Dynamics 365 Commerce Guide: A Full Tour of the Omnichannel Commerce Stack

Quick Answer: This dynamics 365 commerce guide covers the parts that matter in a real rollout. Commerce is Microsoft’s enterprise e-commerce and omnichannel application, formerly Dynamics 365 Retail. It manages the product and variant catalogue, the pricing and promotion engine, carts and orders across channels, fulfilment including store fulfilment, and product recommendations, and it exposes headless storefronts through Commerce APIs hosted on Dataverse. It is a strong fit when you run a website, stores and a call centre off one catalogue, and a poor fit for a small merchant who needs a shop online next week.

If you are completely new to Microsoft’s business application estate, start with the Dynamics 365 complete guide first. This post goes straight into Commerce and assumes you know what Dataverse and the Power Platform are.

Dynamics 365 Commerce Guide: What It Is and What It Is Not

Commerce is the application that used to be called Dynamics 365 Retail, renamed in 2018 when Microsoft split the old “Dynamics 365 for Retail” brand into the application it is today and the separate Dynamics 365 Supply Chain Management product. It is an enterprise platform for selling — not a website builder, not a payment gateway, not an ERP.

The clearest way to hold it in your head: Commerce is the sell side of the enterprise estate. It owns what the product is, what it costs, what is in the cart, what was ordered and how it gets fulfilled. It connects outward to Dynamics 365 Finance for the ledger, to Supply Chain Management for inventory and production, to Customer Service for returns and cases, and to Power Platform for the low-code extensions most customers actually build.

The last row is the one people miss. Commerce is not a monolith of its own; its operational data lives in Dataverse tables in a Commerce database, and Channel Data Manager is the tool that decides what flows to which system — Commerce to Finance for invoices, Commerce to SCM for inventory and orders, and the reverse for stock and pricing. That table mapping is where most “the number is wrong” escalations actually live.

The Catalogue: Products, Variants and Hierarchies

A product in Commerce is a sellable concept — “Men’s Running Shoe”. A variant is a specific SKU of it — size 9, colour black, with a barcode, a cost price and a stock position. Retailers live and die by how well they model this. If every size-colour combination is a separate product, your catalogue becomes 4,000 products instead of 200, your reporting fragments, and your merchandisers lose the ability to move a price on a whole style.

Attributes define the variant axes. You decide which are colour and size, which are sellable versus non-sellable, and how the axes are presented on the storefront. You then set up hierarchies — category, product, variant — and channel availability rules that decide where a variant is shown and sold. Product dimension groups (size, colour, style, configuration) and the associated dimension values are what make a variant axis reproducible across a brand instead of something each merchandiser invents differently.

Conceptual illustration — the Commerce catalogue shape (not a paste-ready script)

Product          "Men's Running Shoe"        product number, title, type, brand, category
  +- Variant    "RUN-BLK-09"                 SKU, colour=black, size=9, barcode, dimensions
  +- Variant    "RUN-BLK-10"                 SKU, colour=black, size=10
  +- Variant    "RUN-WHT-09"                 SKU, colour=white, size=9

Price book        "Retail list prices"        currency, currency round rule
  +- Price rule  "Base price"                priority 100
  +- Price rule  "Member price"              priority 200  (evaluated after base)

Promotion         "Festive 20% off"           discount type, coupon codes, date window, channel scope

Availability      "Variant x channel"         sold online / sold in store / hidden

Pricing and Promotions: Why the Cart Shows a Different Number

Commerce evaluates pricing with an explicit price calculation priority. Price rules are sorted by priority; within the same priority, the resolution is by a defined rule rather than by hope. The important consequence is that prices and discounts are separate mechanisms that both land on the same cart line, so a customer can see a price adjusted and a promotion applied at the same time. Getting this wrong is the most common reason a customer calls the support line about a price.

The working mental model is: price books hold currency and rounding behaviour, price rules hold the actual calculation (a list price, a cost-plus margin, a fixed price, or a formula), and promotions hold everything the marketing team owns. A promotion can be a percentage or fixed amount off, a fixed price, a buy-one-get-one, a bundle price, or a free shipping threshold. Coupons attach to promotions. Channel scoping on both price rules and promotions lets a website price differ from a store price — which is legitimate and has to be explained in the design document, not discovered in production.

One configuration decision worth getting right early: rounding. Half-up versus half-even, and whether the discount is applied to the line before tax or after. A retailer who changes rounding rules after launch gets an enormous number of support tickets about a one-rupee difference, and the finance team will not let you change it mid-quarter.

Carts, Orders, Fulfilment and Order-to-Cash

A cart is a working set of lines with a channel, a customer context and a running total. When the customer commits, the cart becomes an order — either a sales order to be fulfilled, or a purchase order depending on the flow. Orders can be held for review (fraud, credit, manual approval) and released later; that hold mechanism is a deliberate design choice in some retailers and an accident waiting to happen in others.

Fulfilment is where the operational model lives. Commerce supports fulfilment profiles — rules that decide, per store or warehouse, what it is allowed to fulfil: all orders, orders above a value threshold, only certain item groups. That single configuration is how a retailer prevents a small store from picking a bulky item it has no shelf space for. On top of that sit waves, batches and picking lists, which group orders into efficient work for the floor. Store fulfilment extends this so a physical store can allocate, pick and ship an order from its own stock, which is what makes click-and-collect and ship-from-store work at all.

The revenue side is order-to-cash: when an order is invoiced, the invoice goes to Finance through Channel Data Manager, and the payment, tax and settlement trail lives in Commerce’s order tables and in the connected ledger. Returns and cancellations are part of the same model — a return creates a return order, which reconciles against the original, and the financial adjustment flows back to Finance. Building a Commerce implementation without designing returns is a common and expensive shortcut.

Headless Commerce: The Pattern That Changed the Build

In a traditional Commerce implementation, the platform’s own storefront renders the pages. In a headless implementation, the platform provides data and behaviour through APIs, and the customer-facing site is a separate application you control — React, Next.js, Angular, a mobile app, or even a voice surface. The Commerce APIs are hosted on Dataverse and cover product, cart, checkout, order and promotion operations.

Conceptual illustration — the headless request shape (shape, not a copy-paste script)

POST https://{environment}.commerce.azure.com/commerce/carts
Content-Type: application/json

{
  "cartLines": [
    {
      "sellingModel": { "productId": "{product}", "productVariantId": "{variant}" },
      "quantity": 2
    }
  ],
  "currency": "INR"
}

The response carries the cart id, the calculated price and the applied promotions.
Everything the storefront renders about price is returned by the platform, not computed
in the front end. The classic bug is a front end that re-computes a total locally.

The headless pattern is where the modern work and the interview questions live: how to keep the storefront fast while the platform recalculates, how to cache without serving a stale price during a flash sale, and how to handle authentication and carts that survive a page reload. The platform remains the system of record for price and promotion even when the front end owns the pixels.

Where Commerce Wins and Where It Loses

Two more honest notes. Commerce has a real learning curve for people coming from modern web development — the release and configuration discipline is heavy compared with a front-end stack, and “just deploy” does not exist in the same way. And the total cost of ownership for a mid-sized retailer includes Commerce licences, Dataverse capacity, an implementation partner and the ongoing cost of the catalogue discipline it demands. If none of the complexity in the table above applies to the business, the honest recommendation is a simpler platform.

What Actually Happens at Work: The Flash Sale That Priced Differently at the Till

A Mumbai-based electronics retailer ran a headless storefront on Commerce with the company’s own Next.js front end, and used Commerce for the e-commerce channel while the physical stores ran on Store POS. It worked fine for eleven months.

Then they ran their first genuine flash sale. Marketing pushed a 30% discount promotion with a six-hour window, published at 10:00. On the website, the price dropped on time — because the front end called the Commerce cart API and got the promotion applied. In the stores, nothing changed for twenty-two minutes, because Store POS had cached its product and pricing data locally and only refreshed on its own schedule.

The result was a customer queue. A store till charged the full price while the website showed the discounted price on the customer’s phone, twenty feet away. Forty-one customers paid the higher amount in that window, and the store staff, under pressure, started manually applying a store-level override to keep customers calm. By the end of the sale the store had sold 312 units at a price that did not match the published promotion, and the reconciliation between the two channels did not close for nine days.

Three fixes went in, and all three are standard omnichannel design rather than clever fixes. First, promotion effective times were pushed to all channels and POS price refresh was forced on promotion start and end, not just on the standard refresh interval. Second, the override that staff used manually was logged and reviewed daily, so the gap between the two channels became a number someone owned rather than a number everyone argued about. Third, the launch checklist gained a mandatory test: run the same promotion in a web session and a POS session and compare the final cart line price, not the shelf label.

The generalisation: in omnichannel, “the promotion is live” is not a state the business can assume. It is a state you verify per channel, on a schedule, and rehearse before every campaign. That is exactly the kind of thinking that separates a mid-level Commerce consultant from a senior one.

Where to Go Next

Learn the object model, then configure it. The Power Platform roadmap sets out the shared Dataverse, Power Apps and Power Automate foundations that Commerce sits on. If your goal is a Commerce role specifically, the Dynamics 365 Commerce certification path maps MB-210 to the skills the exam actually tests, and the Commerce salary guide for India covers what the career pays.

Training Resources

Get the functional grounding that Dynamics 365 Commerce roles are hired on with SkilBrill Power Platform Functional Consultant Training — solution design, Dataverse data modelling for Commerce and retail estates, business process flows, Power Apps and Power Automate integration for omnichannel scenarios, and the client-facing consulting practice that moves you up the band.

FAQ

What is Dynamics 365 Commerce used for?

Dynamics 365 Commerce is Microsoft’s enterprise e-commerce and omnichannel application. It manages product and variant catalogues, pricing and promotions, carts and orders across web, store and call-centre channels, fulfilment including store fulfilment, and product recommendations, and it powers headless storefronts through Commerce APIs on Dataverse.

Is Dynamics 365 Commerce the same as Dynamics 365 Retail?

Effectively yes. Dynamics 365 Retail was renamed Dynamics 365 Commerce in 2018 when Microsoft separated the application from Dynamics 365 Supply Chain Management. Older job descriptions, CVs and integration documentation still say “Retail”, so treat them as the same product family.

Is Commerce better than Shopify for a large retailer?

For a retailer running stores, a call centre and a website off one catalogue and one order book, yes — Commerce handles shared inventory, pricing and fulfilment natively. Shopify is the better answer for a small merchant needing a storefront quickly, and Adobe Commerce wins where front-end and catalogue customisation dominate.

What does Channel Data Manager do in Dynamics 365 Commerce?

Channel Data Manager is the mapping layer between the Commerce operational data in Dataverse and the connected enterprise systems. It decides which tables flow to Dynamics 365 Finance for invoices and to Supply Chain Management for inventory and orders, and it is where most pricing, stock and order mismatch escalations originate.

Is a headless Commerce storefront harder to build than a themed one?

Considerably. You own the front end, the rendering, the caching strategy, the payment flow and the accessibility work that a themed storefront gives you for free. It buys you total control of the customer experience and is where most modern Commerce engineering work sits.

Written by SkilBrill Training Institute

October 19, 2026 · 12 min read