Does Dynamics 365 Commerce do assortment planning?

Yes, by that name. Microsoft's own documentation says so on two separate current pages.

And then it gives you a filing cabinet.

This is the complete inventory: every field the Commerce merchandising surface holds, read off seven pages. Each one is a classification or an availability flag. Not one is a quantity.

For the merchandising lead who owns range and depth, and the chief merchant who signs the buy. Dynamics 365 Commerce. 8 minute read.

Microsoft says yes, and names it twice

Start with the refutation, because it matters more than a confirmation would.

"Use this hierarchy type to define the overall product hierarchy for your organization. This hierarchy type is for merchandising, pricing and promotions, reporting, and assortment planning."

That is retail-hierarchies, stamped January 2026. The setup page repeats it:

"You can use a Commerce product hierarchy for merchandising, pricing and promotions, reporting, and assortment planning."

So anyone claiming Dynamics has no assortment planning is wrong on Microsoft's own words. The useful question is what the feature behind the phrase stores — and that is answerable exactly, because the pages list the fields.

What a product hierarchy actually holds

A Commerce product hierarchy [GA] is built at Modules > Retail and commerce > Products and categories > Commerce product hierarchy. You create a root, then add category nodes.

Every field on a node, from the how-to page: Name, Description, Friendly name, Keywords, and an optional Display order. Separately, "You can assign category attribute groups to each group as required."

That is the merchandising structure. Names, a search term, and a sort position.

There are three hierarchy types, and the page that lists them introduces the table as "the types of category hierarchies that are available and the general purpose of each type" — so these purposes are Microsoft's, not our reading:

Product hierarchy — "define the overall product hierarchy for your organization… merchandising, pricing and promotions, reporting, and assortment planning"
Supplemental hierarchy — "for any additional category hierarchies that you want to create" — the example given is a spring swimwear promotion
Navigation hierarchy — "group and organize products into categories so that the products can be browsed online or in POS"

And there is a hard constraint worth knowing before you design anything. "Assign this hierarchy type to only one product hierarchy," says the overview. The how-to is blunter: "You can assign only one Commerce product hierarchy per organization."

One structure for the whole organisation. A retailer running two banners with different category logic gets one tree, plus supplemental hierarchies around it.

What a category holds, and the legal-entity trap

Categories do more than group. They push defaults down:

"a merchandising manager can now define default values for an additional set of product properties at the level of the individual category. Then, when you create products, they inherit default values for their product properties."

Genuinely good design. But one distinction on that page catches multi-entity retailers:

"Retail product properties are global in their scope of applicability. In other words, for a given product property, all legal entities share the same value. By contrast, basic product properties are legal entity–specific."

Retail properties are shared across every legal entity you run. If your banners or countries are separate legal entities, a retail property is one value for all of them. Basic properties are not, and the form does not shout about the difference.

Pushing changes is a batch job: Category and product management > Commerce product hierarchy, then Category > Update products. Microsoft's note says where to check it landed — the batch job history log under System administration > Inquiries > Batch jobs, "to view the log and check if there are any warnings or errors."

A merchandising change is not done when you save it. It is done when that log is clean.

What an assortment actually holds

An assortment [GA] is the availability layer:

"Assortments determine which products are available at specific stores and during a specific period."

"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)."

Channel, product, date range. Those are the three dimensions. It reaches the variant — "An assortment can also include specific products and specific variants of products" — so in apparel it reaches the individual size.

It reaches the size as a yes or a no. Never as a share.

Publishing is a batch job too, and edits do not propagate on their own: "If you make changes to an assortment that you already published… you must update the assortment."

Where the quantity lives, and why size is a swatch

The quantity sits in a different form — Commerce headquarters > Buyer's push — which splits a central buy using a Distribution method, a Replenishment hierarchy and a Respect assortments flag.

That flag is the only place the two halves of this subject meet, and it is a filter, not a plan. Every distribution method resolves to a typed weight, taken apart in a separate article and in chapter 4.

Now the part that surprises people who came looking for a size curve.

Commerce does model size. "Dynamics 365 Commerce supports size, style, and color dimensions to distinguish product variants." Size is a first-class product dimension.

But the page devoted to sizes covers how they look: swatches — hex codes and images instead of text, from the 10.0.20 release, configured at Site Settings > Extensions > Dimension Settings. The two settings are "Dimensions to display as image" and "Dimensions to display in product card".

Even there, size is second class: "The swatch selection behavior on product cards is optimized for the color dimension. For other dimensions, a view extension might be required."

The only page about sizes in the Commerce merchandising surface is about rendering them on a web page. Not about how many of each to buy.

What is therefore missing

Three absences, each bounded to the pages actually read rather than asserted about the product.

Any quantity, depth, breadth, budget or open-to-buy field — All five merchandising pages above, read in full: the two hierarchy pages, category management, and both assortment pages. None carries one
A size curve or size profile — Those five plus the dimension-settings page. The terms appear on none of them, and a search of Microsoft's documentation scoped to Commerce assortment and apparel allocation returns no page using either
Any computation of which stores behave alike — Grouping is an organization hierarchy you draw by hand. Microsoft's own worked example groups by store size: "Only your larger stores receive this assortment"

One claim we do not make: that Dynamics has no forecasting. It has demand planning and a planning engine, documented elsewhere. The bounded statement is narrower — these surfaces, as documented, do not consume one.

The eleven questions, what we would reject, and the check for Monday

Each chapter of this cluster answers one question completely.

1 — Can an assortment control how much stock a store gets?
2 — Why did my published assortment never reach the store?
3 — How do you group stores, and what does the Retail assortment purpose actually do?
4 — How does Commerce decide how much stock each store gets?
5 — Can you have more than one product hierarchy?
6 — Are retail product properties shared across all your legal entities?
7 — Why is the only page explaining store allocation scoped to Dynamics AX 2012?
8 — Product hierarchy vs supplemental vs navigation — which do you need?
9 — Assortment vs category vs hierarchy — what decides whether a store can sell a product?
10 — What Commerce merchandising will not decide for you

What we would reject. Extending the assortment or the category with depth, budget and size-mix fields puts a planning model inside the system of record, where it inherits the batch scheduler, the replication path and every platform update — and the partner who built the hierarchy carries it through all of them. Dynamics is the system of record. A merchandise plan is a different object.

How we would build it. Read the history Commerce already holds — sales by store, by variant, by week. Group stores on observed behaviour rather than on a drawn hierarchy, fit a size mix per style per group, and resolve breadth against depth on the buy. Write the result back into what Commerce already reads: the assortment for availability, the store weights for the push. 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. Nothing here reports on anyone's business.

The check for Monday, and it needs nothing from us. Pull your store weights and your trailing sell-through by store, and put them side by side. If the two rankings disagree, your allocation is running on a number that was true once.

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

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
Assortment management — ms.date 2026-01-15
Set up assortments — ms.date 2026-01-29
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

Does Dynamics 365 Commerce do assortment planning?