Why did my published assortment never reach the store?

Because publishing an assortment is a batch job, and there are at least six documented ways for the result to be correct at headquarters and absent at the till — including one where the product is fully assorted and still cannot be sold.

Microsoft documents them all, in different places and no particular order, which is why this question keeps getting asked. Here they are in the order worth checking.

For the merchandiser or functional consultant staring at a channel that is missing a product. Dynamics 365 Commerce. 7 minute read.

First, the mechanism: publishing is a job, not a save

"When you publish an assortment, the assortment scheduler automatically runs. This process generates the list of products. When this process is completed, the products become available to the channels that the product assortment is assigned to."

Two things follow. Availability is the output of a process, not a property of the record you saved. And a process can be stale, queued or failed.

You can also run it for many assortments at once, at Retail and Commerce > Retail and Commerce IT > Products and inventory > Process assortments, where "the system creates tasks for each assortment that you publish."

Cause 1 — you edited it after publishing

The most common one, and it is stated plainly:

"If you make changes to an assortment that you already published or to the channels that the assortment is assigned to, you must update the assortment."

Note the second half. Changing the channels an assortment is assigned to also requires a republish, not just changing the products — and adding a store to an existing assortment is the case people assume is automatic. To make it repeatable, you can "run the assortment scheduler as a batch job."

Cause 2 — the assortment is approved, and the product is still not released

This is the cause almost nobody finds, because everything on screen looks finished:

"You can add products that aren't yet released to a legal entity to an assortment, and you can approve the assortment. However, until the products are released to a legal entity, they can't be made available to the channels."

The assortment can be built, approved and published with a product in it, and Commerce will still, correctly, withhold it from every channel — because release to a legal entity is a separate step the assortment does not perform.

So "the assortment is approved" is not evidence the product will appear. If you are debugging a new style rather than an established one, check this first; new products are where this cause lives.

Cause 3 — the scheduler failed under its own parallelism

This one has a symptom that looks like nothing happened, and Microsoft describes it directly:

"If you configure many assortments, the assortment scheduler creates a large number of tasks to publish them in parallel. These tasks consume many of the AX database's resources. When resource consumption reaches a high level, the system might terminate the tasks and cause them to fail."

Terminated tasks are the failure mode of a large estate. A retailer with a handful of assortments never sees it; one running assortments per banner per season will.

The documented mitigation has a label worth noticing. It requires enabling Batch priority-based scheduling and a feature Microsoft's own name marks as preview — (Preview) Batch concurrency control [PP]. Then, at System administration > Setup > Batch group, create a batch group with Scheduling Priority set to Normal or Low and a Max Concurrency value, and set that group on the Process assortments job.

Microsoft does not publish a recommended concurrency number, and says so: "Depending on the data volume and service status, test to determine which value works best for your service."

Two consequences for a go-live plan. The fix for a core merchandising job depends on a preview feature, so it belongs in a risk register rather than an assumption. And the right value is established by testing on your own volume — a task with a duration, not a setting flipped on cutover morning.

Causes 4 and 5 — the hierarchy purpose, and excluded or stopped

Two shorter ones, both real.

The channel is not in a hierarchy that carries the right purpose. Assortments can only be assigned to channels inside an organization hierarchy "that is assigned the Retail assortment purpose." A hierarchy that looks correct and lacks that purpose silently takes its channels out of scope. Chapter 3 covers this in full.

The product is excluded or stopped. Microsoft's own troubleshooting line names both: check "that the channel and product are included in the assortment, the assortment is published, and the product is not excluded or stopped."

Three precise mechanics sit behind that sentence, and each produces a different symptom:

Excluded — "If a product is both included and excluded in one or more assortments by definition, the product is always considered to be excluded." Exclusion wins unconditionally — one exclusion anywhere defeats any number of inclusions
Stopped — "If you stop a product in all legal entities to which it's released, it isn't assorted, regardless of the assortment configuration." Note all — stopping it in one entity is not enough
Blocked — "Blocked products are still assorted, but you receive a message in the POS that states that the product can't be sold." Still assorted. So this one does not look like an assortment problem at all

That third row is why "excluded or stopped" is not the whole list. A blocked product passes every assortment check and still cannot be sold — the failure surfaces at the till, not in headquarters.

And release is per legal entity, not global

Cause 2 above has a sharper form for multi-entity groups:

"Although two stores in different legal entities can share an assortment that contains the same products, the products are only available if they're released to those legal entities."

One assortment, two entities, one missing the release — and the same assortment produces different availability in each. Assortments are global: "Define assortments at a global level. They can contain channels from multiple legal entities." The release is not.

Two prerequisites that cause failures the other way round

The setup page's prerequisites table is where most of these failures originate, and two of its rows are worth reading in the opposite direction.

Category membership is a distribution decision. "Any products that are added to the category…are automatically included in the assortment" — so a product classified into an included category becomes available at the next scheduler run. "Why did this appear at a store nobody assorted it to" shares a root cause with "why did this not appear." Chapter 9 covers it.

And a new store is the end of a setup chain, not the start of one:

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

The assortment is the last link, so it is the one that gets rushed.

How to verify, and the order to check in

There are two read-back paths, and using them is faster than reasoning about it.

For a physical store: Retail and Commerce > Channels > Stores > All stores, select the store, then on the Store tab in the Inventory group choose View channel products. For an online channel: Channels > Online stores, then the Channel tab, Inventory, View assortment products.

Both show "all the assorted distinct products or product masters". To check a specific size or colour, select the product master and then Product variants, which lists the assorted variants — the level apparel actually cares about.

That drill-down is not optional for a variant-level assortment. A style can be present at a channel with half its size range missing and the product-level list will look entirely correct. If you assort at variant level, checking the master is not checking the answer.

Microsoft's own closing instruction names the four things to confirm, and it is worth using as the checklist rather than paraphrasing it: "Make sure that the channel and product are included in the assortment, the assortment is published, and the product is not excluded or stopped."

The order we would check in, which is ours rather than Microsoft's:

1 — Check: View channel products at the channel · Why here: Establishes whether this is an assortment problem at all
2 — Check: Was the product released to a legal entity? · Why here: Cheapest to check, silent when wrong, and it invalidates everything downstream
3 — Check: Has it been republished since the last edit? · Why here: The most common cause
4 — Check: Is the product excluded or stopped? · Why here: A deliberate setting that outlives the reason for it
5 — Check: Does the hierarchy carry the Retail assortment purpose? · Why here: Structural, so it fails for every channel under it at once
6 — Check: Did the scheduler task actually complete? · Why here: Last because it needs the batch log, and it only bites at scale

The ordering principle: cheapest and most invalidating first. A released-product check takes seconds and makes four of the others irrelevant if it fails.

None of this gives you a quantity. Every cause is about whether a product appears. How much a channel receives is chapter 1 and chapter 4.

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

Why did my published assortment never reach the store?