How does a third-party app read and write Dynamics data…

How does a third-party app read and write Dynamics data without touching the ERP core?

Through the integration surfaces each ERP (enterprise resource planning system) publishes for exactly that purpose — and the two ERPs under the Dynamics 365 umbrella publish different ones. Business Central names four built-in ways to integrate with Dataverse plus three types of web service. Finance & Operations names virtual entities, dual-write and data entities.

"Touching the core" means changing the application's code or its physical tables. Reading and writing through a published surface is the opposite: it is the vendor's own contract, versioned by the vendor, and on two of these surfaces Microsoft states in plain words that no copy of your data is made.

Business Central names three web-service types and four built-in ways in

Microsoft's Integration overview for Business Central opens with the general rule: "Most integrations (except for a few built-in integrations) to and from Business Central are done using web services. Business Central supports three types of web services: REST API, SOAP, and OData." It then names the preference outright — "The recommended way to use web services for Business Central is by using the REST API stack."

The built-in exceptions are counted on the same page: "Business Central has four built-in ways to integrate with Dataverse". Reproduced as Microsoft lists them:

**Data synchronization** — Microsoft's wording, verbatim: "Data synchronization that replicates data between Business Central and Dataverse." · Status: [GA]
**Data virtualization — Microsoft's wording, verbatim: "Data virtualization with virtual tables in Dataverse via Business Central API for (Create/Read/Update/D**elete) operations." · Status: [GA]
**Data change (CUD) events — Microsoft's wording, verbatim: "Data change (CUD**) events using webhooks." · Status: [GA]
**Business events** — Microsoft's wording, verbatim: "Business events (preview)." · Status: [PP] as of the page's 2025-10-19 date

Only the fourth carries a preview marker on that list, and neither integration page stamps the other three either way. The release plan does: Business Central virtual tables fully supported on Microsoft Dataverse records general availability on 1 November 2023, which is where the [GA] on data virtualization comes from. The labels on data synchronization and on CUD events rest on the absence of a preview marker on these two pages, not on a Microsoft status stamp.

Two of those four are notification surfaces rather than data surfaces — our split, not Microsoft's wording. Webhooks and business events tell you something happened; they are not how you read a ledger or write a decision back.

The sentence that decides the Business Central answer

The dedicated page, Integrating with Microsoft Dataverse, separates the two data surfaces in a way that matters to an architect. Data synchronization "persists the synchronized data on the destination end of the setup." Virtualization does not:

"Virtual tables in Dataverse can use Business Central APIs exposed through API Pages. As seen from

Dataverse, these virtual tables act as regular tables. Makers can now build experiences in apps

built on Dataverse with live data shown from Business Central and with full CRUD capability. All

data changes are only saved in Business Central, so no data is copied to Microsoft Dataverse."

That last clause is the sentence to put in front of an IT buyer, and it is Microsoft's, not ours. A synchronization creates a second copy you now govern, back up and reconcile. Virtualization creates none — the record stays in the ERP and Dataverse holds a live projection of it.

Note the mechanism named there: API Pages. Business Central's virtual tables are built on the same API object AL developers publish. That has a consequence we come back to in the sibling piece on AL and X++, because Microsoft's extensibility overview states that "Extending API pages and queries isn't currently possible in Business Central" (Extensibility overview). The surface is open to read and write; the object defining it is not open to extend.

Finance & Operations names three surfaces, and they differ in where the data sits

**Virtual entities** — What Microsoft says it is: "Finance and operations apps act as a virtual data source in Dataverse. They enable full create, read, update, and delete (CRUD) operations from Dataverse and Microsoft Power Platform." · Where the data lives: "By definition, the data for virtual entities doesn't reside in Dataverse. Instead, it continues to reside in the app where it belongs." · Status: [GA], requires version 10.0.12 and Dataverse service update 189
**Dual-write** — What Microsoft says it is: "an out-of-box infrastructure that provides near-real-time interaction between customer engagement apps and finance and operations apps" · Where the data lives: Both. "Any data change in finance and operations apps causes writes to Dataverse, and any data change in Dataverse causes writes to finance and operations apps." · Status: [GA]
**Data entities* — What Microsoft says it is: "A data entity* is an abstraction from the physical implementation of database tables." · Where the data lives: In finance and operations apps; the entity is a de-normalised view over its tables · Status: [GA]

The reach of the first one is wider than most architects expect: Virtual entities overview states that "All Open Data Protocol (OData) entities in finance and operations apps are available as virtual entities in Dataverse, and therefore also in Microsoft Power Platform." Microsoft adds that these experiences "offer full CRUD capability and don't require copying to Dataverse."

Virtual entities invoke the ERP's own business logic — that is the point, not a side effect

The same page describes the call path, and it is the strongest available answer to "what stops a third-party app corrupting my ERP":

"This web service then converts the queries into calls to the associated physical entities in

finance and operations apps, and invokes CRUD or OData operations on those entities. Because a

finance and operations entity is directly invoked in all operations, any business logic on the

entity or its backing tables is also invoked."

A write through a virtual entity does not go around the ERP's validation. It goes through it. The entity's own logic runs, exactly as it would if a user had typed the value into a form.

Identity is bounded the same way. Microsoft describes the traffic as "service-to-service (S2S) calls" using a Microsoft Entra application whose user "should have access only to the CDSVirtualEntityAdapterService web API and the catalog entity, CDSVirtualEntityListEntity" — privileges carried by the out-of-box security role named CDSVirtualEntityApplication.

Then the important part: "The CDSVirtualEntityAdapterService web API looks up the associated user in finance and operations apps and runs the query in the context of that user."

So the blast radius of an integrated app is a finance and operations security role, reviewable by the people who already review security roles. Microsoft warns the inverse case too: "The Dataverse SYSTEM user doesn't have access to all entities in finance and operations, nor do the out of the box service-to-service applications."

One deployment constraint, in Microsoft's words: "For optimal latency in virtual entity calls, always use finance and operations apps and Dataverse that are co-located in the same Azure region. When finance and operations apps and Dataverse are co-located, the virtual entity overhead is expected to be less than 30 milliseconds (ms) per call."

Data entities are the abstraction that outlives the schema

The Data entities overview carries the sentence that answers the upgrade question before anyone asks it:

"The abstracted nature of a data entity can simplify application development and customization.

Later, the abstraction also insulates application code from the inevitable churn of the physical

tables between versions."

That is the durability argument for building against entities rather than tables, made by the vendor whose tables churn. Microsoft groups entities into five categories — Parameter, Reference, Master, Document and Transaction — and the category tells you how an entity behaves under a data copy.

Two properties on the entity decide which surface it appears on: Enable public API — "Select this option to enable the entity for OData services" — and Enable data management capabilities, for "asynchronous integrations such as data import/export and connector integration", which generates a Staging table used "in asynchronous integrations and high-volume scenarios."

Where we would draw the line

We would not read an optimization app's inputs through [dual-write](https://learn.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/data-entities/dual-write/dual-write-overview). It is excellent at what it is for — keeping customer, product and vendor masters aligned across finance and operations apps and customer engagement apps — and it is the wrong instrument for an analytical read.

Microsoft is explicit about what installing it does: "Dual-write consists of two Marketplace solutions that you install on Dataverse. The solutions expand the table schema, plugins, and workflows on Dataverse so that they can scale to ERP size." And: "To create parity with finance and operations applications, dual-write makes some crucial changes in the Dataverse schema."

Changing the Dataverse schema to read some order lines is a large permanent commitment for a small temporary need. Virtual entities and data entities install nothing on Dataverse and change no Dataverse schema.

How our Optimizers connect. Each Optimizer reads through the surfaces above — virtual entities and OData-enabled data entities on Finance & Operations, virtual tables and the REST API stack on Business Central — computes the decision on Azure in your tenant, and writes the optimized value back through the same surface, behind a human approval step and inside a named security role. No ERP object is modified. That is how we architect them.

What to ask this week

For each integration in your estate, name which surface above it uses. The one nobody can place on that list is where to start.
On Business Central, separate the synchronizations from the virtualizations. Every synchronization is a second copy with a governance owner; if it has no owner, that is the finding.
On Finance & Operations, check whether your Dataverse environment is co-located in the same Azure region as the ERP — Microsoft's latency guidance for virtual entities depends on it.
Ask any vendor proposing an integration one question: which security role does your service run as? Under virtual entities the answer is a finance and operations role and it is inspectable.

About Cognilium Cognilium builds AI optimization apps for Microsoft Dynamics 365 — companion apps that optimize the pricing, inventory, warehouse and planning decisions your ERP manages but can't optimize. Dynamics is your system of record. Cognilium is your system of intelligence. https://cognilium.ai · https://www.linkedin.com/company/37180269/

If you are running the integration review and want the surface-by-surface version against your own estate, book a fifteen-minute call and we will walk it with you live — no deck. https://cognilium.ai

How does a third-party app read and write Dynamics data without touching the ERP core?