Microsoft Dynamics 365 F&O and Shopify integration

What moves between them

The main flow runs from Shopify into Microsoft Dynamics 365 F&O. When an order is placed and paid, ml-connector matches or creates the Shopify customer in F&O through the CustomersV3 entity and writes the order through the sales order entities, with each line resolved to a released product and the correct main accounts and financial dimensions. Shopify Payments payouts and refunds are read and applied as CustomerPaymentJournalLines so the ledger reconciles to the bank deposit. In the reverse direction, F&O released-product and on-hand inventory changes are written to the Shopify product catalog so prices and stock on the storefront match the ERP. Orders sync near real time on Shopify webhooks; payouts and catalog updates run on a schedule you set.

How ml-connector handles it

ml-connector stores both credential sets encrypted: the F&O tenant id, environment host, client id, and client secret used to mint the Entra ID bearer token on the environment .default scope, refreshed before its roughly one-hour expiry, and the Shopify store subdomain and offline access token. Each Shopify webhook is verified by recomputing the HMAC-SHA256 of the raw body with the client secret and rejecting a bad signature with 401, never 200, and the X-Shopify-Webhook-Id is stored so a redelivered event is skipped. Shopify orders carry no GL accounts, so the connector resolves the customer by email, maps each line to an F&O released product, and passes financial dimensions as the configured display string against the chosen legal entity. Because F&O Business Events are stub payloads on a batch thread and have no signature, the F&O side is polled over OData with server-driven paging and the @odata.nextLink cursor rather than driven by a push. OData has no idempotency key and rejects a duplicate natural key, so each order is deduplicated on the Shopify GID and a BullMQ jobId and written as an idempotent upsert. Both sides throttle: F&O returns HTTP 429 with a Retry-After header and Shopify returns 429 or a GraphQL THROTTLED cost error, so calls back off and retry. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A direct-to-consumer outdoor gear brand with around 80 employees sells through a Shopify storefront and runs Microsoft Dynamics 365 F&O for finance, inventory, and fulfillment across two warehouses. Before the integration, an accountant exported Shopify order and payout reports each week and keyed the sales orders and fees into F&O by hand, while the warehouse tracked stock in two places that drifted apart and left customers buying items that were already gone. With Shopify and Microsoft Dynamics 365 F&O connected, every paid order lands as a sales order against the right items and dimensions, payouts reconcile to the deposits as payment journal lines, and F&O on-hand changes flow to the storefront. Orders ship sooner, the books match the bank, and the catalog stays accurate.

What you can do

• •Create Shopify orders as Microsoft Dynamics 365 F&O sales orders against the correct released products and dimensions.
• •Match or create Shopify customers in F&O through CustomersV3 by email so sales land on the right account.
• •Apply Shopify Payments payouts and refunds as F&O customer payment journal lines that reconcile to the bank.
• •Push F&O released-product, price, and inventory changes back to the Shopify product catalog.
• •Verify Shopify HMAC-SHA256 webhooks, poll F&O over OData, and retry on HTTP 429 with a full audit trail.

Questions

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

Most data moves from Shopify into Microsoft Dynamics 365 F&O: orders become sales orders, customers are matched or created through CustomersV3, and payouts post as customer payment journal lines. Released-product, price, and inventory updates move the other way, from F&O to the Shopify catalog. Shopify has no general ledger, so all accounting postings happen on the F&O side.

How are Shopify orders turned into accounting entries when Shopify has no chart of accounts?

Shopify is an e-commerce platform, not an accounting system, so it carries no GL accounts. ml-connector resolves the Shopify customer by email, maps each order line to an F&O released product and main account, and passes financial dimensions as the configured display string against the chosen legal entity. Tax and fees are mapped to the matching F&O accounts during the write.

Does Microsoft Dynamics 365 F&O push order data, or does ml-connector poll for it?

The connector polls F&O over the OData API. F&O Business Events can push, but the payloads are lightweight stubs processed on a batch thread with no signature header, so they are not relied on for finance reads. The connector pages through OData with the @odata.nextLink cursor and deduplicates writes on the Shopify GID and a job id, since OData has no idempotency key.