Salesforce Dynamics 365 Integration: Options, Setup and Pitfalls
Why companies run Salesforce and Dynamics 365 together
Microsoft Dynamics 365 is a family of apps, not one product. So "Salesforce Dynamics 365 integration" can mean very different projects. Four situations cover most of them:
- Sales in Salesforce, finance in Dynamics 365. The sales team lives in Salesforce, while orders, invoices and cash sit in Dynamics 365 Business Central or Dynamics 365 Finance. This is a CRM-to-ERP integration, and it is usually permanent.
- Two CRMs after a merger or acquisition. One company sells in Salesforce, the acquired one in Dynamics 365 Sales. Leadership wants one pipeline report and no double-booked accounts.
- Different divisions, different CRMs. A services unit runs Dynamics 365 Customer Service, product sales run Salesforce, and both touch the same customers.
- A phased migration. The company is moving from one CRM to the other and needs both in sync for months while teams switch over.
The first case is about a clean quote-to-cash flow. The other three are CRM-to-CRM syncs, which are harder than they look because both systems want to own the same accounts, contacts and opportunities. For the wider picture of Salesforce integrations, start with our Salesforce integration guide.
Integrate, consolidate or migrate?
Answer this before you compare tools. A permanent two-way sync between two CRMs is one of the most expensive integrations to run, because every new field, picklist value and sales process change has to be made twice.
| Your situation | Usual answer | Why |
|---|---|---|
| Salesforce for sales, Business Central or Finance for accounting | Integrate, permanently | Different jobs; each system is the master for its own records |
| Two CRMs, same customers, one company after a merger | Consolidate, with a temporary sync | Two masters for one customer never stay clean; sync only what the bridge period needs |
| Two CRMs, separate customers and teams | Integrate a few shared objects, or just report across both | Often only accounts, a shared pipeline view or a handoff between teams is needed |
| Moving from one CRM to the other | Migrate, with a sync during cutover | A one-time migration plus a short sync is cheaper than months of two-way sync |
If you decide to move from Salesforce to Dynamics 365 Sales or Customer Service, Microsoft now has a migration tool for that direction. According to Microsoft’s documentation, Dynamics 365 Activate (in preview as of October 2026, US region only) scans a Salesforce org, maps objects and fields to Dataverse, creates the schema and migrates data with reconciliation. It assesses flows, Process Builder, workflow rules and Apex, but does not convert or migrate them. Moving the other way, from Dynamics 365 to Salesforce, is usually done with Salesforce’s data tools, an ETL or iPaaS tool, or a migration partner.
Your integration options compared
There is no Microsoft or Salesforce product that syncs the two CRMs out of the box. These are the realistic routes, from lightest to heaviest.
1. Power Automate (and Power Apps) with the Salesforce connector
Microsoft publishes a Salesforce connector for Power Automate, Power Apps and Copilot Studio. According to Microsoft’s connector reference, it is a Premium connector, so users need a license that includes premium connectors. It has triggers for created and modified records, actions to create, update and upsert records by External ID, SOQL queries and Bulk API jobs. Pair it with the Dataverse connector, whose "When a row is added, modified or deleted" trigger covers the Dynamics side.
The limits matter for a CRM sync. As of October 2026, Microsoft lists a throttle of 900 calls per connection per 60 seconds, there is no Salesforce trigger for deleted records, custom multi-select picklist fields are not supported by the Create record and Update record actions, and the Salesforce org must have API access enabled (trial orgs don’t). It works well for a handful of one-way flows; a full two-way sync built from many flows becomes hard to monitor.
2. Azure Logic Apps and Azure Data Factory
The same Salesforce connector is available in Azure Logic Apps, which suits IT teams that want integrations in Azure with source control and monitoring. For bulk data, Azure Data Factory’s Salesforce V2 connector (the older V1 connector has been removed) copies data to and from Salesforce using Bulk API 2.0, with insert and upsert by External ID, and authenticates with OAuth 2.0 client credentials. It is built for scheduled batch loads: initial migrations, nightly syncs and feeds into a data warehouse, not real-time updates.
3. An iPaaS: MuleSoft, Boomi, Workato
All three have connectors for Salesforce and for Dynamics 365 (MuleSoft’s Microsoft Dynamics 365 Connector, for example, connects to the Dynamics 365 cloud API with OAuth 2.0 authentication). You design the flows, error queues and retry logic once and reuse them for other systems. This is the usual choice when Salesforce and Dynamics 365 are two of many systems, or when a merger brings several integrations at once. MuleSoft is a Salesforce company; our Salesforce MuleSoft integration guide covers when it is worth the price.
4. Prebuilt connector apps
Several vendors sell ready-made Salesforce sync apps on Microsoft AppSource and on AppExchange (now AgentExchange), especially for Salesforce Business Central integration. They are quick to start but vary widely in what they sync, so ask for a demo with your own objects and a written list of supported fields.
5. Custom integration on both APIs
A small service calls the Salesforce REST and Bulk APIs (and listens to Change Data Capture or Platform Events) on one side, and the Dataverse Web API, Business Central API v2.0 or Dynamics 365 Finance data entities on the other. You get full control over matching, conflict rules and logging, and you own maintenance through every release of both platforms.
One more option is read-only: Salesforce Connect can show Dataverse records inside Salesforce as external objects through its OData 4.0 adapter, because the Dataverse Web API is an OData v4 service. Data is read live and not copied. It is a paid add-on in Enterprise, Performance and Unlimited editions and works best for lookups, not for sync.
| Option | What it syncs | Direction | Cost level | Effort | Main limits |
|---|---|---|---|---|---|
| Power Automate + Salesforce connector | Any standard or custom object, record by record | One-way or two-way (one flow per direction) | $ premium licenses | Low | 900 calls per minute per connection; no delete trigger; no multi-select picklists on write |
| Azure Logic Apps | Same connector, Azure-managed | Any | $ usage-based | Low to medium | Same connector limits; needs Azure skills |
| Azure Data Factory | Bulk copy of objects, insert or upsert | Batch, either way | $ usage-based | Medium | Scheduled, not real-time; Salesforce Bulk API batch limits |
| iPaaS (MuleSoft, Boomi, Workato) | Whatever you build; templates help | Any | $$–$$$ subscription plus build | Medium to high | You own design, error handling and monitoring |
| Prebuilt connector app | Vendor-defined objects, often accounts, contacts, orders | Usually two-way | $–$$ subscription | Low | Custom objects and logic may not be covered |
| Custom (Salesforce APIs + Dataverse or Business Central APIs) | Anything | Any | $$$ build plus upkeep | High | Your team maintains it through every release |
Cost levels are relative. Microsoft licenses Power Platform and Azure services per user or per use, and iPaaS vendors quote by connectors and volume, so price the option with the record volumes you actually expect.
Which option fits you
Five questions, about a minute. The result is a starting point, not a final architecture.
Which Salesforce Dynamics 365 integration fits you?
Object and field mapping
Agree on these tables with sales ops and finance before anyone builds a flow. The "system of record" column decides which side wins when both change.
CRM to CRM: Salesforce and Dynamics 365 Sales (Dataverse)
| Salesforce | Dynamics 365 Sales (Dataverse) | Direction | System of record | Notes |
|---|---|---|---|---|
| Account | Account | Two-way or one-way | One system per account segment | Split by region, business unit or owner team; never "whoever edited last" |
| Contact | Contact | Follows its account | Same as the account | Match on stored ID first, email second |
| Lead | Lead | Usually none | Each CRM for its own leads | Sync leads only for a defined handoff between teams |
| Opportunity | Opportunity | One-way to the reporting side | The CRM where the deal is worked | Map stages and probabilities explicitly; amounts in one currency or with currency code |
| Product, price book | Product, price list | From the ERP or one CRM | The system that bills | Different structures: price books vs price lists with unit groups |
| Case | Case (incident) | Only if both teams serve the same customers | The support team’s CRM | Often a read-only view is enough |
| Owner (user or queue) | Owner (user or team), business unit | Mapped, not synced | Each CRM | Keep a user mapping table; unmatched owners go to a default |
CRM to ERP: Salesforce and Business Central or Dynamics 365 Finance
| Salesforce | Business Central / Finance | Direction | System of record | Notes |
|---|---|---|---|---|
| Account | Customer | SF → D365 on first won deal, billing fields back | Salesforce for sales fields, ERP for billing | Company, currency, payment terms and tax area live in the ERP |
| Product, price book entry | Item, sales price | D365 → SF | ERP | One price book per currency or price group |
| Opportunity or quote | Sales quote or sales order | SF → D365 | Salesforce until synced | Trigger on Closed Won or signed quote, not on every save |
| Custom object or related list | Posted sales invoice, payment | D365 → SF | ERP | Read-only in Salesforce; headers and status, not every line |
| Account fields | Balance, overdue amount, credit limit | D365 → SF | ERP | Useful for renewals and credit holds |
On every synced pair, store the other system’s ID: an External ID field in Salesforce and an alternate key column in Dataverse. Microsoft’s documentation describes alternate keys exactly for this, letting an integration find and upsert a row by an external system’s identifier.
How to set up the integration, step by step
These steps follow the most common path, Power Automate or an iPaaS between Salesforce and Dataverse. A custom build follows the same order with code in place of configuration.
- Write down scope and ownersOne page: which objects sync, in which direction, which system masters each one (per object, and per field where needed), and what is out of scope. Get sign-off from sales ops on both sides and, for ERP flows, the controller.
- Prepare sandboxesA Salesforce sandbox and a Dynamics 365 sandbox environment (or a Business Central sandbox) with realistic data, including your messiest accounts. Never build the first version against production.
- Create dedicated integration usersIn Salesforce, an API-only user with a permission set limited to the synced objects; according to Salesforce Help, supported editions include a limited number of free Salesforce Integration user licenses. In Dynamics 365, an application user registered in Microsoft Entra ID with a security role limited to the same tables. Don’t run flows under a person’s login.
- Add cross-reference fieldsCreate an External ID field in Salesforce for the Dynamics GUID and a text column with an alternate key in Dataverse for the Salesforce ID, on every synced object.
- Build user, picklist and currency mapsA table that maps Salesforce users and queues to Dynamics users and teams, every picklist value to its Dataverse choice, and currencies on both sides. Unmapped values must go to a visible default, not fail silently.
- Match existing records onceExport accounts and contacts from both systems, match them (by domain, tax ID or account number, then by hand), clean duplicates and write both IDs back before you switch on automatic creation.
- Build one direction at a timeStart with the master direction for accounts, then contacts, then opportunities or orders. Use upsert by the stored key everywhere, and skip changes made by the integration user to avoid loops.
- Test edge casesMerges, deletes, owner changes, a picklist value that exists on one side only, a record edited in both systems within a minute, and a burst of bulk updates to see how the flows handle throttling.
- Set up alerts, then go liveRoute failed records to a named owner with the reason, decide who checks the error log daily, and go live outside quarter-end. Watch the first two weeks closely.
Built by Gilzor
Results we’ve shipped
Talk to the people who build it. Tell us about your project and get a free estimate of scope, timeline and cost.
CRM-to-CRM sync pitfalls and how to fix them
| Pitfall | What happens | Fix |
|---|---|---|
| Two masters for one record | Edits overwrite each other; reps lose trust in both CRMs | One master per object, segment or field; the other side is read-only for those fields |
| No cross-reference IDs | Duplicates on every sync; merges in one system break links | External ID in Salesforce, alternate key in Dataverse; upsert, never blind create; handle merges explicitly |
| Ownership models differ | Records land with the wrong owner or the integration user; sharing breaks | Map Salesforce users and queues to Dynamics users, teams and business units; default unmatched owners to a named queue |
| Picklist and choice mismatches | Sync errors or wrong values; Salesforce stores text values, Dataverse choices store a number behind each label | A value-mapping table with a default; freeze picklist changes or add them to a change process |
| Sync loops | An update in one system triggers an update back, forever | Ignore changes made by the integration user; compare values before writing; filter triggers to the fields you sync |
| Deletes not handled | Records deleted in one CRM live on in the other | Sync deletes from the Dataverse side via its delete trigger; for Salesforce, use Change Data Capture or a periodic reconciliation |
| API limits on both sides | Throttling errors at peak, partial syncs | Queue and retry with backoff, honor Retry-After, move bulk work to off-hours batch jobs |
| Too much synced | Licenses, storage and API calls spent on data nobody uses | Sync the shared minimum; show the rest live or in a shared report |
API limits deserve a closer look because a two-way sync hits both platforms at once. On the Dynamics side, according to Microsoft’s documentation, Dataverse service protection limits are counted per user and per web server: by default 6,000 requests and 20 minutes of combined execution time in a five-minute sliding window, and 52 or more concurrent requests. Exceeding them returns a 429 error with a Retry-After header, so your integration must wait and retry. On the Salesforce side, the org has a rolling 24-hour API request allocation that depends on edition and licenses, and the Power Automate connector adds its own per-connection throttle. Check the Salesforce allocation in Setup before you size the sync.
Salesforce with Business Central or Dynamics 365 Finance
A Salesforce Business Central integration is a CRM-to-ERP project, the same quote-to-cash loop as connecting Salesforce to any ERP. A few Microsoft-specific facts shape the design:
- Business Central’s built-in CRM integration is for Dynamics 365 Sales. According to Microsoft’s documentation, it runs through Dataverse and couples items, prices, opportunities, sales orders and posted invoices with Dynamics 365 Sales. It does not connect to Salesforce, so Salesforce needs its own connector, iPaaS or custom build.
- Business Central API v2.0 is the custom route. It is a REST API, enabled by default for Business Central online. Microsoft notes that the standard APIs can’t be extended with extra fields; you copy the API page in AL and publish a custom API instead, so budget for a little AL development.
- Dynamics 365 Finance syncs with Dataverse through dual-write. Microsoft describes dual-write as near-real-time, bidirectional integration between finance and operations apps and Dataverse. If you already run dual-write, connecting Salesforce to Dataverse can give it customer and order data without a second direct link into Finance.
For how the full order-to-cash loop works between a CRM and an ERP, including who creates the customer and how orders lock after sync, see our Salesforce NetSuite integration guide; the design carries over to Business Central almost unchanged. For SAP on the ERP side, see the Salesforce SAP integration guide.
When a custom integration makes sense
Power Automate flows and connector apps handle simple, low-volume syncs well. A custom build, or custom logic inside an iPaaS, pays off when:
- Matching is hard: the same customer exists in both CRMs under different names, with different hierarchies.
- You need field-level mastering, for example sales fields from Salesforce and service fields from Dynamics 365 on the same account.
- Several companies, currencies or business units each follow their own rules.
- Volume or speed is past what per-connection throttles and premium licenses handle economically.
A typical custom build has a small integration service with a queue, OAuth clients for Salesforce and Microsoft Entra ID, idempotent upserts keyed on the stored IDs, Change Data Capture or Dataverse change tracking to pick up changes, a retry and error dashboard, and automated tests for each flow.
Our API integration cost guide breaks down where that money goes, and the data integration cost guide covers migrations and warehouse feeds.
Go-live checklist
Tick what is already done. It shows how ready your integration is for real data.
Salesforce Dynamics 365 go-live readiness
FAQ
Can Salesforce integrate with Microsoft Dynamics 365?
Does Business Central have a native Salesforce integration?
Should we integrate Salesforce and Dynamics 365 Sales or migrate to one CRM?
Is the Salesforce connector in Power Automate free?
How do you avoid duplicates when syncing two CRMs?
How much does a Salesforce Dynamics 365 integration cost?
Where Gilzor fits
Gilzor’s engineers, based in Poland and Cyprus, can map your Salesforce and Dynamics 365 data, decide with you what to integrate and what to consolidate, build the sync on Power Platform, an iPaaS or the platform APIs, and support it after launch. See Gilzor’s Salesforce integration services.
No sales pitch
Get a straight answer for your project
Tell us what you’re building. We’ll reply with options, a rough cost and timeline. If we’re not the right fit, we’ll say so.
CTO of Gilzor. Responsible for architecture and the engineering standards our teams work by.
LinkedIn →Gilzor · Web Development partner
Need a team for your web product?
Services
Web DevelopmentCustom websites and web apps — front-end, back-end, launch and support.→By company type
Selected projects
The team behind them
