Can you have more than one product hierarchy in Dynamics…

Can you have more than one product hierarchy in Dynamics 365 Commerce?

Many category hierarchies, yes. One Product hierarchy, no.

That distinction is not pedantry — it is a design constraint that shapes what a multi-banner retailer can express in Commerce, and it is stated in two places that people tend to read separately.

For the merchandiser or consultant designing a category structure. Dynamics 365 Commerce. 6 minute read.

Many hierarchies, one Product hierarchy

Start with the permission:

"Create one category hierarchy to represent all the products and categories in your organization, and then use that category hierarchy for multiple purposes. Alternatively, create multiple category hierarchies for special purposes, such as product promotions."

So multiple structures are explicitly supported. Now the constraint, which arrives as a property of the type:

"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. Assign this hierarchy type to only one product hierarchy."

And the how-to page says the same thing without the type language: "You can assign only one Commerce product hierarchy per organization."

Two pages, one rule. You get as many category hierarchies as you like, and exactly one of them can be the Product hierarchy — the one Microsoft attaches merchandising, pricing, reporting and assortment planning to.

What the constraint actually constrains

This matters most for the retailer who has more than one way of thinking about their range.

Consider a group running two banners — a value chain and a premium chain — with genuinely different category logic. Different top-level departments, different depth, different language.

In Commerce, one of those structures is the Product hierarchy and the other is not. The second can exist as a supplemental hierarchy, and it will not be the tree that merchandising, pricing and assortment planning hang from.

The same applies across geographies where category conventions differ, and across a wholesale-plus-retail business where the two channels classify the same goods differently.

None of this makes Commerce the wrong system. A single canonical product structure is a defensible design and most retailers benefit from being forced into one. But it is a decision made once, early, usually during implementation, and it is expensive to revisit — so it deserves more thought than it normally gets, and it deserves to be made by a merchant rather than inherited from whoever loaded the data.

The practical question to settle before go-live is not "can we have two?" It is "which one of ours is canonical, and what do we lose by demoting the other?"

The supplemental pattern, in Microsoft's own example

The documentation shows what the additional hierarchies are for, and the example is worth having verbatim because it is precise about scope:

"Use this hierarchy type for any additional category hierarchies that you want to create. For example, in the spring, you have a promotion for swimwear. Therefore, you include your swimwear products in a separate category hierarchy and apply the promotional pricing to the various product categories."

A supplemental hierarchy is a working set, not a second spine. Seasonal, promotional, temporary — a convenient way to gather products for one purpose without disturbing the canonical structure.

Read alongside the constraint, the intended shape becomes clear: one permanent tree that everything merchandising-related hangs from, plus disposable trees for campaigns. That is a coherent model. It is just not the same as two co-equal category structures, which is what a two-banner group often wants.

The third type is the Navigation hierarchy, whose documented job is to "group and organize products into categories so that the products can be browsed online or in POS" — the customer-facing tree, which is a different thing again. Chapter 8 compares all three properly.

Why the single tree carries more than structure

The constraint bites harder than it first appears, because the Product hierarchy is not only a filing system. It is where defaults live:

"By using a category hierarchy to structure your products, you can set up and maintain product attributes and properties at the category level. These attributes and properties include settings for product dimensions and POS settings. Any products that you assign to the categories automatically inherit the attributes and properties that you define."

Product dimension settings and point-of-sale settings inherit down the tree. For apparel, product dimensions are where size and colour live — so the shape of your one hierarchy determines where those defaults can be set and how granularly.

There is also a bulk mechanism: "You can also copy the property settings for any product to multiple products in a selected category at the same time."

So the single canonical tree is doing two jobs at once — organising the range, and carrying the defaults that get inherited by everything in it. Choosing its shape is choosing where your defaults can vary. A structure that groups by supplier or by buying team, for instance, is a poor place to hang attribute defaults that vary by product type.

The exception worth knowing: a supplemental hierarchy built for assortments

There is a clause in the prerequisites that changes the practical answer to this article's title, and almost nobody uses it:

"Create one core hierarchy to group and categorize all products that you distribute through your channels. You can also create separate, supplemental category hierarchies to group or categorize your products for special purposes, such as promotions or assortments."

Microsoft names assortments — not only promotions — as a legitimate purpose for a supplemental hierarchy.

That matters because it relieves the exact pressure this constraint creates. Your one Product hierarchy has to serve merchandising, pricing, reporting and assortment planning simultaneously, so its shape is a compromise between four audiences.

If the grouping that makes sense for range decisions differs from the grouping that makes sense for reporting, you do not have to pick one. Build a supplemental hierarchy shaped for assortment construction and write your assortments against that, leaving the canonical tree to serve reporting and pricing.

The cost is maintenance — a second structure to keep current, and products that drift between categories in one but not the other. Chapter 9 covers how assortments consume category structures, which is what makes this option work.

What the single tree is used for, and why "multiple purposes" is the design intent

The overview page frames the canonical tree as deliberately multi-purpose:

"Create one category hierarchy to represent all the products and categories in your organization, and then use that category hierarchy for multiple purposes."

That is the design intent stated plainly: one structure, reused. Read alongside the one-per-organization rule, the model is coherent — a single canonical classification, reused across four functions, with supplemental trees for anything that does not fit.

It also explains why the node fields are so sparse. A tree serving four audiences cannot carry audience-specific data on its nodes, so what it holds is a Name, a Description, a Friendly name, Keywords and a Display order, plus category attribute groups — "You can assign category attribute groups to each group as required."

The specificity lives in the attributes hanging off the categories, not in the categories themselves. Chapter 6 covers what those attributes do and the legal-entity trap inside them.

What we would do instead, and the check for Monday

How we would work with it. The constraint is reasonable and we would not fight it. What we would do is stop the single tree from being the only lens: keep Commerce's canonical hierarchy as the system of record for structure and defaults, and compute alternative groupings — by behaviour, by sell-through pattern, by size mix — outside it, then use them to drive the decisions the tree was never meant to make. 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. Find out who chose your Product hierarchy's top-level structure, and when. If the answer is a data-migration decision from implementation, ask a merchant whether they would draw it the same way today. Then check whether any attribute defaults are set at category level at all — if none are, the tree is carrying structure only, and you are maintaining product settings one product at a time for no reason.

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

Can you have more than one product hierarchy in Dynamics 365 Commerce?