Microsoft Dynamics 365 F&O and Microsoft Dynamics 365 Sales integration

What moves between them

The primary flow runs from Microsoft Dynamics 365 Sales into Microsoft Dynamics 365 F&O. When an opportunity is won or a quote becomes a sales order in CRM, ml-connector creates or updates the matching account as a customer in the ERP and writes the order with its line items against the right legal entity. In the other direction, released products, prices, and customer master changes flow from the ERP back into Sales so reps quote against live catalog data. Because Sales has no general ledger, ml-connector never posts financial entries or GL data into CRM. Sync runs on change tracking delta reads and Dataverse webhooks from Sales, with a scheduled poll of the ERP to pick up product and customer changes.

How ml-connector handles it

Both systems use OAuth2 client credentials through Microsoft Entra ID, so ml-connector stores each credential set encrypted and requests a separate access token per environment host, since the OAuth scope is the environment URL plus /.default and differs on each side. It accepts both tenant-specific hosts as credential fields because neither product has a shared base URL. From Sales it uses change tracking delta tokens and registered Dataverse webhooks to detect new and changed records, then reads full detail through the Web API. Writing into the ERP, it fully specifies each OData entity key including dataAreaId, since records are scoped to a legal entity, and it maps CRM accounts to ERP customer accounts and CRM products to released product numbers before any order is written. Customer and product master records are aligned first so every order line references an item and customer that already exist in the ERP. Both APIs return HTTP 429 with a Retry-After header under load, so ml-connector backs off and retries. Neither side offers a built-in idempotency key, so it dedups on natural business keys such as the order number and on the Business Events ControlNumber to avoid creating an order twice. The first ERP call after an environment restart can be slow because OData metadata is not cached, and Dataverse lookups like the customer field are polymorphic, so the connector resolves whether each points to an account or a contact. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A regional industrial equipment distributor with roughly 200 staff runs Microsoft Dynamics 365 Sales for its field reps and Microsoft Dynamics 365 F&O for finance and warehouse fulfillment. Before the integration, when a rep closed a deal, an order coordinator rekeyed the customer and every line item into the ERP by hand, which delayed fulfillment and introduced mismatched part numbers and prices. With the two systems connected, a won opportunity becomes an ERP sales order within minutes, mapped to the correct legal entity and customer account, while released products and prices flow back so reps always quote current catalog data. Orders ship faster and the part-number errors that used to surface at picking are gone.

What you can do

• •Create ERP customers and sales orders from won opportunities and accepted orders in Microsoft Dynamics 365 Sales.
• •Send released products, prices, and customer master changes from the ERP back into Sales so reps quote live data.
• •Detect CRM changes with Dataverse change tracking delta tokens and registered webhooks rather than full re-fetches.
• •Bridge OAuth2 client credentials across both Entra ID environment hosts with a separate scoped token for each side.
• •Dedup orders on natural keys and the Business Events ControlNumber, with retries and a full audit trail on every record.

Questions

Which direction does data move between Microsoft Dynamics 365 F&O and Microsoft Dynamics 365 Sales?

The primary flow is from Sales into the ERP. Won opportunities and accepted orders become customer and sales order records in Microsoft Dynamics 365 F&O, while released products, prices, and customer master data flow back into Sales. Because Sales has no general ledger or accounting dimensions, ml-connector never posts GL or financial entries into CRM.

How does ml-connector handle authentication when both systems use Microsoft Entra ID?

Both sides use OAuth2 client credentials through Microsoft Entra ID, but the OAuth scope is built from each environment host plus /.default, so they are not interchangeable. ml-connector stores both credential sets encrypted and requests a separate access token per environment, refreshing each before it expires. The Sales app must also be registered as an Application User with a Dataverse security role for its token to work.

How does the integration detect changes without duplicating records?

On the Sales side it uses Dataverse change tracking delta tokens and registered webhooks to pick up new and changed records, then reads full detail through the Web API. Neither system offers a built-in idempotency key, so ml-connector dedups on natural business keys such as the sales order number and on the Business Events ControlNumber the ERP emits. It also follows the Retry-After header when either API returns HTTP 429.