Which direction should the data flow - Dynamics to Salesforce or the other way?

Usually both, but for different objects. Master data and financial reality - accounts, posted invoices, credit limits, order status - are authoritative in Dynamics 365 and flow to Salesforce. Pipeline and relationship data - opportunities, new leads-turned-accounts, contact edits - are authoritative in Salesforce and flow back. The integration's job is to make each field one-directional so the two systems never fight over the same value.

How do you match a Dynamics 365 account to the right Salesforce account?

Not by name - names drift and duplicate. We agree a stable key up front, typically the Dynamics account number or a shared external ID stored on both sides, and write it into a Salesforce external ID field so every future sync is an upsert against that key. Where no shared key exists yet, we run a one-time reconciliation to seed the mapping before go-live, so you do not start by creating thousands of duplicates.

Can salespeople see invoices and open balances from Dynamics in Salesforce?

Yes, and it is one of the most common reasons to build this. Posted invoices, payment status, and open receivables from Dynamics 365 Finance appear on the Salesforce account as related records or rolled-up fields, so a rep sees whether a customer is on credit hold before they promise a delivery. We keep those read-only in Salesforce so the ERP stays the single source of financial truth.

Does this work with Dynamics 365 Business Central as well as Finance & Operations?

Yes, but the connection differs. Business Central exposes clean OData v4 and standard APIs; Finance & Operations (and the Dataverse-backed CE apps) use the Dataverse Web API and OData with different entity names and pagination. We confirm which Dynamics 365 app you actually run - they share a brand, not a data model - and build against the right API surface rather than assuming one covers the other.

Who operates it after go-live, and what happens when an API changes?

We do. The pipeline runs on cloud-native, fully EU-hosted infrastructure that we monitor. When Microsoft rev's the Dataverse API or Salesforce enforces a new API version or lowers a rate limit, that is our problem to fix under contract, not something your admins discover when the sync silently stops. You get a named owner, alerting, incident response, and an SLA.

Dynamics 365 Salesforce integration

What a Dynamics 365 to Salesforce integration actually does

Sales lives in Salesforce. The money, the inventory, and the fulfilled reality of the customer relationship live in Dynamics 365. When those two run as islands, a rep quotes a customer who is on credit hold, finance chases an invoice against an account whose owner changed three months ago, and everyone re-keys the same company into two systems with two slightly different spellings.

A Dynamics 365 to Salesforce integration removes that gap. It gives sales a real customer 360 - order history, open balances, and credit status pulled from the ERP - while feeding won opportunities and clean contact data back into Dynamics so operations acts on what sales actually closed. The point is not to move rows. It is to make each system authoritative for the fields it owns and consistent everywhere else.

What data moves

Dynamics 365 object / event	Becomes in Salesforce	Notes
Customer / Account	Account (upsert on external ID)	Dynamics account number is the match key, not the name
Contact	Contact linked to the Account	De-duplicated against existing Salesforce contacts by email + account
Product / Released item	Product2 / PricebookEntry	Unit of measure and price list mapped to the right Salesforce price book
Sales order	Order (read reference)	Status and fulfilment stage surfaced so reps see delivery reality
Posted invoice	Invoice record / related list	Read-only in Salesforce; ERP stays the source of financial truth
Payment status / open balance	Rolled-up field on Account	Drives credit-hold visibility before a rep promises a deal
Salesforce opportunity (won)	Sales order / quote in Dynamics	Reverse direction: closed pipeline becomes an order to fulfil

The exact object mapping, which fields are authoritative on which side, and which are read-only are agreed once and encoded in the pipeline. After that, nobody re-maps them by hand.

The details that break naive syncs

A generic connector or a nightly export gets you the happy path and leaves the expensive edge cases on your admins:

Identity and dedup. Salesforce and Dynamics both love to create duplicates. Matching on company name guarantees them. The integration matches on a stable external ID written to both sides, and does a real reconciliation pass before go-live so you inherit a clean mapping instead of thousands of near-duplicate accounts.
Which side wins a field. If both systems can edit the account’s billing address, the last write wins and it is usually wrong. Every field needs an owner: address and credit from Dynamics, opportunity and activity from Salesforce. A naive two-way sync without field-level ownership creates a flapping loop.
Currency, tax, and price lists. Dynamics posts invoices in a document currency with an exchange rate and tax codes; Salesforce has its own multi-currency and price books. Amounts have to carry currency and rate, not just a number, or the pipeline reported in Salesforce and the ledger in Dynamics quietly diverge.
API limits and pagination. Salesforce enforces a 24-hour API request allocation and Bulk API rules; the Dataverse Web API paginates and throttles differently again. A full re-sync that ignores this burns your Salesforce daily limit by lunchtime. The pipeline batches, backs off, and uses bulk endpoints where volume warrants.
Delta vs full sync. You cannot re-read every account every hour. The integration tracks change tokens (Dataverse change tracking, Salesforce SystemModstamp) and moves only what actually changed, with periodic reconciliation to catch anything a webhook dropped.
Partial failures. When 40 of 5,000 records fail validation, the run must not roll back the 4,960 good ones or silently swallow the 40. Failed records go to a dead-letter queue with the reason, get retried, and surface as an alert - not as a number that is quietly wrong next quarter.

How we build and run it

We treat this as a pipeline, not a scheduled export. Changes are picked up from each system (by change token or webhook), validated, transformed into the agreed mapping, and written with upserts against the stable external ID so a retry or a re-run never creates a duplicate.

The pipeline is idempotent end to end: every record carries a stable key, so re-processing the same change is a no-op rather than a second account. It runs on cloud-native, fully EU-hosted AWS infrastructure, so account, contact, and financial data never leaves the EU - which keeps your DPA / AVV and your GDPR obligations clean when both a Microsoft and a Salesforce cloud are in scope.

Then we keep it running. Monitoring, alerting, incident response, and - critically - tracking Salesforce API version deprecations and Dataverse API changes are our responsibility under contract. When Microsoft or Salesforce changes something, we adapt the pipeline before it becomes your outage. You get a named owner and an SLA, not a middleware licence and a support queue.

When this integration is worth building

If you have a few dozen accounts and one person who calmly keeps both systems tidy, you do not need this, and we will say so. A one-off import or a light point tool is fine when volume is low and nobody is bidirectional.

It earns its place when the same customers live in both systems at scale, when sales needs live credit and order status to stop over-promising, when duplicates and manual re-keying are eating admin time, or when finance and sales are quietly working from two different versions of the truth. At that point a managed, EU-hosted pipeline that someone else owns and operates is cheaper than the reconciliation it replaces.