Dual-Write Explained: Finance and Operations, Dataverse and Virtual Entities

What is dual-write, in plain terms?

Dual-write is the integration Microsoft provides between finance and operations apps (Dynamics 365 Finance, Supply Chain Management, Commerce and the related apps) and the customer engagement apps that run on Dataverse, such as Dynamics 365 Sales, Customer Service and Field Service. Microsoft describes it as an out-of-box infrastructure that provides near-real-time, bidirectional integration through Dataverse. In practice that means a customer created by a salesperson in Dynamics 365 Sales appears in Finance and Operations shortly afterwards, and a credit limit changed by the finance team in Finance and Operations appears on the account in Sales.

The important word is copy. With dual-write, each side stores its own physical copy of the shared records. Dataverse holds the customer engagement copy, Finance and Operations holds its own, and dual-write keeps the two aligned. That is what makes it useful, because Sales, Customer Service, Power Apps and Power Automate all work on real Dataverse rows, and also what makes it a design job: every synchronized table and field becomes a contract between two systems that two teams change.

• Which tables are shared at all: customers, contacts, products and prices are the usual core; many tables are better left on one side.
• Which fields travel with each table, and in which direction, rather than everything that can be mapped.
• Which system owns each field, so the finance team and the sales team are never editing the same value from two places.
• How Finance and Operations legal entities line up with Dataverse business units, teams and record ownership.
• What happens to a record that fails to sync, who sees the error, and who fixes it the same day.

How do virtual entities (virtual tables) differ from dual-write?

Virtual entities take the opposite approach. Finance and Operations acts as a virtual data source in Dataverse: its OData entities appear in Dataverse as virtual tables, and the data does not reside in Dataverse. When a user opens a form or a view that shows a virtual table, the rows are read from Finance and Operations at that moment. Nothing is copied, so there is no second copy to keep aligned, and also no local copy to fall back on.

Microsoft uses both names. The Finance and Operations documentation says virtual entities; Dataverse calls the same objects virtual tables. They are one feature seen from two sides.

When should you use dual-write, and when virtual entities?

The deciding question is who needs to change the data, and how much of it there is. If both the CRM and the ERP side create and edit the same records, and the CRM side needs them as genuine Dataverse rows for its own processes, dual-write is the right tool. If the CRM side mainly needs to see ERP data so that a salesperson or a service agent can answer a customer, virtual entities give current values without the cost of keeping a second copy.

Most real projects use both. Customers, contacts and products are shared through dual-write, because both sides own parts of them. Invoice history, open orders and stock levels are shown through virtual entities, because the CRM side reads them and copying large transactional tables adds load for little gain. Anything that is neither, such as a nightly export to a data warehouse, belongs in a batch integration rather than either of the two.

• Choose dual-write when both sides edit the record, when CRM processes such as workflows, Power Automate flows or security rules must run on it as Dataverse data, or when users need it on the CRM side even while the ERP is busy.
• Choose virtual entities when the CRM side mainly reads, when the data is large or changes constantly, or when one source of truth matters more than a local copy.
• Choose a batch or API integration when the data moves on a schedule, goes to a third system, or is far too large for row by row synchronization.
• Write the choice down per table. A one-page decision list saves weeks of argument in testing.

Who is this guide for, and who needs a different route?

It is for architects, IT managers and finance system owners who run, or are about to run, Dynamics 365 Sales, Customer Service or Field Service together with Dynamics 365 Finance, Supply Chain Management or Commerce, and who need the customer, product and order data to mean the same thing on both sides. It is also for Microsoft partners scoping that integration for a client.

If your ERP is Business Central, the route is different: Business Central connects to Dataverse through its own connection and virtual tables, covered further down. Business Central fits small and mid-sized companies that want finance, inventory, projects and light manufacturing in one cloud system. Finance and Operations fits larger organizations with several legal entities, deep supply chain or production needs, or retail operations on Commerce. If you also run Dynamics 365 Customer Engagement, both connect to it through Dataverse.

What are the typical dual-write pitfalls?

Dual-write rarely fails for technical reasons alone. It fails when the integration is switched on before the two teams have agreed what the shared data means. The list below is what we check first when a dual-write design is already in trouble, and what we design out from the start on a new one.

• Mapping everything because it is possible. Every extra table and field is another place for the two systems to disagree; start with the smallest set that runs the shared process.
• Nobody owns the field. When both the sales team and the finance team edit the same value, changes overwrite each other and nobody can say which one is right. Give every shared field one owning system.
• Duplicates before the first sync. The same customer often exists in the CRM and the ERP under different numbers. Agree the matching key and clean the data before the initial load, or both copies arrive twice.
• Legal entities and business units that were never aligned. Finance and Operations organizes data by legal entity; Dataverse organizes access by business units, teams and owners. Decide how one maps to the other first.
• Custom logic firing on synchronized writes. A plugin in Dataverse or X++ code in Finance and Operations that reacts to every change can create loops or stop a record from saving on the other side. Review both sides for logic that assumes a human made the edit.
• Sync errors with no owner. A record that did not sync is a business problem, such as an order that never reached the warehouse. Name the person who checks the errors every day and the process for fixing them.
• Test environments linked to the wrong counterpart environment. After a sandbox is refreshed or copied, check which Finance and Operations environment is linked to which Dataverse environment before anyone tests.
• Large transactional volumes in near-real-time sync. High-volume tables add load on both sides; show them through virtual entities or move them in batch instead.

How does Business Central connect to Dataverse instead?

Dual-write is built for finance and operations apps. Business Central has its own route. It connects to Dataverse through the Set up Dataverse connection assisted setup, with one-way or two-way synchronization per table, and that connection is the route Microsoft documents for integrating Business Central with Dynamics 365 Sales. For data that should be visible in Dataverse without being copied, the Business Central Virtual Table app exposes Business Central data as virtual tables: the data stays in Business Central, the virtual tables are built on API v2.0, and custom APIs can be exposed as well.

The design questions are the same as for dual-write: which tables are shared, which side owns each field, which data is only shown rather than copied, and who handles the errors. The tooling and the extension language differ, which is why the CRM and ERP integration is designed per ERP rather than from one template.

How do you plan a dual-write or virtual entity project?

Start from the processes that cross the boundary, not from the list of tables the tool can map. Quote to order, customer onboarding, credit checks, product and price updates and service work that ends in an invoice are the usual candidates. For each one, write down which system starts it, which system finishes it and which data both need along the way. The integration design then follows almost mechanically. Delivery of that design is our CRM and ERP integration service.

• List the cross-system processes and the people who run them, on both the CRM and the ERP side.
• For each table involved, choose dual-write, virtual entity or batch integration, and record why.
• Assign one owning system per shared field, and agree the matching keys for records that already exist on both sides.
• Clean and deduplicate the data on both sides before the initial load, then rehearse the load in a test environment.
• Review custom logic on both sides, Dataverse plugins and flows as well as X++ extensions, for behaviour on synchronized writes.
• Name the owner of sync errors and the daily check, and test the error path deliberately, not only the happy path.
• Go live table by table where the processes allow it, rather than switching on every mapping on the same day.

How does Solzet deliver dual-write and CRM and ERP integration?

Solzet works on both sides of the Microsoft business stack. We know Dataverse and Dynamics 365 Customer Engagement deeply, and we implement Business Central and Finance and Operations. That means one team designs the CRM, the ERP and the integration between them: Customer Engagement with Business Central through the Dataverse connection and virtual tables, Customer Engagement with Finance and Operations through dual-write and virtual entities, and Power Platform across both.

For the ERP side, see Dynamics 365 Finance and Operations and Dynamics 365 Business Central; for the CRM side, Dynamics 365 consulting. Where Microsoft licensing does not suit the CRM side, a custom CRM can integrate with Finance and Operations through its OData entities instead. More decision guides are collected on the Solzet guides page.