--- title: "Allocation & Assortment Optimization for Dynamics 365" canonical_url: "https://cognilium.ai/dynamics-365/assortment-optimization" slug: "dynamics-365/assortment-optimization" section: "dynamics-365" page_type: "pillar" date_modified: "2026-09-24" description: "Allocation, size curves and store clustering for apparel on Dynamics 365. Commerce names the assortment; it never derives how deep, in which sizes, where." publisher: "Cognilium AI" author: "Mudassir Marwat" person_same_as: - "https://www.linkedin.com/in/mudassir-marwat/" - "https://orcid.org/0009-0008-1927-2598" - "https://github.com/mudassirmarwat" - "https://medium.com/@mudassir-marwat" - "https://www.youtube.com/@mudassir-marwat" - "https://dev.to/mudassirmarwat" - "https://hashnode.com/@mudassirmarwat" - "https://huggingface.co/mudassirmarwat" - "https://bsky.app/profile/mudassir-marwat.bsky.social" - "https://substack.com/@mudassirmarwat" - "https://topmate.io/mudassirmarwat" - "https://fueler.io/mudassirmarwat" - "https://www.instagram.com/mudassirmarwat/" - "https://www.facebook.com/mudassir.marwat" - "https://www.reddit.com/user/mudassirmarwat/" - "https://www.f6s.com/member/mudassir-marwat" - "https://cognilium.ai/founder" answers: - "Commerce does assortment planning, and says so" - "An assortment holds" - "Breadth is modelled. Depth is a typed weight." - "What Dynamics manages" - "What it does not decide" - "Five decisions, and each one constrains the next" - "Beside the ERP, not inside it" - "What we are not claiming" - "The rest of the family" - "Start with a read-only pass" entities: [] related: --- # Allocation & Assortment Optimization for Dynamics 365 **Does Dynamics 365 Commerce do assortment planning?** It does the part it names. Microsoft's own documentation describes the retail category hierarchy as being for merchandising, pricing and promotions, reporting, and assortment planning — the phrase is theirs, and any article denying it is wrong. What an assortment record holds is a channel, a product and a date range: which products are available where, and when. That is a membership decision. How many units of each, in which store, is a different question, and the fields for it are not in that record. ## In short **Does Dynamics 365 Commerce do assortment planning?** It does the part it names. Microsoft's own documentation describes the retail category hierarchy as being for merchandising, pricing and promotions, reporting, and assortment planning — the phrase is theirs, and any article denying it is wrong. What an assortment record holds is a channel, a product and a date range: which products are available where, and when. That is a membership decision. How many units of each, in which store, is a different question, and the fields for it are not in that record. **What is the difference between assortment breadth and depth?** Breadth is which products a channel carries. Depth is how many of each it should hold. Dynamics 365 Commerce models breadth directly through assortments and executes them faithfully. Depth is derived elsewhere, in replenishment, from a typed weight or a hierarchy split — which means the number deciding how much stock a store receives is usually a parameter someone set rather than a figure computed from that store's own rate of sale. **Can this run without changing our Dynamics 365 implementation?** Yes, and that is the design constraint. The optimizer reads sales history, assortments and category hierarchies, computes the recommendation outside the ERP core, and writes the answer back into the records Dynamics already executes, behind an approval step. No overlayering, no change to the ERP core, and no replacement of your implementation partner. **What data does it need to start?** Transactional sales history by channel and product, your assortment and category hierarchy definitions, and the current replenishment parameters. The first pass is read-only: it establishes which assortment decisions are already being made by default rather than by intent, before anything is recommended. A glass extension cantilevered over a dark facade Wooden blocks stepped beneath a rising trend line How much of this style goes to which store? The quantity split. Dynamics executes the split you give it; the weight behind it is usually set once and applied to every store in a band. Which sizes, in what ratio, for this store? The dimension that turns a good allocation into a bad one. A national curve sent to every door guarantees a broken size run somewhere, and broken runs are what get marked down. A tailor's measuring tape coiled on a blue ground Sell-through by size, colour and fit is evidence about the next buy. It sits in transactional history and is rarely read back into the design decision. We have not researched this surface in Dynamics yet, and say so rather than implying depth we do not have. A material board of fabric and finish samples Clusters are usually drawn by region or by revenue band. Neither predicts what a store sells. The clustering that matters is the one derived from rate of sale by size and category. What does the channel surface, and in what order? The category hierarchy carries keywords and a display order. What it does not carry is which arrangement sold, which makes ordering an opinion rather than a measurement. Search relevance itself is unresearched on our side — the same honest gap as design. A magnifying glass on a split-colour ground **Assortment optimization for Microsoft Dynamics 365** A companion app that derives assortment breadth and depth per channel from transactional sales history, and writes the recommendation back into the assortments and category hierarchies Dynamics 365 Commerce already executes. It does not modify the ERP core. Dynamics 365 Commerce records which products a channel carries and between which dates. It executes that faithfully. What it does not hold anywhere in that record is how much of each, in which sizes, at which store — the three numbers that decide whether a run sells through or gets marked down. Apparel retail · allocation & size curves ## Commerce does assortment planning, and says so Start with the concession, because the gap only matters once the capability is clear. The phrase “assortment planning” is Microsoft’s own, on current documentation, describing what a retail category hierarchy is for. “This hierarchy type is for merchandising, pricing and promotions, reporting, and assortment planning.” Microsoft Learn — Dynamics 365 Commerce, retail category hierarchies So this page does not claim Commerce lacks assortment planning. It claims something narrower and checkable: look at what the records actually hold. ## An assortment holds Every one of those is an identifier or a membership. Not one is a quantity, a forecast, or a rate of sale. The plan is ## Breadth is modelled. Depth is a typed weight. Breadth — which products a channel carries — is a real decision and Commerce models it directly. Depth is the other half, and it is answered somewhere else: in replenishment, by a weight applied down a hierarchy. A weight is a reasonable way to split a quantity when you have nothing better. The difficulty is that it is typically set once, applied to every store in a band, and left. It does not know that one of those stores sells the size run differently, or that a category has moved since the weight was chosen. The ERP knows which stores carry the product. The margin lives in how many each one should have had. ## What Dynamics manages Which channels carry which products, and when The category structure merchandising is organised by Replenishment that executes the parameters it is given ## What it does not decide How deep to go per channel, from that channel's own sales Which of the products in an assortment earn their space When a weight set at go-live stopped describing reality ## Five decisions, and each one constrains the next Apparel is where the gap costs the most, because a garment is not one product. It is a style in a colour across a size run, and every one of those dimensions is a separate decision that Dynamics records and does not derive. Get the fourth one wrong and the first three stop mattering — the store received the right style, in the right colour, in sizes nobody there wears. The chain runs one way. A size curve computed on the wrong store cluster produces a worse allocation than no curve at all, because it is confidently wrong at every door in the group. That is why we start at the clustering and work outward, rather than optimising the number a merchandiser already argues about. Three of these five are written up in depth below. Design and search relevance are not: we have not researched those surfaces in Dynamics, and naming a decision we can describe is different from claiming we have studied it. They are in the chain because leaving them out would misrepresent how the decisions constrain each other — not because there is an article behind them. ## Beside the ERP, not inside it The Assortment Optimizer reads sales history, assortments and category hierarchies, derives breadth and depth per channel, and writes the recommendation back into the records Dynamics already executes — behind an approval step. No overlayering, no change to the ERP core, and no replacement of your implementation partner. The first engagement is read-only and answers one question before anything is recommended: which assortment decisions are currently being made by default rather than by intent? That is usually the finding that pays for the work, and it needs no write access to produce. ## What we are not claiming This is demo-ready and built on request. It is not a shipped product with a user base, and there is no sell-through or markdown figure on this page attributed to us — because we have not run it in your tenant. The numbers that matter come from a read of your own extract. Everything above about how Commerce behaves is quoted from Microsoft’s documentation and linked so you can check it rather than take our word. ## The rest of the family Replenishment runs to the safety stock you typed in. This derives that number from your own demand history instead of a planner's spreadsheet. A clipboard checklist held in front of warehouse shelving Business Central picks the lowest price you already entered. It never asks what the price should be. Hands using a calculator beside printed receipts What Dynamics manages in each domain, and what we optimize. Technical drawings and drafting tools on a desk The supported integration surface, the security model, and what we do not touch. Abstract blue light trails against a dark background How breadth and depth are decided per channel, which Commerce records hold the answer, and where the recommendation is written back. ## Start with a read-only pass The first pass is read-only: it establishes which assortment decisions are already being made by default rather than by intent, before anything is recommended. --- Canonical HTML: https://cognilium.ai/dynamics-365/assortment-optimization