Master Data Services vs Dual-Write for Dynamics 365

Connecting Dynamics 365 Finance and Operations (back-office ERP) with Dataverse-based Customer Engagement apps (CRM, Customer Service, Field Service) is a frequent architectural requirement. Two patterns dominate: Dual-Write (Microsoft's purpose-built bidirectional sync) and Master Data Services / Master Data Integrator (older patterns, mostly one-way). Knowing which to use when matters.

The integration problem.

• F&O has its own data — customers (in F&O's CustTable), items, etc.
• Dataverse has Customer Engagement's data — Accounts, Contacts, Products.
• Same business entity (a customer) lives in both.
• Changes in one need to flow to the other.

Without a sync mechanism, manual re-entry happens; data diverges; chaos ensues.

Dual-Write. Microsoft's purpose-built sync:

• Bidirectional — changes flow both ways.
• Real-time — within seconds.
• Built into F&O — configurable; enabled per entity.
• Maps F&O entities to Dataverse entities — Customer → Account, etc.
• Initial sync — bulk one-time populating; ongoing changes incremental.
• Conflict resolution — defined rules when both sides change.

For organisations running F&O + Customer Engagement, Dual-Write is the canonical integration.

Dual-Write architecture.

• F&O writes change events to its internal queue.
• Dual-Write service reads queue.
• Translates F&O record to Dataverse representation per mapping.
• Writes to Dataverse.
• Mirror path for Dataverse → F&O.

Each entity has a configurable map; standard maps shipped by Microsoft; customisable for extensions.

Dual-Write mapping configuration.

• F&O entity — source.
• Dataverse table — target.
• Field mappings — per-column.
• Filters — only sync certain records.
• Direction — one-way or two-way.
• Initial sync vs running sync — separate configuration.

Standard mappings cover common entities; custom entities need custom mappings.

Common Dual-Write entities.

• Customer / Account
• Vendor / Account (with different role)
• Released Product / Product
• Sales Order
• Quotation
• Invoice (less commonly)
• Contact
• Address
• Employee / Contact (with Worker role)

The list expands per wave.

Master Data Services (MDS). The older pattern:

• Microsoft's enterprise master data management product (SQL Server-based).
• Hub-and-spoke; MDS is the authoritative source.
• F&O and Dataverse both subscribe to MDS.
• Less integrated with Dynamics; manual configuration.

Mostly legacy now; Dual-Write supersedes for Dynamics-specific scenarios.

Master Data Integrator (older Dynamics-specific tool). Historical:

• Pre-Dual-Write integration between F&O and Customer Engagement.
• File-based, slower, batch-oriented.
• Largely deprecated; Dual-Write is the replacement.

Dual-Write strengths.

• Real-time bidirectional.
• Native to Dynamics; minimal external infrastructure.
• Standard mappings for common entities.
• Conflict resolution built in.
• Microsoft-supported.

Dual-Write limitations.

• Bound to Dataverse-F&O pair; not for non-Dynamics destinations.
• Mapping complexity for custom entities.
• Performance issues at very high volumes (>10K changes per minute).
• Initial sync of large data sets can take days.
• Schema changes break mappings; coordination needed.

Alternative patterns.

• Custom integration via Azure Service Bus — for complex scenarios beyond Dual-Write's reach.
• ADF pipelines — for batch sync rather than real-time.
• APIs direct — F&O and Dataverse APIs called directly from custom code.

Each has its place; Dual-Write should be the default for F&O↔Dataverse sync.

Conflict resolution. When both sides change a record simultaneously:

• Last write wins — default.
• Source priority — one side authoritative for specific fields.
• Manual review — for conflicts, queue for human resolution.

Configurable per entity / per field.

Monitoring. Operational health:

• Dual-Write admin pages — sync status per entity.
• Failed syncs — exception queue.
• Latency metrics — how fast changes flow.

Without monitoring, sync issues compound; data diverges silently.

Schema evolution. When entities change:

• New field added in F&O → Dual-Write mapping needs update.
• New field added in Dataverse → similar.
• Field renamed → mapping breaks.

Coordinate schema changes; test mappings; deploy together.

Common pitfalls.

• No initial sync planning. Skipping initial bulk; running data desynchronised.
• Mapping gaps. Some fields not mapped; data divergence on un-mapped fields.
• Conflict resolution untuned. Last-write-wins for every field; legitimate updates overwritten.
• No monitoring. Failures accumulate; nobody notices until reconciliation reveals divergence.
• Heavy plug-ins on Dataverse side. Dual-Write writes; plug-in fires; updates F&O; loop.
• Performance under load. Heavy F&O batch creates lag in Dataverse view.

Strategic positioning. For organisations running both F&O and Customer Engagement on Dynamics 365, Dual-Write is the canonical integration pattern. Plan and execute it thoughtfully; the initial setup investment pays back continuously.

For organisations with non-Dynamics destinations (Salesforce, ServiceNow), or with complex multi-system integrations, Dual-Write doesn't apply directly; custom patterns via Service Bus or Power Automate fill the gap.

Master Data Services has its niche for enterprise MDM but is increasingly secondary to Dual-Write for Dynamics-specific needs. Choose based on the actual integration topology; don't force tools beyond their natural fit.