Assortment vs category vs hierarchy

Assortment vs category vs hierarchy — what actually decides whether a store can sell a product?

The assortment does. The hierarchy and the category decide what a product is; only the assortment decides where and when it may be sold.

Those three words get used interchangeably in requirements documents, and the conflation causes real problems — because changing the wrong one produces no error and no effect.

For the merchandiser or consultant untangling a requirements document. Dynamics 365 Commerce. 7 minute read.

What each of the three actually is

Hierarchy — What it does: Classifies the range. A tree of category nodes, one canonical per organization · Microsoft's words: "Use product hierarchies to categorize or group products"
Category — What it does: A node in that tree. Groups products and carries inherited defaults · Microsoft's words: "you can set up and maintain product attributes and properties at the category level"
Assortment — What it does: Authorises products for channels over a period · Microsoft's words: "Assortments determine which products are available at specific stores and during a specific period"

Classification, grouping, authorisation. Three different jobs, and only the third one is a permission.

A product can be perfectly classified, in the right category, inheriting the right defaults — and unavailable in every store you own, because no assortment authorises it. The hierarchy has no opinion about where anything is sold.

The reverse holds too: a product needs no particular category position to be assorted, because an assortment can name products directly.

Where the three meet

They meet because an assortment can be built from categories:

"In Commerce, an assortment is a mapping of one or more channels (or groups of channels, when using organization hierarchies) to one or more products (or groups of products, when using category hierarchies)."

That parenthetical is the whole relationship. An assortment can point at a category instead of at each product, which is what makes assortments maintainable at scale — and it means your category structure becomes the vocabulary your assortments are written in.

There is a consequence people meet in production. From the setup page:

"Any products that are added to the category that is included in the assortment are automatically included in the assortment. Then, the next time that the commerce assortment scheduler is run, these products become available to the channels that the product assortment is assigned to."

So classifying a new product into a category can authorise it for sale, without anyone touching an assortment. That is powerful and it is a footgun: the category is now a distribution decision, and whoever classifies products is making one.

Microsoft has a name for this and it is worth using. The overview page calls it a dynamic assortment:

"You can define assortments by using specific channels and products or by including organization units and categories. Assortments that include references to these groups are dynamic assortments. If the definition or contents of those groups change while the assortment is active, the definition of the assortment also changes."

So the behaviour is not an accident of implementation — it is the documented design, with a term for it. And the same page spells out the consequence in both directions: "if you add an organization unit to a different node, the organization unit's assortment is automatically adjusted based on that definition."

Moving a store in the hierarchy changes what it sells. That is the store-side twin of the product-side behaviour, and chapter 3 covers the hierarchy mechanics.

And the inverse capability exists too — an assortment can "include all products in a specific category" while excluding "selected products from a category that is included in the assortment." So a category membership can be overridden per product, which is exactly the setting people forget they configured.

And there is a precedence rule that settles every conflict, which almost nobody knows:

"If a product is both included and excluded in one or more assortments by definition, the product is always considered to be excluded."

Exclusion wins, across assortments, unconditionally. One exclusion anywhere defeats any number of inclusions, and no amount of adding it elsewhere brings it back. That is worth knowing before you debug.

You are not stuck with one category structure

One detail in the prerequisites changes how these three objects can be combined: Microsoft names assortments — not only promotions — as a legitimate purpose for a supplemental category hierarchy.

So if the grouping that suits range decisions differs from the one that suits reporting, you can build a supplemental hierarchy shaped for assortment construction and write assortments against that. Chapter 5 covers the trade.

Three levels of granularity, and they cost different amounts to maintain

An assortment can be written at three levels, and the choice is the single biggest driver of how much ongoing work it creates:

A category — What it costs you: Almost nothing ongoing. New products in that category join automatically at the next scheduler run · When it is right: The range is defined by product type and you trust your classification
A specific product — What it costs you: One maintenance action per product per assortment, forever · When it is right: Deliberate exceptions, or a range that does not follow classification
A specific variant — What it costs you: The most granular and the most work. Per size, per colour · When it is right: Apparel, where a store carries a style but not every size in it

That third row is where apparel lives, and it is worth being clear about what it buys. Variant-level assortment lets you say a store carries this style in sizes 10 to 16 and not in 6 or 20. That is a real merchandising decision and Commerce supports expressing it.

What it does not do is decide which sizes, or in what proportion. It records the answer; nothing computes it. Chapters 1 and 4 cover why the quantity side is separate.

There is also a copy shortcut: the first documented step is "Create a new assortment, or copy an existing assortment." Copying a known-good one beats building from blank, especially for a seasonal range that mostly repeats.

The authorisation is conditional, and that is the part that bites

Saying "the assortment decides" is true and incomplete. The assortment decides subject to three conditions, each documented on the setup page and each capable of silently withholding a product:

The assortment has been published, and republished after any edit — Availability is the output of the scheduler. Unpublished edits do not reach the channel
The product has been released to a legal entity — "until the products are released to a legal entity, they can't be made available to the channels" — even if the assortment is approved
The channel sits in a hierarchy carrying the Retail assortment purpose — Assortments cannot be assigned to that channel at all

None of those three is visible from the assortment record you are looking at. Chapter 2 walks the full diagnostic; the point here is structural. The assortment is the decision-maker, and it is not self-sufficient.

A fourth dependency sits further upstream and is easy to forget during a rollout — a channel is not a lightweight object:

"Each retail store channel can have its own payment methods, price groups, point of sale (POS) registers, income accounts and expense accounts, and staff. You must set up all these elements before you can create a retail store channel."

So the chain runs: those elements, then the channel, then the channel's position in a purpose-bearing hierarchy, then the assortment, then the scheduler. A new store is not assorted until every link exists. For a chain opening locations on a schedule, that sequence is the critical path and the assortment is the last link, not the first.

How to verify, at the level that matters

Both read-back paths end at the variant, which is the level apparel needs:

"To validate assorted product variants, select the product master in the list." Then: "On the action pane, select Product variants. A new list shows all assorted product variants."

Checking the master is not checking the sizes. A style can be present at a channel with half its size range missing, and the product-level list will look correct. For a variant-level assortment, the drill-down is the only honest verification.

Which one to change

The practical version, and this table is ours:

Stop one store selling one product — The assortment — exclude the product, then republish
Stop every store selling a group of products — The assortment that includes their category, or the category membership
Change what a product is — its attributes, defaults, reporting position — The hierarchy and category. This will not change where it is sold
Make a new product available wherever its type already sells — Its category, provided an assortment already includes that category
Change how deep each store goes — None of these. That is the buyer's push — chapters 1 and 4

The last row is the one worth remembering. Three objects decide whether; none of them decides how many.

What none of the three decides

Across the three pages behind this article, read in full, none of these objects carries a quantity, a depth, a breadth, a budget or an open-to-buy figure. Nor a size mix.

That absence is bounded to these pages and is the cluster's central finding — chapter 10 assembles the complete list with its bounds, and chapter 0 walks the full field inventory.

The useful summary is a sentence: classification says what it is, the category says what it is like, the assortment says where and when it may be sold — and the quantity is decided on a different form by a weight somebody typed.

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

Assortment vs category vs hierarchy — what actually decides whether a store can sell a product?