Dual-write works well for shared master data (customers, vendors, products, pricing) and the prospect-to-cash documents that Finance and Operations and Customer Engagement both own. It struggles with high-volume transactional data, unmonitored sync errors and heavily customised entities.
Microsoft's pitch is that F&O and CE share data in near real time through Dataverse, so sales sees true stock and pricing, finance sees real orders, and Dynamics 365 behaves like one product. We have implemented it several times, and the pitch is achievable inside these boundaries.
Dual-write is at its best on the master data spine: customers, vendors, products, pricing. Syncing them by hand is miserable work, and dual-write does it with framework-level consistency, including initial sync for existing data. If the requirement is "the account team and the finance team should be looking at the same customer", dual-write is the shortest reliable path there.
It also fits prospect-to-cash. A quote matures in CE, becomes an order in F&O, and the fulfilment status flows back to where the account manager works. This is the pattern the feature was built for, and it works.
Volume: dual-write is a synchronous, row-by-row mechanism, and pushing high-volume transactional data through it, telemetry, large order books, integration traffic that belongs in middleware, produces throttling and sync errors that take real effort to drain. The framework is built for master data and business documents. Estates that use it as an integration bus regret it.
Error handling: when a row fails to sync, someone has to notice, diagnose and replay it, and out of the box that someone is whoever checks the queue. Any serious deployment needs monitoring and alerting built around sync health from day one, because a silent backlog of failed rows becomes a reconciliation problem that grows the longer nobody looks.
Customisation drift: dual-write maps assume the entities on both sides still look roughly standard. Estates that have customised heavily on either side spend their implementation budget reworking maps, and every future change to those entities carries a dual-write regression test with it, alongside the One Version update routine.
The framing we use with clients is simple: dual-write for shared master data and the documents both systems co-own; Azure integration services for volume, for anything event-driven, and for every system that is not Dynamics; and reporting out of the lakehouse instead of either application (see your ERP is not a reporting archive). Most struggling dual-write deployments carry loads that belonged in the second or third category.
Sequencing matters too. Decide master data ownership first: one system is the source of truth per entity. Dual-write will synchronise an unresolved ownership problem in both directions.
Dual-write is Microsoft's framework for near real-time synchronisation between Finance and Operations and Customer Engagement apps through Dataverse. It includes an initial sync for existing data.
Shared master data such as customers, vendors, products and pricing, plus business documents both systems use, such as quotes and orders. High-volume and event-driven traffic belongs in Azure integration services.
The common causes are high volumes that trigger throttling, failed rows nobody is monitoring, and entities customised away from the standard maps. Monitoring and alerting on sync health should be in place from day one.
It can, at a cost. Heavy customisation means reworking the maps, and every later change to those entities needs a dual-write regression test.
Our Dynamics 365 practice designs integration architecture alongside the implementation itself.
Marcel Rizzolo is Director of Coder Trove.