How do you group stores for assortments, and what does the…

How do you group stores for assortments, and what does the Retail assortment purpose do?

You group stores by drawing an organization hierarchy and assigning the assortment to a node instead of to each store. It works well, and it has one prerequisite that fails silently: the hierarchy must carry the Retail assortment purpose, or none of its channels can be assigned an assortment at all.

That is the practical answer. The more useful answer is what this mechanism is and is not — because "grouping stores" and "clustering stores" are different jobs, and Commerce does one of them.

For the merchandiser or consultant designing a store structure before go-live. Dynamics 365 Commerce. 6 minute read.

The mechanism is an organization hierarchy

Assortments do not have to be assigned store by store:

"By adding your channels to an organization hierarchy, you can assign assortments to groups of stores. Instead of assigning the assortment individually to each store, assign the assortment to the high-level organization node."

An assortment is "a mapping of one or more channels (or groups of channels, when using organization hierarchies) to one or more products" — so the grouping is built into the definition rather than bolted beside it.

For a chain of any size this is the difference between a maintainable setup and a spreadsheet. It is genuinely good design and it is the right thing to use.

The purpose gate, and why a correct-looking hierarchy does nothing

Here is the sentence to write on the wall before you design anything:

"You can assign assortments only to channels that are included in an organization hierarchy that is assigned the Retail assortment purpose."

An organization hierarchy in Dynamics can serve several purposes, and the purpose is a property of the hierarchy rather than of the assortment. Build a hierarchy, populate it correctly, omit that purpose, and every channel underneath it is out of scope for assortment assignment — not with an error, but by being unavailable.

Two things follow that are worth planning around.

It fails at the structural level, so it fails wide. A missing purpose does not affect one store; it affects every channel in that hierarchy at once. That makes it a fast thing to check when a whole region looks wrong, and it is why chapter 2 puts it above the per-product causes in its diagnostic order.

A hierarchy can be right for reporting and wrong for assortments. The same tree serves "assortments, replenishment, and reporting" — the purpose is what admits it to each. A structure inherited from a finance or reporting project is exactly the case where this bites.

What inheritance actually buys you

The payoff is not only fewer clicks today:

"Whenever a new channel is added to the high-level organization node, that channel automatically inherits any assortments that were assigned to the higher-level organization node."

A new store opens and arrives pre-assorted. That is the real value of the hierarchy: the day-one range for a new location is a consequence of where you hang it, not a task somebody has to remember.

It also sets the shape of the maintenance problem. Because inheritance flows down from nodes, your assortment strategy is expressed as positions in a tree — which means changing a store's range can mean moving it, and moving it changes everything else it inherits.

Microsoft's own grouping example is the tell

The documentation's worked example is worth quoting exactly, because it shows the intended pattern:

"For example, you define one assortment that includes a base set of products. All stores receive this assortment. You then define another assortment that includes only large sporting equipment. Only your larger stores receive this assortment."

A base range for everyone, plus a bolt-on for a group defined by floor space. That is the documented pattern, and for a lot of retailers it is a reasonable one.

Notice what defines the group: store size. Not climate, not demographics, not sell-through, not size mix. The example groups by the most easily observed physical attribute a store has, and it groups by hand.

There are two different store hierarchies, and conflating them is a real error

This is the thing most worth knowing in this article, and it is invisible unless you read the assortment pages and the allocation pages together.

The hierarchy discussed so far is an organization hierarchy carrying the Retail assortment purpose. It decides which channels an assortment can be assigned to.

But the buyer's push — the form that decides how much stock each store receives — takes a different one. Its field is called Replenishment hierarchy, and on the archived page that documents it:

"If you selected Location weight or Fixed quantity for all, you can select a hierarchy of stores in the Replenishment hierarchy field. These are the stores that will receive the transferred products."

Two hierarchies, two purposes, two questions. One governs whether a store may sell a product. The other governs which stores are in scope to receive stock.

They can describe the same set of stores and they are not the same object. A store can sit in an assortment hierarchy and not in the replenishment hierarchy you picked at run time, or the reverse — and the two mistakes produce different symptoms.

There is a related precondition on the allocation side that has no equivalent on the assortment side:

"warehouses that are not identified as stores are excluded from calculations and the resulting quantities that are distributed."

A warehouse is flagged as a store by "the Store check box on the Retail FastTab in the Warehouses form." So a location can be correctly assorted and still silently excluded from every distribution, because the flag that admits it to the allocation calculation is a different setting on a different form. Chapter 4 covers the allocation side in full.

What a channel actually is, and why grouping is not free

One more thing worth knowing before designing a hierarchy: the objects you are grouping are not lightweight.

"Channels represent a brick-and-mortar store, an online store, or an online marketplace."

And a store channel has substantial prerequisites of its own:

"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 hierarchy groups channels, and a channel is the end of a setup chain rather than the start of one. For a chain opening locations on a schedule, that sequence is the critical path, and the assortment inheritance discussed above is the last link — which is exactly why it is worth having right, because it is the link that gets rushed.

Grouping is not clustering, and the difference is the whole gap

Both words get used for this and they are different jobs.

Clustering — what a merchant means — The stores that behave alike are discovered from evidence — sales patterns, size mix, seasonality — and the groups are an output, not an input

Nothing in either sourced page computes group membership. The hierarchy is drawn, the purpose is set, and the assortment follows the shape you gave it. That is an availability mechanism doing its job correctly; it is not a merchandising decision.

Which means the quality of every assortment you assign is capped by the quality of a tree somebody drew, usually once, usually at implementation, usually from the org chart or the property portfolio rather than from sales behaviour.

What we would do instead, and the check for Monday

How we would build it. Compute the groups from the evidence Commerce already holds — sales by store by variant by week — and treat the hierarchy as an output to be maintained rather than an input to be guessed. Stores that behave alike get grouped because they behave alike, the grouping is refreshed as behaviour drifts, and the assortment mechanism underneath keeps working exactly as designed. We surround Commerce; we do not touch its core.

Status, stated plainly. Assortment & Space Optimizer is the named place this decision sits 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.

The check for Monday, and it needs nothing from us. Open your assortment hierarchy and write down, for each node, the sentence that explains why those stores are together. If a node's answer is "they are in the same region" or "they were opened by the same team", you have found a grouping that was never a merchandising decision. Then compare two stores inside one node on sell-through for the same style. If they disagree sharply, the node is doing no work.

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

Set up assortments — ms.date 2026-01-29
Assortment management — ms.date 2026-01-15
Create a new product hierarchy — ms.date 2026-01-21
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

How do you group stores for assortments, and what does the Retail assortment purpose do?