Unified commerce architecture on Dynamics 365
By Emil Björk · Microsoft business apps consultant, Gothenburg
What unified commerce actually means on Dynamics 365 — one product master, one pricing engine, one order, one customer across store, web, and call centre — how Commerce delivers it, where headless and Customer Insights fit, and why BC plus Shopify is integrated commerce, not unified.
"Omnichannel" meant a retailer had a store system, a web shop, and a call centre, and had built enough integration between them that a customer could mostly move across. "Unified commerce" means there is one system underneath — one product master, one pricing engine, one order object, one customer record — and the channels are front ends. The difference is not marketing; it decides whether cross-channel returns, real-time inventory, and consistent promotions are configuration or a multi-year integration programme. This guide sets out how Dynamics 365 Commerce delivers the unified shape, and where the edges are.
The four things that must be single
One product master. Commerce products live in headquarters (the Finance and Supply Chain Management product master) with retail-specific enrichment — categories, attributes, images, variants — and are released to channels through assortments. The web shop, the POS, and the call centre read the same product. There is no catalogue sync because there is no second catalogue.
One pricing engine. Trade agreements, price groups, discounts, and promotions are evaluated by the same pricing engine in every channel, running on the Commerce Scale Unit. A promotion set up once applies at the till, in the basket online, and on a call-centre order, subject to channel eligibility. Microsoft has been extending this same engine toward Supply Chain Management sales orders under the unified pricing management feature, which is the direction of travel for B2B retailers who also sell through account managers.
One order. Whether it was created at a register, on the storefront, or in the call centre, the order is a headquarters sales order with an originating channel. Fulfilment, returns, and customer history operate on that object. This is the property that makes "return anywhere" and "buy online, collect in store" straightforward.
One customer. Customers are headquarters customer records, created asynchronously from any channel and consolidated in the global address book. Loyalty, purchase history, and preferences attach to that record.
If a proposed architecture breaks any of these four — a separate PIM that channels read from independently, a storefront with its own promotions engine, an order management layer that owns orders and syncs them down — it is integrated commerce with extra steps. Sometimes that is the right call, but it should be a conscious one.
The runtime shape
Headquarters holds master data and finance. The Commerce Scale Unit (CSU) runs the channel-facing services: pricing, cart, order creation, inventory lookup, customer lookup. Every channel is a client of the CSU — the Store Commerce app, the first-party e-commerce site, the call-centre order-entry forms, and any custom client built on the Commerce SDK.
That client-of-CSU model is what makes headless commerce a first-class option rather than a workaround. A retailer can run a React storefront on Vercel, a native mobile app, and a marketplace connector, all calling the same Retail Server APIs, with cart and pricing behaving identically. The first-party storefront is the quickest path when its templating is good enough; headless is the path when brand experience or existing front-end investment matters more.
Where Customer Insights fits
Unified commerce gives you one transactional customer. It does not give you the marketing view: web behaviour, email engagement, survey responses, the loyalty app. Customer Insights – Data stitches those sources into a unified profile with segments and measures, and Customer Insights – Journeys acts on them. The clean architecture is Commerce as the system of record for identity and transactions, Customer Insights as the analytical and activation layer, and a deliberate decision about which attributes flow back into Commerce for use at the till (clienteling) and which stay in the marketing stack.
The failure mode is running loyalty tiers in Commerce, segments in Customer Insights, and a promotion engine in a third-party email tool, then discovering that three systems disagree about who is a gold customer.
Inventory across channels
Unified inventory is the piece that requires the most operational discipline. Commerce reads on-hand from headquarters and from channel databases; the Inventory Visibility add-in for Supply Chain Management provides the near-real-time, cross-channel picture that ship-from-store and endless aisle depend on. Without accurate store counts, unified commerce promises availability the store cannot honour. See endless aisle and click-and-collect for the fulfilment side.
What still needs partners
Even on a genuinely unified platform, expect partners for payments beyond the reference Adyen connector, tax engines for complex US sales-tax estates, fiscalisation outside the countries Microsoft's framework covers, marketplace connectors, advanced search and merchandising on the storefront, and returns-management or fraud-screening specialisms. None of those break the unified shape as long as they act as services to the CSU rather than as competing systems of record.
Business Central plus Shopify
For SMB retailers, Business Central with the Shopify connector and a partner POS is a good stack, but it is integrated commerce. Shopify owns the online product presentation, its own discounts, and the online order until it syncs; the POS ISV owns store transactions; BC owns inventory and finance. Cross-channel returns, consistent promotions, and unified customer history require deliberate integration work, and some of it will not be possible. That is acceptable for one to a few dozen stores with modest omnichannel ambitions. When the requirements list starts reading like the four "singles" above, the honest answer is Commerce, and the retail overview covers that trade-off.
Decision test
Ask one question of every component in the proposed architecture: which system is the source of truth for products, prices, orders, and customers, and does this component read from it or compete with it? If the answer is "compete", either the component goes or unified commerce is not what is being built.
Further reading
Related guides
- Click-and-collect fulfilment in Dynamics 365 CommerceHow buy-online-pick-up-in-store works end to end in Dynamics 365 Commerce — delivery modes, order sourcing, store-side fulfilment in the Store Commerce app, payment capture at pickup, and the gaps you fill with partners.
- Endless aisle and cross-store inventory in Dynamics 365 CommerceHow Dynamics 365 Commerce supports endless-aisle selling — customer orders from the POS, cross-store inventory lookup, deposits, fulfilment from another location, and what to build versus buy for kiosks and sales-credit rules.
- Multi-store rollout patterns for Dynamics 365 CommerceHow to structure and roll out Dynamics 365 Commerce across many stores — organisation hierarchy, scale units, data distribution, register setup, and the wave plan that keeps a 200-store rollout from stalling.
- Seasonal forecasting for retail on Dynamics 365How to forecast seasonal retail demand with Dynamics 365 — Demand Planning for store-SKU seasonality, Commerce replenishment for allocation, BC's forecast extension for small retailers, and the open-to-buy and promotion-lift gaps that still live in spreadsheets or ISVs.
- Dynamics 365 for retailHow Dynamics 365 fits retail — Commerce for omnichannel, Business Central for SMB retailers, and the typical retail stack.
Spot something wrong or want a topic covered? Send a correction or a topic request — both are welcome.