Some companies searching for a way to connect Dynamics 365 to their store already have a connector installed. Microsoft preinstalls its Shopify Connector in new Business Central online environments, yet it does not serve Business Central on-premises, WooCommerce or Magento storefronts, or Dynamics 365 Finance and Supply Chain Management. That is the first fork in any Microsoft Dynamics ecommerce integration. The approach that tends to hold up makes Dynamics the owner of items, prices, stock and the ledger, lets the store own the checkout, and then uses the lightest connection the edition allows. With ownership settled, the team stops reconciling two versions of the same order.
Which connection that turns out to be depends less on preference than on three facts: the Dynamics 365 application in use, where it is hosted, and how many exceptions the store’s orders carry. Teams planning ecommerce ERP integration around Dynamics usually get firmer estimates when they answer those three questions before comparing tools, because each answer rules some routes in and others out.
Which Dynamics 365 Application Holds Your Finance and Inventory?
Dynamics 365 is a family of applications rather than one product, and the two that usually hold finance and stock for a retailer integrate in quite different ways.
Dynamics 365 Business Central Online
Business Central is Microsoft’s ERP for small and mid-sized companies. In its cloud version it includes Microsoft’s own Shopify Connector, preinstalled in new environments and available from Microsoft’s Marketplace for older ones; the organisation needs both a Business Central licence and a Shopify licence to use it. For every other storefront, Business Central exposes a REST API, version 2.0, that any language able to call REST endpoints can use.
Business Central On-Premises
Microsoft’s own documentation states that the Shopify Connector isn’t available for on-premises deployments. On-premises installations can still expose the same APIs once they are enabled, but the integration then runs through the company’s own network, so hosting, firewall rules and certificates become part of the project scope.
Dynamics 365 Finance and Supply Chain Management
Larger organisations often run Finance and Supply Chain Management, which Microsoft also calls the finance and operations apps. The same documentation confirms the Shopify Connector does not work with Supply Chain Management. Integration here runs through data entities exposed over OData, batch data APIs and business events, usually coordinated by an integration platform or custom middleware. If the system in question is actually Dynamics 365 Sales, the customer relationship application, the project is a CRM integration rather than a finance and stock one, and the design questions change accordingly.
Building a Single Source of Truth Between Dynamics 365 and the Store
A single source of truth rarely means one database. It means every type of record has one system allowed to change it, while every other system holds a copy it treats as read-only. Without that rule, an integration simply moves disagreements between systems faster than staff could. A typical split for a store connected to Dynamics 365 looks like this:
- Items and units of measure: Dynamics. Purchasing, costing and stock valuation depend on them. Marketing copy, images and SEO fields usually stay in the store or a PIM.
- Prices and discounts: usually Dynamics. When finance sets prices by customer group or contract, the ERP owns them and publishes them to the store. Short promotional pricing can sit in the store if the ledger only needs the final amount charged.
- Available stock: Dynamics or the warehouse system. Availability is calculated where stock is managed and published to the store per location. The store’s figure is a copy that ages between updates.
- Orders and payments: the store, then Dynamics. Orders are created at checkout and handed to Dynamics exactly once, carrying an identifier both systems keep so a retried message cannot create a duplicate sales order.
- Customers: decided case by case. Guest buyers may not need an individual customer card in the ERP at all, while trade accounts with credit terms and agreed prices are typically mastered in Dynamics.
Key takeaway: A Microsoft Dynamics ecommerce integration works when ownership is decided for each record type before any tool is chosen. The connector or middleware enforces those decisions; it cannot make them on the business’s behalf.
Route One: Business Central and Shopify Through Microsoft’s Connector
Where the stack is Business Central online and Shopify, the built-in connector is usually the sensible starting point. Microsoft maintains it, publishes its source code in the BCApps repository, and offers integration events covering orders, products, customers, inventory, shipping and returns, so partners can adjust behaviour without forking it. Several Shopify stores can be connected to one Business Central environment, each configured on its own shop card.
Its limits come from the same design. According to Microsoft’s technical FAQ for the Business Central Shopify Connector, the connector pins one version of Shopify’s GraphQL Admin API and adopts a newer one only in Business Central’s major releases, while Shopify supports each version for 12 months. The connector shipped in April 2026, for example, relies on API version 2026-01, which remains accessible until 31 December 2026. A company that postpones Business Central updates for too long can therefore find synchronisation blocked, which makes the ERP update calendar part of the store’s maintenance plan.
Extension has boundaries too: Microsoft keeps the connector’s internal code private and exposes events plus a few public functions. Requirements outside those hooks, such as an approval step before high-value orders post or a pricing rule the connector does not model, tend to push the design towards custom middleware running alongside the connector or replacing part of it.
The connector is often enough when the store sells standard items from a limited number of locations, prices follow Business Central price lists, and finance accepts how orders, payments and refunds are mapped. A trial with partial refunds, edited orders and bundles shows quickly whether that holds. Our earlier article on when a packaged connector beats a bespoke build, and when it does not covers that decision for ERPs generally.
Route Two: Business Central APIs and Middleware for Other Platforms
WooCommerce, Adobe Commerce, BigCommerce and custom storefronts reach Business Central through API v2.0. The standard API pages cover items, customers, sales orders and invoices, but Microsoft’s API reference notes that extending them with additional fields isn’t currently possible. Teams that need extra fields copy the API page in AL, Business Central’s development language, and publish a custom API, which then becomes code the business has to version and maintain.
Change detection is where estimates tend to be optimistic. Business Central can send webhook notifications when entities such as items, customers, sales orders or sales invoices change, but each notification identifies the changed record rather than carrying its data, so the subscriber calls back for the details. Microsoft’s webhook documentation also describes behaviour the design has to absorb. Subscriptions expire after three days unless renewed. Notifications wait 30 seconds after the first change, and if more than 1,000 records change in that window, one collection notification replaces the individual ones. When the subscriber is unreachable, Business Central retries over 36 hours, but an unexpected response code deletes the subscription.
For that reason, middleware that renews subscriptions, handles collection notifications and runs a scheduled reconciliation is safer than relying on webhooks alone. Throughput needs similar care. Business Central online applies per-user limits to OData requests, currently 6,000 within a five-minute sliding window, and answers with HTTP 429 when they are exceeded. A full catalogue refresh pushed through one integration account can meet that ceiling, so batching, back-off and retry logic belong in the first release rather than the second.
The trade-off of this route is ownership: middleware needs hosting, monitoring, documentation and a named person or partner accountable when a sync stops.
Route Three: Finance and Supply Chain Management at Higher Volumes
Finance and Supply Chain Management exposes its data through data entities, and Microsoft’s integration guidance separates two inbound patterns. OData calls are synchronous: business logic runs immediately and the caller receives success or an error, which suits real-time exchanges at modest volume, such as reading an order’s status. Batch data APIs are asynchronous: a data package is queued for import and the caller has to poll for the outcome. Microsoft’s rule of thumb is to use the batch API once volumes exceed a few hundred thousand records, and on-premises deployments support only the Data management package REST API.
For an ecommerce store, that often means orders arrive in a queue held by middleware and post in small batches, while product, price and stock changes leave Dynamics as business events or scheduled exports. Microsoft describes business events as lightweight notifications, advises against using them to export data, and states that the order in which events are emitted is not guaranteed to match the order of delivery. Each event carries a control number so the consumer can discard duplicates. A reliable design treats an event as a prompt to read the current record, not as the record itself.
Stock may justify a dedicated layer. Supply Chain Management licences include the Inventory Visibility Add-in, a separate service that accepts inventory changes and soft reservations from external channels in real time. Without soft reservations, Microsoft notes, a channel has to wait until its order is synchronised to and processed by the ERP before inventory reflects it. Retailers selling the same stock through several channels may find that worth the effort; a single webshop with steady volume may manage with frequent exports.
Comparing the Three Microsoft Dynamics Integration Routes
| Route | Often fits when | Main strength | Main limitation | Who maintains it |
|---|---|---|---|---|
| Microsoft Shopify Connector (Business Central online) | Shopify store, standard items, price lists and few order exceptions | Maintained by Microsoft; quick to enable and well documented | Fixed mappings; online only; extension limited to published hooks | Business Central administrator, with partner support for extensions |
| Business Central API v2.0 with a connector or middleware | Non-Shopify storefronts, or Shopify needs beyond the connector | Works with any platform; custom validation and routing rules | Custom API pages, webhook renewal and per-user rate limits to manage | Developer or retained partner with monitoring in place |
| Finance and Supply Chain Management via data entities and an integration platform | Higher volumes, several legal entities, warehouses or channels | Handles batch volumes; event-driven updates | Highest design and testing effort; asynchronous errors must be polled | Integration team or long-term partner |
The connector looks modest beside the other two, and for many Business Central and Shopify stores that is its advantage: fewer moving parts and a vendor keeping it current. Middleware earns its cost when the exceptions it handles would otherwise land on staff as manual corrections.
Which Integration Route Fits Your Business?
Use the built-in connector when Business Central online and Shopify are both in place, the catalogue and price lists fit the connector’s model, and the company can keep Business Central current.
Choose middleware on Business Central’s API when the storefront is WooCommerce, Adobe Commerce or custom, or when orders need validation, splitting or enrichment before they post. It also helps when a 3PL or marketplace joins the same flows, because one layer can route and log all of them.
Plan an integration platform on Finance and Supply Chain Management when volumes are high, several legal entities or warehouses are involved, or the same stock serves several channels. Trade channels add requirements of their own, and the integration and storefront are often designed together when the store offers trade customer portals with account-specific pricing.
Consider waiting when order volumes are low and stable, or when the business is about to change Dynamics edition or hosting. An integration built against a system due for replacement can mean paying for the same work twice.
A Practical Order of Work for a Microsoft Dynamics Ecommerce Integration
The sequence below settles the expensive decisions while they are still cheap to change.
- Confirm the application, edition and hosting. The answer determines which routes, APIs and limits apply.
- Write the ownership table. For each record type, name the owning system, the direction of flow, and the rule that applies when two systems disagree.
- Map the structures. Match Dynamics locations or warehouses to store locations, item variants to product variants, customer price groups to store price lists, and payment methods to ledger accounts.
- Design for failure before success. Decide how orders queue, how retries avoid duplicates, who is alerted when a posting fails, and how a daily reconciliation compares orders, stock and payments.
- Test with real history. Replay several weeks of genuine orders, including refunds, edits, discounts and trade orders, in a Dynamics sandbox and ask finance to check the documents produced.
- Go live in stages, then monitor. Start with one store or location, and keep alerts and reconciliation running after the project team has moved on.
The order matters more than the tooling. In Astravelo’s Magento 2 build with Horizon ERP and real-time inventory synchronisation, WD Market treated multi-store architecture, catalogue structure and ERP connectivity as foundational priorities before optimising individual storefront features. The case study reports roughly 75% less manual work across four countries and a catalogue of more than 50,000 SKUs. The ERP there was Horizon rather than Dynamics, but the lesson transfers: the integration was planned as business infrastructure from the start, not added after launch.
Internal expert input required: confirm whether WD Market has delivered a Microsoft Dynamics 365 integration (Business Central or Finance and Supply Chain Management) and, if so, add one verified example naming the route used and how webhook expiry or API throttling was handled.
Mistakes That Keep Dynamics 365 and the Store Out of Step
- Enabling the connector without reviewing its mappings. Default settings decide how customers, taxes and refunds are created in Business Central, and finance may only notice the effect when month-end figures fail to match.
- Letting both systems edit the same field. When prices or product titles can be changed in Dynamics and in the store admin, the next synchronisation quietly overwrites one side’s work.
- Treating notifications as complete data feeds. Expired webhook subscriptions, collection notifications and events delivered out of order can each leave gaps that only a scheduled reconciliation will reveal.
- Sending every call through one integration user. Because Business Central online throttles per user, a single busy account can receive 429 responses while the environment as a whole still has capacity.
Making Dynamics 365 the Record Every Channel Trusts
Connecting Microsoft Dynamics 365 to an ecommerce store starts with knowing which Dynamics application is in use and where it runs. Business Central online with Shopify can often rely on Microsoft’s connector, provided the update calendar is respected. Other storefronts, and requirements beyond the connector’s hooks, lead to Business Central’s API with middleware, while Finance and Supply Chain Management calls for an integration layer built around data entities, batch imports and business events. In each case, the single source of truth comes from deciding which system owns every record and designing for failed and duplicated messages. The next step is to write that ownership table and test it against the store’s least typical orders.
From Two Sets of Numbers to One Ledger the Team Trusts
WD Market’s integration work spans custom middleware, error handling with automatic retries and logs, and ongoing data reconciliation, and Microsoft Dynamics 365 is one of the ERP systems its integration team connects stores to. A review usually begins with the ownership table described above and a sample of orders that currently need manual correction. To see how that work is scoped and supported, explore WD Market’s ERP and CRM integration services.
To talk through your Dynamics 365 set-up, contact our engineering team. Shorter observations from integration and store-operations projects are shared on WD Market’s LinkedIn page.
Questions About Connecting Dynamics 365 to an Ecommerce Store
Can the Shopify Connector be used with Business Central on-premises?
No. Microsoft makes the Shopify Connector available only for Business Central online, and it also excludes environments that use the Embed App format. A business running Business Central on-premises can still connect Shopify by enabling the Business Central APIs and placing a third-party connector or middleware between the two systems. Companies already planning a move to the cloud version may prefer to schedule the integration after it.
How often should stock synchronise between Dynamics 365 and the store?
It depends on how quickly each product sells and how much buffer the business keeps. Fast-moving items with thin stock may need near-real-time updates driven by webhooks or business events, while slow movers can follow a schedule. Either way, a periodic reconciliation against Dynamics catches notifications that were delayed or missed. Retailers on Supply Chain Management selling through several channels can also use soft reservations in the Inventory Visibility Add-in to reduce overselling.
Can WooCommerce or Adobe Commerce connect to Dynamics 365 Business Central?
Yes, through Business Central’s REST API rather than Microsoft’s Shopify Connector. Options range from third-party connectors to middleware built around the store’s own rules. The main points to check are whether the standard API pages carry every field the store needs, since adding fields means publishing a custom API, and how the design renews webhook subscriptions and stays within per-user request limits. Projects of this kind are usually scoped through data mapping and integration architecture work before development begins.
How long does a Dynamics 365 ecommerce integration take?
A straightforward Business Central and Shopify set-up on Microsoft’s connector is mainly configuration and testing. Middleware projects take longer. WD Market’s published timeline allows around one week for architecture and data mapping, two to six weeks of development, one to two weeks of testing and validation, and a week to go live and stabilise. Multi-entity Finance and Supply Chain Management environments are scoped individually because the number of flows varies widely.