Power Apps alternative that connects directly to your business systems

How does Power Apps reach Business Central data?

Microsoft documents virtual tables as the way to use Business Central tables in Dataverse: you make the tables available as virtual tables, and the data stays in Business Central. This article covers that route only; if your maker plans another connection method, check its behaviour in current Microsoft documentation.

For customer engagement apps, Microsoft describes makers building experiences with data directly from Business Central, with full create, read, update and delete capability, without copying it to Dataverse and applying the logic that already resides in Business Central. The route also has documented limits. Virtual tables cannot yet be used in charts, and attachments, images and multiline text fields are not supported. They are organization owned and do not support Dataverse row-level security, so Microsoft recommends implementing your own security model for the external source. They also do not support auditing.

None of this rules Power Apps out. Each limit is work that someone on your team has to design around and keep in place.

Who builds and maintains a Power Apps app?

In Power Apps, an app is typically built and maintained by a named maker in the business or in IT, which becomes a risk when that person moves on or changes role. Planning for that ownership is part of the real cost of the app, not an afterthought.

In its guidance on governing the default environment, Microsoft notes that when a maker leaves an organization, their apps and flows are in effect owner-less. The same guidance warns that apps without proper application lifecycle management are prone to business continuity risks, and recommends moving high-value apps from the default environment to a managed environment for premium security and governance capabilities.

This article does not assess Microsoft Copilot; whatever AI assistance a maker uses, someone still has to own version two, the next field change in the ERP and next year's access review.

How does business data reach an agent-built app in Ronja?

In Ronja, the platform connects to the systems you already use and gathers and models your data and business definitions into a shared foundation that analysis tools, applications and automated workflows run on. That foundation and the software runtime reside in a company-specific cloud environment, while your existing systems stay in place.

This is a data layer of its own, so it is fair to ask the same question of Ronja that you would ask of Dataverse: how do its figures stay consistent with the ERP? The answer is setup, not automation. Source permissions, data mapping and reconciliation are necessary steps when systems are connected: which records the app may read, how each field matches what finance sees in the ERP, and how differences are checked.

Once the mapping is agreed, amounts and limits are computed by explicit queries or code run by a real compute engine, not written by a language model. Deterministic calculation keeps a figure reproducible; whether it matches the ERP still depends on the mapping and reconciliation behind it.

Power Apps or an agent-built app: side by side

Worked example: a purchasing approval app on Business Central

1. Write down the rule

   This is a hypothetical scenario: Business Central is used as an illustration, and the connections available for your setup must be confirmed first. The purchasing lead writes down the need: purchase orders above an illustrative limit of 50,000 in the company currency need the finance lead's approval, and orders that exceed the cost center's remaining budget are flagged.

2. Connect the source and settle the data

   When Business Central is connected, source permissions, data mapping and reconciliation are agreed: which vendors, purchase orders, cost centers and budgets the app may read, and how each field matches what finance sees in the ERP. This is where consistency with the ERP is decided.

3. An agent builds the app

   AI agents build the approval app against the modelled data in the shared foundation. The foundation and runtime sit in a company-specific cloud environment, while Business Central stays in place as the system of record.

4. Code calculates amounts and limits

   Order totals, remaining budget and the approval threshold are computed by executable program logic, not by AI interpretation. The figures are reproducible, and they agree with the ERP only as far as the mapping and reconciliation from the connection step hold.

5. A person approves each consequential order

   AI interprets ambiguous input, such as a free-text justification, while the finance lead approves orders above the limit. Illustrative: an order of 72,000 against a remaining budget of 40,000, both in the company currency, is flagged on both rules and routed for approval.

6. Run, monitor and adjust

   The app runs with access control, versioning, monitoring and audit history. When the approval limit or a cost center changes, the purchasing lead decides the new rule and AI agents maintain the app; if the underlying ERP fields change, it is worth rechecking the mapping.

How do access control, versioning and audit history work for an agent-built app?

In Ronja, access control, versioning, monitoring and audit history are part of the runtime that executes the software. The same runtime runs an analysis on request, an application a team opens and a workflow started by a schedule or an event.

The data foundation and runtime sit in a company-specific cloud environment, and your existing business systems remain in place; Ronja connects to them rather than replacing them. Consequential decisions stay with people: AI interprets ambiguous input, deterministic code performs calculations and validations, and humans approve what matters.

This does not remove governance work on your side. You still decide who may see which suppliers, cost centers or budgets, and source permissions, data mapping and reconciliation still have to be settled when the systems are connected. For you as an IT lead, having these controls in the runtime can make it easier to account for what runs, but it does not replace your own review.

Who this approach suits, and who it does not

When is Power Apps still the right choice?

Power Apps remains a sound choice when your company already has people who build and maintain apps on the Microsoft stack, and when the app lives mostly inside Microsoft data. If a capable maker owns the app, IT runs a managed environment and the licenses are already in place, adding another platform may not be worth it.

Licensing belongs in the comparison. Microsoft states that model-driven apps use Dataverse and are premium by default, and every user who runs one needs a license with Power Apps premium use rights.

Power Apps may be a weaker fit when no one has time to own the app, when the logic spans Business Central and other systems such as a CRM, or when you need row-level security and auditing on ERP data read through virtual tables. In those cases, an agent-first platform that builds on top of the ERP rather than replacing it is worth reviewing. A fair test is one bounded process, such as purchase approvals, compared on both routes.

If you want to run that test on your own data, we can review one bounded process with you.

Talk to us

Review one bounded process with Ronja.

Sources

• Microsoft Learn – Power Platform integration with Business Central via virtual tables
• Microsoft Learn – Create and edit virtual tables with Microsoft Dataverse
• Microsoft Learn – Manage and govern the default Power Platform environment
• Microsoft Learn – Manage Dataverse auditing
• Microsoft Learn – Power Apps licensing FAQs
• Ronja – Platform
• Ronja docs – Deterministic by design
• Ronja – Data foundation