Item Explosion Is Not a Strategy: Product Masters and Variants Done Right

I have scars from this one. Ok, not literal scars but you know what I mean.

More than once, I have walked into a “product master” conversation that was really a legacy ERP coping strategy dressed up as process. The team is proud of it too. They will say it like they discovered fire: “We keep it simple. A 10 lb bag is one item. A 20 lb bag is another item. A 50 lb bag is another item.” And I am sitting there thinking, no, you did not keep it simple. You pushed complexity into the worst possible place: the item master, the one table you will touch every day for the rest of your ERP life.

I have watched this blow up in three different ways across real implementations. First, planning turns into a guessing game because demand gets split across a bunch of ItemIDs that should have rolled up into one product family. Second, pricing governance turns into a never ending game of whack-a-mole. Someone updates the 10 lb bag price agreement and forgets the 20 lb bag. Or the 20 lb gets a “temporary” discount that never gets removed. Third, reporting becomes a special kind of misery where every executive question starts with “well, it depends how you group the items.”

And then there is the migration moment. You discover you have 12,000 items that are really 2,000 products wearing different packaging costumes. Suddenly everyone wants “just a direct copy” into D365 because nobody wants to own the cleanup. I have seen teams spend weeks debating whether the 8 oz bag is a different product than the 10 oz bag, while ignoring the fact that nobody can explain why they have three different naming conventions, two different unit setups, and five different barcode formats for the same thing.

D365 is not asking you to create more items. It is asking you to model reality. Product masters, variants, dimensions, and unit conversions exist because this problem is common.

If you bring legacy item explosion into F&O, you are not modernizing. You are importing technical debt with a fresh coat of paint.

Properly Implementing Products in D365 F&O

Especially when your legacy ERP created a separate item for every size

If you are coming from a legacy ERP, there is a high chance your “product strategy” evolved into a coping mechanism:

• 10 lb bag is Item A

• 20 lb bag is Item B

• 50 lb bag is Item C

• Same material, same supplier, same demand drivers, same everything… different ItemIDs

Apparel is the same story, just louder:

• Shirt, size S is Item 1001

• Shirt, size M is Item 1002

• Shirt, size L is Item 1003

• Multiply by colors, styles, seasons, and suddenly your item master is a landfill.

D365 F&O gives you better patterns because it was built to separate a product’s identity from its variations, using product masters, product variants, and product dimensions.

The real cost of “one item per size”

People defend this pattern because it is familiar, not because it is good.

Here is what it quietly breaks:

• Forecasting and planning: Demand gets fragmented across ItemIDs that should roll up together.

• Pricing governance: Trade agreements become repetitive, inconsistent, and harder to audit.

• Substitution and fulfillment: You cannot easily reason about what is truly interchangeable.

• Reporting and analytics: Every “by product” report becomes a data-wrangling exercise.

• Master data workload: Every new size becomes a full lifecycle event: setup, security, testing, EDI, barcodes, approvals, training, and support.

The most dangerous part: it creates the illusion of control while burying you in maintenance.

The D365 mental model you need to adopt

Product master vs variant, in plain English

• Product master: The “family” (the thing you sell conceptually).

• Product variants: The specific sellable or stockable versions created from dimensions like size, color, style, configuration, version.

• Product dimension group: The rulebook that defines which dimensions matter for this product master.

So instead of creating 30 different “items” for a shirt, you create one product master, then generate variants for the combinations that should exist.

Microsoft even calls out this exact legacy scenario as a reason to use variants instead of many individual products.

Scenario 1: Same material, different bag sizes (10 lb vs 20 lb)

This is where teams usually argue: “But the bag is different, so it must be a different item.”

Sometimes that is true. Often it is not.

The better patterns (from most common to most robust)

Pattern A: Product master + Size dimension (recommended when warehouses count bags)

If your warehouse receives, picks, and ships “bags”, model bags as variants.

Example

• Product master: MATERIAL-ABC

• Dimension group: Size

• Size values: 10LB, 20LB, 50LB

• Variants: MATERIAL-ABC (10LB), MATERIAL-ABC (20LB), etc.

Then do the variant-specific work where it belongs:

• Barcode / GTIN per variant (because packaging usually changes the identifier)

• Weights and measures per variant (shipping and freight rating depend on it)

• Variant-aware unit conversions if needed (more on that next)

If you want your variant numbers and names to be readable and consistent, use product variant nomenclature rather than accepting the default formatting.

Why this works: you keep one product identity for planning and governance, while still preserving operational truth (a 10 lb bag is not a 20 lb bag in the warehouse).

Pattern B: Product master + Unit of measure conversions per variant (great for packaging logic)

If you sell in “bags” but also need clean conversions to pounds, cases, pallets, or other packaging, D365 supports unit of measure conversions per product variant when the feature is enabled.

This is the grown-up answer to “I need different pack quantities depending on the variant.”

Also: warehouse processes care a lot about unit defaults and sequencing. If your unit strategy is sloppy, WMS will punish you.

Pattern C: One product, no variants, multiple units (only when you truly do not care about package form)

This is the simplest model, and it is fine when:

• you store the material in bulk,

• you do not count bags,

• and packaging is basically just a sales unit.

Be honest here. Most organizations think they do not care about packaging until the first cycle count, the first EDI label, or the first freight dispute.

When bag sizes really should be separate items

Here is the hard truth: variants are not magic. Separate items can be correct when any of these are true:

• Different formulation or spec (it is not actually the same material)

• Different regulatory handling, hazard class, or compliance requirements

• Different costing behavior that cannot be managed cleanly as variants

• Not substitutable in practice (customers refuse substitutions, contracts lock it down)

• Different supply chain entirely (different vendor, lead time, MOQ, or quality process)

If none of those apply, separate ItemIDs are usually just legacy habit.

Scenario 2: Apparel (sizes, colors, styles)

Apparel is the cleanest use case for product masters and product dimensions.

Example

• Product master: TSHIRT-LOGO

• Dimensions: Size + Color + Style (if needed)

• Variants: automatically generated combinations (S/Red, M/Red, L/Black, etc.)

If you are using Dynamics 365 Commerce, variant groups (size, color, style) are first-class concepts there too.

What experienced teams do differently:

• They do not create every theoretical combination. They generate only what the business will actually buy, stock, or sell.

• They use product attributes for descriptive data (fabric, season, fit, gender), and reserve product dimensions for operationally meaningful variation.

• They invest in naming and numbering up front, because renaming thousands of variants later is a self-inflicted wound.

“Better ways” checklist: decide the model before you build anything

Before you mint even one new product master, answer these:

1. What makes this product the “same” product?Same spec? Same supplier? Same substitutability? Same planning bucket?

2. What variations must the warehouse physically manage?If the warehouse counts it, scans it, labels it, or bins it differently, it probably deserves a variant.

3. What variations must customers recognize?If customers order “10 lb bag”, that is a clue. If contracts price by package, that is a bigger clue.

4. Do identifiers change by size?If GTIN, barcode, or labeling changes, plan for variant-level identifiers.

5. Does packaging affect units and conversions?If yes, consider unit conversions per variant.

The implementation approach that avoids rework (the veteran version)

This is the part most teams skip, then regret.

Step 1: Build a “product philosophy” document

One page. Non-negotiable rules. Examples:

• “We use product masters for any product where size and color vary.”

• “We only create new items when spec or compliance changes.”

• “We do not encode size in the product name if Size is a dimension.”

If you cannot write the rule, you are not ready to migrate.

Step 2: Prototype in a sandbox with real transactions

Do not prototype by looking at forms. Prototype by running:

• PO creation

• Receiving and put-away

• Sales order picking

• Shipping labels and barcodes

• Planning coverage and substitution decisions

A product model is only “right” if operations agrees it is livable.

Step 3: Design your dimension group like you will live with it for five years

Because you will. Product dimensions and the dimension group are foundational to variant behavior.

Step 4: Make variant naming and numbering boring

and consistent

Use nomenclature to control how variant numbers and names are generated. Your integrations and users will thank you.

Step 5: Plan your identifiers and scanning strategy early

• Barcodes and GTINs are not an afterthought

• If you are doing GS1 scanning, get the mapping strategy right before go-live

Step 6: Migrate with mapping, not copying

Your legacy items become either:

• product masters + variants, or

• true separate items (for the justified reasons)

Do not “lift and shift” thousands of legacy SKUs into D365 just because you can. That is not migration. That is fossil preservation.

A practical rule of thumb

If the only reason you have separate items is “different size”, D365 is telling you to stop doing that and use product dimensions and variants instead.

Gonna... release (product) this blog now... this was a terrible joke, I know.

DynamicsDad