Integrating Dynamics 365 Sales with Salesforce: cutover and coexistence patterns

Most organisations that connect Dynamics 365 Sales to Salesforce are not building a permanent integration. They are somewhere on a path from one CRM to the other, or they have inherited two CRMs through an acquisition and need them to coexist until someone makes a decision. The integration pattern you pick should match which of those situations you are actually in, because the right answer for a six-month cutover is the wrong answer for a five-year coexistence.

Three situations, three patterns

Cutover. Salesforce is being retired and Dynamics 365 Sales is replacing it. The integration is temporary scaffolding: it keeps both systems usable while business units move across in waves. Here the pattern is a one-way feed from the system that is still live to the system that is going live, with a hard end date.

Coexistence with a split. Different business units, regions, or product lines will stay on different CRMs indefinitely. Each system is the system of record for its own opportunities, and the integration exists so that shared customers and shared reporting make sense. The pattern is a master-data sync for accounts and contacts, and nothing else.

Coexistence with overlap. The same sales team touches both systems for the same customers, usually because one CRM owns a product line the other does not. This is the pattern to avoid if you can. Two-way opportunity sync between CRMs with different pipeline models is where integration projects go to die.

Be honest with yourself about which one you are in. Many "coexistence" projects are really cutovers that nobody has been given permission to call a cutover.

What to sync and what not to

Accounts and contacts are the safe core. Both systems model them similarly enough that a field mapping is tractable, and a shared customer list is what most stakeholders actually want. Even here, decide on one system of record per record. A rule like "the CRM that created the account owns it, the other one holds a read-only copy" is simple and enforceable. Bidirectional ownership with last-write-wins conflict handling sounds flexible and produces silent data loss.

Opportunities are where the models diverge. Salesforce stages, probability, forecast categories, and opportunity products do not line up cleanly with Dynamics 365 business process flows, pipeline phases, and product line items. If you must move opportunities, move them once as part of a wave migration, not continuously.

Activities (emails, calls, tasks) are almost never worth syncing between two CRMs. They are high volume, low value across the boundary, and both systems already have their own Outlook and Gmail integrations. Let each CRM keep its own activity history and accept the gap.

Leads are a special case. If marketing feeds leads into one system, route them to the right CRM at the point of creation rather than syncing after the fact. A routing rule at the front door is far cheaper than reconciling duplicate leads later.

Tooling options

Power Automate with the Salesforce connector. Adequate for low-volume, event-driven sync of accounts and contacts. The connector handles authentication and basic CRUD. It does not handle bulk backfills well, and flow run limits bite when a mass update on one side triggers thousands of runs.

An iPaaS (Boomi, MuleSoft, Workato, Celigo). The default for anything with real volume or more than a handful of objects. You get retry, mapping tooling, and monitoring you would otherwise build yourself. Salesforce-heavy organisations often already own MuleSoft; use what is already paid for and understood.

Custom code against both APIs. Dataverse Web API on one side, Salesforce REST or Bulk API on the other, with an Azure Function or a small service in between. Justifiable when the mapping logic is genuinely complex or when the integration is a short-lived cutover tool that will be thrown away. See our guide on Azure Functions for Dynamics 365 for the mechanics.

Dual maintenance by humans. Do not laugh. For a three-month cutover with a small team, having reps enter shared accounts in both places is sometimes cheaper and less risky than building anything. It fails once volume or duration grows.

Identity and matching

The hardest technical problem is knowing that a Salesforce account and a Dataverse account are the same company. Store the foreign key explicitly: a Salesforce ID column on the Dataverse account and a Dataverse GUID field on the Salesforce account. Use alternate keys in Dataverse so upserts are idempotent. Never match on name alone; matching on a normalised domain or a tax registration number is better, and even that needs a human review queue for the ambiguous cases.

Cutover sequencing

For a cutover, the pattern that works is: migrate historical data once (closed opportunities, activity history) as a bulk load, then run a live sync only for open accounts, contacts, and open opportunities during the overlap window, then switch off the sync and make Salesforce read-only. Keep Salesforce accessible read-only for as long as the licence allows rather than exporting everything to a reporting database on day one; people will want to check things.

What breaks in practice

Picklist drift is the usual first failure. Someone adds a value to a Salesforce picklist, the sync has no mapping for it, and records start failing quietly. Build the integration to reject unknown values loudly and alert someone.

Ownership is the second. User records do not map one-to-one across systems, especially when reps exist in only one CRM. Decide up front what owner a synced record gets on the other side.

Deletes are the third. Salesforce soft-deletes to a recycle bin; Dataverse hard-deletes unless you build otherwise. Most integrations should treat deletes as a status change rather than propagating them.

Stability verdict

A one-way account and contact sync between the two CRMs is a stable, well-trodden pattern. Two-way opportunity sync is not, and any partner who tells you it is routine has not lived with one. If you are comparing the products rather than connecting them, start with Dynamics 365 Sales vs Salesforce.