Dual-write integration between F&O and Dataverse
How Microsoft's Dual-write framework synchronises Finance/SCM data with Dataverse — table maps, initial sync, and operational realities.
Dual-write is Microsoft's near-real-time integration between Dynamics 365 Finance and Supply Chain Management (the F&O apps) and Microsoft Dataverse (under the CRM apps and the Power Platform). It exists because F&O has its own database that's not Dataverse, so customers running both CRM and ERP need the same Account, Contact, Product, and Order tables to stay in sync between the two systems.
The model. Dual-write defines maps — pairs of tables, one in F&O and one in Dataverse, with a field-level mapping between them. Microsoft ships dozens of standard maps (customer, vendor, product, sales order, sales invoice, employee, work order, project). Custom maps can extend the standard ones or add net-new tables.
Direction. Each map declares a direction: F&O → Dataverse, Dataverse → F&O, or bi-directional. Bi-directional is common for customer-facing entities (a customer added in Sales appears in Finance, and vice versa). Master data with a single authority (e.g. items maintained in F&O) is typically one-directional.
Near-real-time. Dual-write fires synchronously on save in each system. A successful F&O save also writes to Dataverse and waits for the acknowledgment; a Dataverse save writes to F&O. If the partner system is unavailable, the save fails or queues for retry, depending on the map's configuration.
Initial sync. Before live operation, an initial sync copies historical data in bulk in one direction (typically F&O → Dataverse). Initial sync is a sizeable operation for large datasets and is run from LCS.
Plays well with CDM. Dataverse tables in dual-write are aligned with the Common Data Model, so the same Dataverse Account is shared across Dual-write to F&O, Customer Insights, Sales, and Customer Service.
Pitfalls.
- Latency under load. A burst of F&O posting can backlog Dual-write, with downstream apps seeing data minutes after the source. Monitor the queue.
- Schema drift. Map definitions must track schema changes in both F&O and Dataverse. A new required field on either side breaks the map until updated.
- Validation differences. Both systems have their own validation; rejected writes need a retry strategy.
Where it fits. Dual-write is the canonical choice for customers running F&O alongside CRM-side D365 apps. For F&O integrations that don't need Dataverse — pure ERP-to-ERP, ERP-to-EDI — use the Data Management Framework or the F&O REST API instead.
Related guides
- Master Data Services vs Dual-Write for Dynamics 365How Master Data Services and Dual-Write differ as integration patterns between F&O and Dataverse — strengths, weaknesses, and the architectural choices.
- Data entities and the Data Management FrameworkHow bulk data import, export, and integration work in Dynamics 365 Finance and SCM — entities, projects, and the recurring integration pattern.
- Finance and Operations and the Power PlatformHow Dynamics 365 Finance and Supply Chain extend through the Power Platform — virtual entities, Power Automate, Power Apps, and AI Builder.
- Lifecycle Services (LCS) explainedWhat LCS does for Dynamics 365 Finance and Supply Chain projects — workspaces, environments, deployable packages, BPM, and support.
- One Version and updates in Finance and SCMHow Microsoft's One Version policy works for Dynamics 365 Finance and Supply Chain — Service Updates, pause windows, and the upgrade obligation.