Dual-write between F&O and Customer Engagement: what it actually does

Dual-write is the integration between Dynamics 365 Finance and Operations and Dynamics 365 Customer Engagement apps. The branding is crisp; the architecture questions around it are constant. Architects specifying dual-write for the first time routinely get it wrong in predictable ways.

What dual-write is not

Several misconceptions show up in planning workshops:

"Dual-write is one-way from Finance to Customer Engagement." Wrong. It's bi-directional. Changes on either side propagate to the other side. Configuring it as if it's one-way misses half the capability and creates confusion when changes flow "unexpectedly".

"Dual-write exports master data once and then you manually update." Wrong. It's a persistent sync, not a migration tool. Once configured and enabled, the integration continues running in the background for every change.

"Dual-write duplicates tables without keeping relationships." Wrong. Table maps carry relationships across the boundary - a customer record in F&O and the corresponding account record in Dataverse stay linked via alternate keys, not via duplicated joins.

Getting these straight matters because the architecture implications are different for each false belief.

What dual-write actually does

Dual-write establishes near-real-time bi-directional data flow between specific tables in F&O and specific tables in Dataverse (which backs Customer Engagement apps). When you create or update a record on one side, the change flows to the paired table on the other side within seconds.

The machinery underneath:

• F&O has plugins on the covered tables that fire on change
• Dataverse has plugins on the paired tables that fire on change
• Plugins publish to a shared integration event stream
• Each side subscribes to events for tables it cares about
• Field mappings are declared via table map configurations

The result: F&O sees customer records created in CE for new leads. CE sees customer master records created in F&O for billing-driven account setups. Both sides stay consistent.

Why bi-directional matters

Consider customer master management at a company running both F&O and CE:

F&O maintains customer master for billing. When AR sets up a new customer with payment terms and credit limit, that record needs to appear in CE so sales can see it.

CE maintains leads and accounts for prospecting. When sales converts a lead to an account that's ready for quote-to-cash, that record needs to flow to F&O.

If dual-write were one-way F&O → CE, sales would manually recreate accounts in F&O after conversion. If it were one-way CE → F&O, billing wouldn't see records originated in AR. Bi-directional is the only pattern that fits how the two systems are actually used.

Standard table maps

Microsoft ships default maps for the common master data:

• Customer / account - customer master, contacts, addresses
• Vendor - vendor master, contacts, addresses
• Product - released products, product variants, product images
• Financial dimensions - default dimension values for cross-module consistency
• Employee / system user - for task assignment flows

Additional out-of-box maps cover less-common but still important scenarios (tax codes, currency, payment terms). Custom maps extend this for tables unique to the implementation.

Conflict rules

Bi-directional sync needs conflict resolution when both sides edit the same field at the same time. Dual-write supports:

• F&O wins (default for F&O-master tables)
• CE wins (default for CE-master tables)
• Per-field overrides - the Customer's "preferred communication" might be CE-master while everything else is F&O-master

Documenting conflict rules per table is the architect's responsibility. Standard defaults are a starting point, not a final answer.

Initial sync and ongoing sync

When enabling dual-write for a table with existing data:

• Initial sync pushes current state from one side to the other (F&O typically the source for master data)
• Ongoing sync takes over once initial completes

For tables with large existing datasets, skip initial sync via dual-write (too slow) and use DMF-based migration + delta-only sync activation. This is documented but teams often miss it and wonder why their initial sync is still running after 3 days.

What dual-write isn't for

Not every F&O ↔ CE integration needs dual-write:

• High-frequency operational data (inventory transactions, time entries) - too chatty for dual-write; use business events + custom integration
• Reporting data - reads don't need sync; query each side directly or combine via Power BI
• Bulk data loads - use DMF, not dual-write
• One-off migrations - use data entities + DMF, not dual-write

Dual-write shines for master data and key transactional records that both sides genuinely need to see. Outside that scope, different patterns fit better.

Operational discipline

Running dual-write in production requires:

• Error queue monitoring - Power Platform admin center shows failed syncs; daily sweep minimum, hourly during initial rollouts
• Performance monitoring - dual-write latency per table tracked; alert when it crosses acceptable threshold
• Map versioning - when schema changes on either side, table maps update; deploy via ALM like any other change
• Disable-and-resync procedures - occasionally a table drifts and needs resync; ops team knows how

What ships with the architecture

A working dual-write implementation has:

• Standard table maps activated for the master data in scope
• Custom table maps for scenario-specific tables
• Conflict rules documented per map
• Initial sync strategy executed (direct or DMF-assisted)
• Error queue monitoring active
• Documentation of what syncs vs what doesn't, for future architect reference

Dual-write does exactly what the name says - writes to both systems. Understanding the "near real-time, bi-directional" part correctly is most of the work.