Are retail product properties shared across all your legal…

Are retail product properties shared across all your legal entities?

Yes — the retail ones. Not the basic ones.

That is a single sentence in Microsoft's documentation and it is one of the highest-consequence facts in Commerce merchandising, because it means two fields sitting side by side on the same form can behave completely differently for a group with more than one legal entity.

For the merchandiser or consultant working in a multi-entity group. Dynamics 365 Commerce. 6 minute read.

The answer, and the sentence that gives it

Verbatim:

"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. In other words, for a given basic product property, the value can differ across legal entities, depending on the individual business requirements of each legal entity."

Two categories, two scopes:

Retail product properties — Scope: Global · What that means when you change one: One value for every legal entity. Change it once and it has changed everywhere
Basic product properties — Scope: Legal entity–specific · What that means when you change one: The value can differ per entity, "depending on the individual business requirements of each legal entity"

So the same edit is either local or organisation-wide depending on which group the field belongs to — and nothing about the act of typing tells you which.

For a single-entity retailer this is a non-issue. For a group running banners, countries, franchise arms or a separate wholesale company as distinct legal entities, it is the difference between a local change and a global one.

Why this is easy to miss

The reason this catches people is historical, and the same page explains it:

"In previous versions of the app, product properties were divided into basic product properties and Retail product properties, based on the scope of their applicability."

"In the enhanced product category structure, product properties are logically separated into groups based on their applicability to reflect the structure of the released product details form."

The distinction used to be visible in the naming, and now the form is organised to mirror the released product details form instead. That is better design — the grouping reflects how you actually work — and it means the words basic and Retail no longer sit in front of you as a permanent reminder of scope.

The scope did not change. The signposting did. So the knowledge has to live with the person rather than on the screen, which is exactly the kind of thing that leaves with a consultant at the end of a project.

The toggle you need to know exists

Because the two scopes coexist, the form gives you an explicit switch, and knowing it exists is most of the battle:

"To manage properties across all legal entities, select View for all legal entities (or Edit for all legal entities)."

"To manage properties for a specific legal entity, select View for a specific legal entity (or Edit for a specific legal entity)."

Read the mode you are in before you change anything. The same field, edited in the two modes, does not mean the same thing — and for the legal entity–specific properties, editing in the wrong mode is how one entity's requirement quietly becomes everyone's.

The workspace path is Category and product management > Commerce product hierarchy.

Category defaults, and the batch job that pushes them

The scope question compounds with inheritance, because categories carry defaults:

"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, based on the association of those properties with an individual category in the product hierarchy. You can also modify these inherited product properties for each product to meet individual business requirements."

So defaults flow down the category tree and can be overridden per product. Useful — and it means a category-level change is a change to a population, not a record.

Pushing an update to existing products is a deliberate act: on the Commerce product hierarchy page, select Category on the Action Pane, then Update products.

And Microsoft tells you where to confirm it worked, which is the part worth building into a runbook:

"When you select Schedule batch job in the Update products dialog box, you can find the batch job history log on the System administration > Inquiries > Batch jobs form. For the Update products batch job, select Batch job history > Log, and then select Message details in the upper right to view the log and check if there are any warnings or errors."

A merchandising change is not finished when you press the button. It is finished when that log is clean. Note the wording: warnings or errors — plural, and warnings count. A partially applied property push across a large category is the kind of thing that shows up weeks later as inconsistent product behaviour with no obvious cause.

Chapter 2 makes the same point about the assortment scheduler. Both of the merchandising surfaces that change many records at once are batch-driven, and both have a log that is the actual proof of completion.

What to do when you need a global property to vary — and the honest answer

The obvious follow-up question is what happens when a retail property genuinely needs different values in different legal entities. A UK banner and a German banner, one property, two correct answers.

Across the pages read for this cluster, no documented mechanism makes a retail property vary by legal entity. That absence is bounded to category-management-product-creation and retail-hierarchies, both read in full. The scope is a property of the property, not a setting you toggle per entity.

So the practical options are structural rather than configurable, and each has a real cost:

Model the difference in a basic property instead, where scope is per entity — Only works if a basic property carries the meaning you need
Split the products, so each entity has its own product records — Duplicates the catalogue and everything downstream of it
Accept one value and handle the variation outside the property — The variation now lives somewhere with no audit trail

None of those is a workaround for a defect — they are the ordinary consequences of a deliberate scope decision. But it is better to meet them during design than during a rollout, which is why this belongs beside the toggle rather than after go-live.

The bulk mechanism, and why it raises the stakes

Categories do not only push defaults to new products. There is a copy path for existing ones:

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

So one action can rewrite a property across a category. Combine that with a global retail property and a single copy operation reaches every product in that category, in every legal entity. That is a large blast radius behind an unremarkable-looking command — and it is the strongest argument for the batch-log habit described above.

What we would do instead, and the check for Monday

How we would work with it. The scope split is deliberate design and we would not change it. What we would do is make it legible: derive, from the property definitions themselves, which fields are global and which are entity-specific, and surface that beside the decision rather than leaving it to whoever remembers. Then treat every category-level push as a change with a blast radius that gets recorded. 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. Count your legal entities. If the answer is one, stop — this article does not apply to you. If it is more than one, take the last category-level property change anyone made and find its batch job log. Two questions: did it complete without warnings, and did the person making it know whether the fields involved were global or entity-specific? If nobody can answer the second, that knowledge is currently held by memory alone.

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

Manage product categories and products — ms.date 2026-01-20
Commerce hierarchies — ms.date 2026-01-28

Are retail product properties shared across all your legal entities?