Dual-write integration between F&O and Dataverse

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.

Standard maps at a glance

Domain	Example maps	Typical direction
Party data	Customer, Vendor, Contact, Worker	Bi-directional (both systems create and edit)
Product	Released product, Product master	F&O → Dataverse (F&O is the system of record for items)
Sales	Sales order, Sales order line	Bi-directional (Sales app creates, F&O fulfils and invoices)
Project	Project, Project task	Bi-directional (Project Operations and F&O Project management)
Case/Service	Work order, asset	F&O/Field Service → Dataverse depending on which app owns the record

Not every table needs dual-write — a table with a single authoritative system and no CRM-side consumer of that data (a purely internal F&O configuration table, say) should stay in F&O only. Turning on dual-write for tables nothing downstream reads adds sync overhead and failure surface for no benefit.

Extending a standard map vs building a custom one

Microsoft's standard maps cover the common fields for each entity, but a project's own required fields — a custom customer attribute, an industry-specific product field — usually aren't in the standard mapping. Dual-write supports extending a standard map by adding fields to it, which is the preferred approach when the entity itself is standard and only the field list is incomplete. Reach for a fully custom map only when the entity itself doesn't exist in the standard set at all; extending is lower-maintenance because it inherits fixes and schema updates Microsoft ships to the base map, where a custom map is entirely the implementation team's to maintain.

Monitoring and alerting

Dual-write exposes sync status and error logs through both the Dataverse Dual-write admin app and F&O's own integration monitoring. A healthy operational setup alerts on: a rising error queue (writes failing and retrying without resolving), growing latency (the gap between a save and its counterpart appearing on the other side), and any map that's been disabled (deliberately or due to a fatal schema mismatch) without anyone noticing. Because dual-write runs synchronously on save, a silent backlog is worse than a visible one — users on the source system see their save succeed even while the counterpart write is failing, so nobody notices the drift until a report on the other side looks wrong.

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.

Where to go next

When it misbehaves, dual-write troubleshooting patterns gives the diagnostic order and dual-write sync errors decodes the messages. Master data services vs dual-write covers the alternatives, how Dynamics 365 apps connect the architectural context, and what is Microsoft Dataverse the platform on the other side.