Back to Blog
Published:
Last Updated:
Fresh Content
Warehouse MethodsChapter 1

Is advanced warehouse management a setting you can turn on later?

8 min read
1,731 words
high priority
Mudassir Marwat

Mudassir Marwat

Founder & CEO, Cognilium AI

TL;DR

Microsoft publishes a migration tool for moving items onto warehouse management processes, and states that open inventory transactions do not block it. The requirements, the validation list and two unsupported cases are the real answer — and the setting that is genuinely hard to revisit is not this one.

Is advanced warehouse management a setting you can turn on later?

Yes, and Microsoft publishes the tool. The reason the question keeps getting asked is that the answer people fear — you had one chance at go-live — is true of a different setting than the one they are asking about. Here is which is which.

The switch is documented, and the thing you cannot casually revisit is a different setting

The fear is reasonable and misdirected. Turning warehouse management processes [GA] on for an item is a migration with a published tool, a validation step and two unsupported cases. Where the batch number sits relative to the location is the decision that sets your options for years — and it is not the same switch.

That distinction matters commercially, because the two get quoted as one risk. "We would have to re-implement" is usually a sentence about the hierarchy, not about the checkbox.

Two different switches, and only one of them is about the building

WMS (warehouse management system — the module that directs work on the scanner) is enabled in two independent places, and a building can satisfy one and not the other.

  • Use warehouse management processes on the warehouse — Where it lives: The Warehouses page · What it governs: Whether this building runs WMS at all
  • Use warehouse management processes on the storage dimension group — Where it lives: The item's storage dimension group · What it governs: Whether this item can do warehouse work anywhere

For the building, warehouse configuration overview (ms.date 2025-11-20) is direct: "To use WMS in Supply Chain Management, you must create a warehouse and enable it for WMS. On the Warehouses page, select the Use warehouse management processes option."

The two are genuinely independent, and reservations in Warehouse management (ms.date 2026-06-22) says so: "you can use an item that is enabled for WMS in both warehouses that are enabled for WMS and warehouses that aren't enabled for WMS."

That sentence is worth re-reading if you run a mixed estate. A WMS item in a non-WMS building is a supported state, not a misconfiguration — and chapter 12 is where that goes when the second building belongs to somebody else.

What an item needs before it can do warehouse work

The item-side requirement is a property of the storage dimension group. The migration article (ms.date 2024-01-30) states it precisely:

"an item must be associated with a storage dimension group in which the Location inventory dimension is active, and the Use warehouse management processes parameter is selected. When this setting is selected, the Site, Warehouse, Inventory status, Location, and License plate inventory dimensions become active."

Five dimensions arrive together. That is the data-model change, and it is why the question feels heavier than a checkbox.

The same page lists three requirements an item must meet, and all three are prerequisites rather than consequences:

  • Storage dimension group — "must have the Use warehouse management processes parameter set to Yes"
  • Inventory reservation hierarchy — "An inventory reservation hierarchy must be assigned"
  • Unit sequence group — "A unit sequence group must be assigned" — it "defines the sequence of units that can be used in warehouse operations"

The middle one is the load-bearing row, and section 6 is why.

Microsoft's migration tool, and the sentence most people expect not to find

There is a published tool, reachable two ways: Inventory Management > Setup > Inventory > Change storage dimension group for items, or Warehouse management > Setup > Enable warehouse management processes > Change storage dimension group for items.

You add a row per item with a target storage dimension group, a reservation hierarchy and a unit sequence group, then Validate changes, then Process changes. Microsoft notes it "can take a while" and "uses both parallel processing and the batch framework."

Then the sentence that answers the headline, in a Note on that page:

"You can change the storage dimension group for items even if open inventory transactions exist."

Open transactions are the thing everyone assumes forces a hard cutover. Microsoft says twice on that page that they do not.

Two bounds. It frames itself as an upgrade path — "provides an overview of the process of upgrading from Microsoft Dynamics AX 2012 R3, running the WMSII module" — and its ms.date is 30 January 2024, the oldest page cited here.

The tool and the requirements are described in general terms on it; the framing is not. Treat it as the documented mechanism, and confirm the behaviour in your own sandbox before planning a cutover around it.

What actually stops a conversion: a validation list and two unsupported cases

The validation step is the real gate, and its conditions are published. Microsoft says it "checks for the following conditions, among others" — so this is the documented subset, not a complete list:

  • "A default inventory status must be defined."
  • "On-hand inventory with pallets must exist only on license-plate-tracked locations."
  • "On-hand inventory without pallets must not exist on license-plate-tracked locations."
  • "All combinations of storage dimension groups and reservation hierarchies must be valid."
  • "Items that are migrated to use WMS must not be enabled to use catch weight."

Two scenarios are listed as unsupported, and the second is the one that surprises people, because it is a property of your open reservations rather than of your setup. Microsoft calls it a hole:

"If any reserved ordered transactions have a 'hole' in the dimensions, the item can't be converted. A hole can occur for items where the batch dimension is active and is below the location dimension in the reservation hierarchy. If a reservation exists on the site, warehouse, or batch, the location is missing. We refer to this situation as a hole. Holes aren't supported."

The fix is stated: "remove the hole by either assigning the missing dimensions or clearing the dimensions." That is order-by-order remediation, scaling with your open order book, not your item count. It is the number to get before you scope the project, and nothing on the page suggests the tool produces it before you run the validation.

The other unsupported case is catch weight: those items "must be downgraded to a dimensions group where only the location dimension is active."

Note what downgraded implies — then read who it is offered to: "To use items that were blocked during upgrade, you have two options." Every move documented here starts from a Pallet ID item blocked at an AX 2012 upgrade, never on WMS. So the switch is documented in one direction, for one population, and nothing says a WMS-enabled item can be moved back off. That is a statement about what is published, not what is possible — and it is why the sticky decision is elsewhere.

The setting that really is sticky, and it is not this one

It is the reservation hierarchy, and specifically what it decides about when a batch or serial number gets committed. Flexible warehouse-level dimension reservation policy (ms.date 2026-04-28) states the constraint plainly:

"the challenge is that only one inventory reservation hierarchy can be assigned to each released product. Therefore, for the WMS to handle tracked items, after the hierarchy assignment determines when the batch or serial number should be reserved (either when the demand order is taken or during the warehouse picking work), this timing can't be changed on an ad-hoc basis."

One hierarchy per product, and it fixes the moment of commitment. That is narrower than "one-way" and more useful: it names what is hard to change, and when it bites. Microsoft's names for the two models are Batch-above[location] and Batch-below[location], and chapter 2 is about which you already chose.

How we build on top of this, and where we would draw the line

Pick-Path & Slotting Optimizer reads the dimensions your hierarchy already publishes and optimizes the decisions above them — which orders travel together, which item earns which slot — writing back into the wave, cluster and slotting objects Dynamics 365 executes, behind an approval step. Dynamics is the system of record for the warehouse. The optimization above it is a second system.

A working demo exists; it is not off the shelf. We build it against your systems and your constraints on request, and we have no delivered warehouse engagements — so this is a capability, not a report on somebody's building.

We would not touch a storage dimension group or a reservation hierarchy. That belongs to whoever owns your data model — your implementation partner's work — and an optimizer that needs your hierarchy re-cut has mistaken a modelling problem for a configuration one.

We would also not model over an item estate mid-migration. If half your items are converted, the walk you would optimize is not the walk you will have.

What to do this week

  1. Count your unconverted items. Go to Inventory management > Setup > Inventory > Items blocked for inventory updates. An empty page and a full page are very different projects.
  2. Check the two switches separately. On the Warehouses page, note which buildings have Use warehouse management processes selected, then check the same parameter on a storage dimension group. A mismatch is a supported state and worth knowing you are in.
  3. Ask whether catch weight is active on any item you intend to convert. It is on the published validation list, and the one condition that forces a group change the other way.
  4. Run the validation on a sandbox copy before you estimate. The hole count decides the timeline, and validation is where it appears.

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/

If you are inside the WMS enablement decision, book a fifteen-minute call and we will walk your dimension groups and hierarchies with you — which decision is reversible and which is not. No deck. https://cognilium.ai

Sources

Sources

Share this article

The work behind this series

The methods behind the articles — slotting, batching, routing — and the data each one needs.

Mudassir Marwat

Mudassir Marwat

Founder & CEO, Cognilium AI

Mudassir Marwat's argument is that ERP systems record decisions they never optimise.

Founder & CEO of Cognilium AI; 37 AI agents in production across four products; 4 production AI products built and operated; three clouds in production (AWSGCPAzure)
Agentic AIRAG → GraphRAG retrievalVoice AIMulti-Agent Orchestration
Next in this series
Batch above or below location — which did you choose, and can you change it?
Chapter 2 · 8 min
In short

Key takeaways

  • Two independent settings carry the same name: one on the warehouse and one on the item's storage dimension group. A warehouse can carry one while an item carries the other, and an item enabled for warehouse processes is supported in a warehouse that is not.
  • Microsoft publishes a migration tool for changing an item's storage dimension group, and a Note on that page states the change is possible even when open inventory transactions exist.
  • Selecting the warehouse-processes parameter on a storage dimension group activates five inventory dimensions at once, which is why the change reads as a data-model decision rather than a setting.
  • What blocks a conversion is usually the state of your open reservations rather than your configuration — a reservation missing its location where the batch dimension sits below location, which Microsoft calls a hole and lists as unsupported.
  • The decision that resists revisiting is the reservation hierarchy, because only one can be assigned to each released product and it fixes when a batch or serial number is committed.
What goes wrong

Common mistakes to avoid

  • Treating the warehouse switch and the item switch as one decision. They are configured in different places, and the mixed state is documented as supported rather than as a defect to clean up.
  • Assuming open orders force a hard cutover. The migration page says otherwise in a Note, and the planning question is the hole count instead.
  • Scoping the migration from the item count. The remediation work sits in open reserved-ordered transactions, so it scales with the order book.
  • Deciding the reservation hierarchy in the same conversation as the switch. It is the constraint that outlives the project, and it deserves its own.

Bring your own numbers

Tell us how your warehouse is laid out and what your pickers actually walk. We will tell you which part of it a system can decide, and which part it cannot.

Get your pick diagnosticNo cost, no obligation.