Sales teams live in Salesforce. Finance and operations live in Dynamics 365. The integration between them fails in a predictable way: someone decides to sync everything, both systems end up with conflicting versions of the customer, and nobody trusts either. The integrations that work start by deciding, per field, which system owns the truth, and then sync a deliberately short list.
Decide ownership before you decide technology
| Data | Usually owned by | Flows to |
|---|---|---|
| Leads, opportunities, activities | Salesforce | Stays in Salesforce |
| Account name, addresses, contacts | Salesforce until the first order, then Dynamics 365 | Both, with one owner per field |
| Credit limit, payment terms, tax setup | Dynamics 365 | Read-only in Salesforce |
| Products and list prices | Dynamics 365 | Salesforce, read-only |
| Quotes | Salesforce | Dynamics 365 only when converted to an order |
| Orders, invoices, payments | Dynamics 365 | Salesforce, read-only status |
The pattern is consistent: commercial activity flows one way, financial facts flow the other, and each field has exactly one owner. A sales user can see the invoice status; they cannot change the credit limit.
What to sync
- Accounts and contacts once an opportunity is won, with a shared customer ID
- Products and prices from Dynamics 365 to Salesforce on a schedule
- Orders from Salesforce to Dynamics 365 at the point of conversion
- Order, shipment and invoice status back to Salesforce
What to leave alone
- Opportunities and pipeline. Finance does not need them in the ERP; reporting can join the two systems.
- Every custom field someone added in Salesforce in 2019.
- Real-time sync for data that changes once a month. A scheduled run is simpler and easier to reconcile.
Technology options
For Dynamics 365 Finance & Operations, orders and customers go through data entities, either directly or via Dataverse dual-write where Customer Engagement is also in play. Power Automate handles simple scheduled flows; Azure Logic Apps or Service Bus handle volume, retries and queuing. Salesforce exposes everything through its REST API. The design decision that matters is the one above, not the tool.
Reconciliation, again
A daily report: orders converted in Salesforce today, orders created in Dynamics 365 today, differences listed. It is the single most useful artefact in the whole integration and it takes an afternoon to build.
A worked design for a typical B2B company
Sales manages leads and opportunities in Salesforce. When an opportunity is won, the account is checked against Dynamics 365 by a shared external ID; if it does not exist, the customer is created in Dynamics 365 from the Salesforce account with a default customer group, and the Dynamics 365 customer number is written back to Salesforce. From then on, address and contact changes made in Salesforce flow to Dynamics 365, while credit limit, payment terms and tax setup are maintained in Dynamics 365 and shown read-only in Salesforce.
Products and list prices are published from Dynamics 365 to Salesforce every night. Quotes are built in Salesforce; when a quote is accepted, a sales order is created in Dynamics 365 and its number returned to the opportunity. Shipment and invoice status update the Salesforce order record so that sales can answer “where is my order” without asking operations. Each morning a reconciliation report lists orders converted yesterday and orders created in Dynamics 365 yesterday, with any differences.
Decisions to make before the first line of code
- Which identifier links the account in both systems, and who creates it
- What happens when sales creates a customer that already exists under a slightly different name
- Whether a quote can be converted if the customer is on credit hold in Dynamics 365
- How product bundles and price lists in Salesforce map to items and trade agreements in Dynamics 365
- Who is told, and how, when a sync fails
Signs an existing integration needs attention
Duplicate customers appearing in Dynamics 365. Sales asking operations for order status by email. Prices in Salesforce that differ from the invoice. An integration user whose password expired and nobody noticed for a week. Each of these is a design gap, not a technology failure, and each is fixed by deciding ownership and adding reconciliation.
Three versions of the customer across systems? See how we design integrations or book a consultation.
Frequently asked
Should we use dual-write for Salesforce?
Dual-write connects Finance & Operations with Dataverse, which suits Dynamics 365 Customer Engagement. For Salesforce, a data-entity or middleware integration is the usual route, with Dataverse involved only if you also run Customer Engagement.
Real-time or scheduled?
Orders at conversion are worth near-real-time. Products, prices and most customer data are fine on a schedule. Fewer real-time flows means fewer things to break.
Can we fix an integration someone else built?
Yes. We document what it does, decide ownership per field with you, then stabilise or rebuild it on supported patterns.