Product hierarchy vs supplemental vs navigation

Product hierarchy vs supplemental vs navigation — which one do you need?

Probably all three, for different jobs, and the mistake is using one for another's purpose.

Dynamics 365 Commerce has three category hierarchy types. Microsoft documents a distinct purpose for each, and the distinctions are sharper than the shared word "hierarchy" suggests.

For the merchandiser, digital merchandising manager or consultant setting up category structures. Dynamics 365 Commerce. 7 minute read.

The three types, in Microsoft's words

The overview page introduces its table as "the types of category hierarchies that are available and the general purpose of each type" — so what follows is Microsoft's statement of purpose, not our reading of it:

Product hierarchy — Documented purpose: "define the overall product hierarchy for your organization… for merchandising, pricing and promotions, reporting, and assortment planning" · Cardinality: "Assign this hierarchy type to only one product hierarchy"
Supplemental hierarchy — Documented purpose: "for any additional category hierarchies that you want to create" · Cardinality: No limit stated; "multiple category hierarchies" is supported
Navigation hierarchy — Documented purpose: "group and organize products into categories so that the products can be browsed online or in POS" · Cardinality: Unstated

One further sentence sets the boundary for the third type, and it is the most useful line on the page:

"only product hierarchies that are assigned the Commerce navigation hierarchy type are referenced when you browse products by category online or in point of sale (POS)."

So your customers never browse the Product hierarchy. They browse whatever carries the navigation type. Those can be the same shape and they are not the same object.

Which one you need

The short version, and this part is ours:

Classify the range once, for merchandising, pricing, reporting and assortment planning — The Product hierarchy — and you get exactly one
Gather products for a campaign, a season or a promotion without disturbing the canonical structure — A Supplemental hierarchy
Decide what a shopper sees when they browse a category online or at the till — A Navigation hierarchy

The failure this prevents is the common one: building a single tree that tries to be both the internal classification and the customer-facing browse structure. Those two have different consumers and different optimum shapes. Internal classification wants to match how you buy and report. A browse tree wants to match how a shopper looks for things, which is rarely the same.

The Product hierarchy — the canonical one

This is the tree everything merchandising-related hangs from, and there is one of it: "You can assign only one Commerce product hierarchy per organization." Chapter 5 covers that constraint and its consequences.

Two things worth knowing here. It is created at Modules > Retail and commerce > Products and categories > Commerce product hierarchy, and its nodes carry very little: a Name, Description, Friendly name, Keywords and an optional Display order.

And it carries defaults, which is the part that makes its shape consequential:

"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 inherit down this tree — and for apparel, product dimensions are size, style and colour. So the canonical structure decides where those defaults can be set and how granularly.

The Supplemental — a working set, not a second spine

Microsoft's example is precise about scope and worth having verbatim:

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

Seasonal, purpose-built, disposable. The pattern is a permanent canonical tree plus temporary trees for campaigns. Using a supplemental hierarchy as a parallel permanent structure works mechanically and fights the documented intent.

The Navigation hierarchy — what your customers actually browse

This is the digital merchandising surface, and it is where the three types stop being an administrative detail.

The navigation tree is what gets "browsed online or in POS", and it is the only one referenced for that. Which means the shape of that tree is the shape of your online category navigation — a merchandising decision dressed as a configuration task.

What Commerce gives you on top of the tree is presentation control over product dimensions. From the dimension settings page:

"Dynamics 365 Commerce supports size, style, and color dimensions to distinguish product variants."

Those can be rendered as swatches rather than text — available from the 10.0.20 release, configured in site builder at Site Settings > Extensions > Dimension Settings, with two settings: "Dimensions to display as image" and "Dimensions to display in product card".

The resolution order is documented and worth knowing, because it explains why some dimensions look different from others:

"If you select a dimension for display as a swatch, Commerce module rendering looks for an available configuration of a hex code swatch. If no hex code is configured, system logic looks for a configuration of an image URL swatch. If neither a hex code nor an image URL is configured, text is shown."

Hex code, then image, then text. And colour is the privileged dimension:

"The swatch selection behavior on product cards is optimized for the color dimension. For other dimensions, a view extension might be required to customize swatch selection behavior."

So on a product card, colour behaves well out of the box and size may need development. For apparel — where size is the dimension that decides whether a shopper can buy at all — that asymmetry is worth knowing before you design the card.

These settings apply to product details pages and search result list pages, which is the point at which category structure, variant presentation and on-site search meet.

Three practical points the type table does not tell you

A supplemental hierarchy can be built for assortments, not just promotions

The type table's Supplemental row gives promotions as its example. A different page is more specific about what else qualifies:

"You can also create separate, supplemental category hierarchies to group or categorize your products for special purposes, such as promotions or assortments."

Assortments are named explicitly. So if the grouping that suits your range decisions differs from the one that suits reporting, a supplemental hierarchy shaped for assortment construction is a documented option rather than a hack. Chapter 5 covers why that relieves real pressure, and chapter 9 covers how assortments consume category structures.

"Multiple purposes" is the design intent, which explains the sparse nodes

The same overview page frames the canonical tree as deliberately reused:

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

One structure, four functions. That is why a node carries so little — a tree serving merchandising, pricing, reporting and assortment planning at once cannot hold function-specific data on its nodes. The specificity lives in category attribute groups instead: "You can assign category attribute groups to each group as required."

Which channels the navigation tree actually serves

Worth being precise, because "online" undersells it. The navigation type is referenced for browsing "online or in point of sale (POS)" — so the same tree shapes the customer's path on the website and the associate's path at the till.

And the channels themselves come in three kinds: "Channels represent a brick-and-mortar store, an online store, or an online marketplace."

A browse structure designed only around the website is also the structure your store staff navigate. Those two users are looking for different things at different speeds, and one tree serves both.

What the browse tree does not decide

Two honest boundaries, and they are different from each other.

Bounded absence. Across the three pages behind this article, the navigation hierarchy organises products into categories and the dimension settings control how variants are displayed. Neither carries a quantity, a depth, or a size mix — the same finding as the rest of this cluster, and here it means the customer-facing tree is a presentation structure rather than a plan.

And one thing we have not researched, stated as such. Search relevance and ranking — what comes first on a search result list page, and why — is not covered by any page we opened. We are not claiming Commerce lacks relevance tuning; we are saying we have not read the pages that would tell us, and this article therefore makes no claim about it. That is a gap in our research, not a finding about the product.

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
Apply display settings for product dimensions — ms.date 2026-01-22
Set up assortments — ms.date 2026-01-29

Product hierarchy vs supplemental vs navigation — which one do you need?