What Dynamics 365 Commerce merchandising will not decide…

What Dynamics 365 Commerce merchandising will not decide for you

Five decisions, and Commerce records every one of them faithfully without making any of them.

That is not a complaint — a system of record that substituted its own judgement for yours would be worse. But knowing where recording stops and deciding begins separates a team that trusts its ERP correctly from one that assumes a plan exists somewhere in it.

For the chief merchant or merchandising lead deciding what to expect from the system. Dynamics 365 Commerce. 8 minute read.

How to read this, and what Commerce does decide well

Every absence below is bounded to specific pages, named where the claim is made. That matters because an unbounded absence claim is almost always false — a product this large has a feature touching almost any topic. Nine Microsoft pages were read in full: seven current, two archived.

Two claims you will not find here. We do not say Dynamics has no forecasting; it has demand planning and a planning engine, documented elsewhere. And we do not say Commerce has no assortment planning, because Microsoft uses that exact phrase — chapter 0 opens on it.

Now the credit, because the rest of this means nothing without it.

Assortments let you "assign thousands of products to your channels at the same time, in any combination that your stores require." A new store "automatically inherits any assortments that were assigned to the higher-level organization node" — it opens pre-assorted.

Category defaults propagate so "when you create products, they inherit default values for their product properties." And assortments reach the individual variant, which in apparel means the individual size.

None of that is trivial and all of it is hard to build. The five gaps below are the boundary of the job, not failures at it.

It will not decide how wide, or how deep

Bounded to five pages, all read in full: the two assortment pages, the two hierarchy pages, and category management.

Across all five, no field holds a quantity, a depth, a breadth, a budget or an open-to-buy figure. A category node carries a Name, a Description, a Friendly name, Keywords and an optional Display order. An assortment carries channels, products and a date range.

The merchant's central trade — breadth against depth on a fixed buy — has no representation in any of them. You can express which products a store may sell down to the variant. You cannot express how much of each.

So the plan lives somewhere else, usually a spreadsheet, and is then typed into Commerce as a set of memberships. The system of record records the output of a process it cannot see.

Chapter 9 traces which object decides what; chapter 0 has the full field inventory.

It will not decide the size mix

Bounded to those five pages plus the dimension-settings page, and to a documentation search.

The terms size curve and size profile appear on none of the six. A search of Microsoft's documentation scoped to Commerce assortment, apparel and allocation returns no page using either term.

What Commerce does have is size as a first-class product dimension: "Dynamics 365 Commerce supports size, style, and color dimensions to distinguish product variants." And the page devoted to those dimensions is about how they are displayed — swatches resolving hex code first, then image, then text, on product detail pages and search result lists.

The only page about sizes in the merchandising surface is about rendering them. Not about what proportion of a buy each one should be.

For apparel this is the expensive gap, and the mechanism is familiar to anyone who has run a season: the middle sizes clear at full price, the tails do not, and the markdown lands on stock over-bought at allocation.

Commerce can record that a store carries sizes 10 to 16. Nothing in it decides that 10 to 16 was the right range, or how the units split across them. Chapter 8 covers the display side.

It will not decide which stores behave alike

Bounded to the two assortment pages.

Grouping exists and works: build an organization hierarchy, flag it with the Retail assortment purpose, assign assortments to nodes, and inheritance flows down. It is the right mechanism and you should use it.

But nothing computes membership. You draw the tree. Microsoft's own worked example groups by floor space and does it by hand — "You then define another assortment that includes only large sporting equipment. Only your larger stores receive this assortment."

So the distinction is grouping, which Commerce does, versus clustering, which merchants mean: stores discovered to behave alike from evidence, with the groups an output rather than an input.

The consequence is that every assortment you assign is capped by the quality of a tree somebody drew, usually once, during implementation. Chapter 3 covers it in full.

It will not decide how much each store gets, or tell you the answer has drifted

Bounded to the buyer's-push page and the two archived pages.

Quantity lives on a different form, and all three of its distribution methods reduce to one shape: a replenishment rule carrying a typed Weight, a proportional store weight from the same typed field, or an equal split. The weight's documented default is "the replenishment weight that is defined on the Retail FastTab in the Warehouses form" — a number somebody entered.

None of the three method descriptions references demand, sales history or sell-through.

And here is the compounding half, which is the most useful finding in this article. Across all nine pages, none describes a mechanism that reviews an existing weight, assortment or category default against outcomes. Every documented flow is setup, publication or execution. There is no documented review step, no drift alert, no comparison of a configured value against what actually happened.

That is a bounded claim about nine pages, not a claim that no such feature exists anywhere in Dynamics. Within this surface the pattern is consistent: you can configure it, publish it and run it, and nothing tells you it stopped being right. A weight set at go-live stays authoritative until someone questions it, and nothing prompts that question.

Chapters 1, 4 and 7 cover the allocation surface and the documentation situation.

Two things we have not researched, stated as gaps rather than absences

This distinction matters and it is easy to blur.

Search relevance and ranking. What appears first on a search result list page, and why. No page covering it was opened. We are not saying Commerce lacks relevance tuning — we have not read the pages that would tell us.

Product design, and the design-to-assortment handoff. Nothing in the nine sources touches it. For apparel the design calendar is upstream of everything here, and we have not researched how Commerce represents it.

Space, facings and planograms are the same case: absent from all nine pages, and claimed as unresearched.

A declared research gap is not a finding. Presenting one as an absence is how a piece of writing starts going past its sources, and the two are easy to confuse when both produce the sentence "we found nothing".

Why this is not a criticism, and what we would do

The pattern across all five gaps is the same, and it is design rather than defect. Commerce holds classifications, permissions and executions. It does not hold judgements.

That is the correct division for a system of record. An ERP that inferred your range strategy from last year's sales and applied it silently would be unauditable.

Every one of these gaps is a place where the system waits for a human decision. The honest observation is not that the wait is wrong, but that the decision it waits for is usually made in a spreadsheet, once, and never revisited.

How we would build it. Compute the decisions from evidence Commerce already holds — sales by store, by variant, by week. Group stores on observed behaviour rather than a drawn hierarchy, fit a size mix per style per group, resolve breadth against depth on the buy.

Then write the answers back into the fields Commerce already reads: the assortment for availability, the store weights for the quantity. The engine and the forms do not change. We surround Commerce; we do not touch its core, and the partner who built the hierarchy keeps everything they built.

Status, stated plainly. Assortment & Space Optimizer is the named place these decisions sit in our portfolio, and it is not one of the eight built products in our register. The paragraph above is how we architect this class of problem — a capability, not a shipped app. We build these on request, against your systems and your constraints, and we have no delivered retail engagements. Nothing here reports on anyone's business.

The check for Monday, and it needs nothing from us. Pick one style from last season and write down four things: how many stores carried it, how units split across stores, how units split across sizes, and how much cleared at full price. Then find where each decision was made, and by whom.

However many trace to a spreadsheet rather than a field in Commerce is the size of this gap in your business — measured by you, with no software and no call.

About Cognilium Cognilium is the AI optimization layer for Dynamics 365 — complementary apps that optimize the pricing, inventory, warehouse and planning decisions your ERP manages but can't optimize. Built on Power Platform, Dataverse and Azure. https://cognilium.ai · https://www.linkedin.com/company/37180269/

Want to know what the gap between your store weights and your sell-through is worth? Book a 15-minute call — we'll walk the method and the model with you, on your data if you bring it. No deck.

Sources

Assortment management — ms.date 2026-01-15
Set up assortments — ms.date 2026-01-29
Commerce hierarchies — ms.date 2026-01-28
Create a new product hierarchy — ms.date 2026-01-21
Manage product categories and products — ms.date 2026-01-20
Apply display settings for product dimensions — ms.date 2026-01-22
Push products from a distribution center to stores using buyer's push — ms.date 2026-02-11
Use buyer's push to distribute products — archived, ms.date 2014-04-18
Set up replenishment rules (Retail essentials) — archived, ms.date 2014-08-15

What Dynamics 365 Commerce merchandising will not decide for you