Does Dynamics 365 Dynamic Item Placement Do Slotting?

The short answer

No. Dynamics 365 dynamic item placement does not do slotting, and it does not claim to.

It is a real feature, it reached general availability in June 2026, and it is genuinely useful. What it does is hold your inventory to storage policies you define, automatically, as stock arrives. What it does not do is work out what those policies should be. That second thing is slotting, it is a question you answer from your order history before you ever configure the feature, and nothing in dynamic item placement performs it. The rest of this article is the evidence for that sentence, in Microsoft’s own words, because it is the kind of claim that should be shown rather than asserted.

What Microsoft actually shipped

Dynamic item placement is part of the 2026 release wave 1 for Supply Chain Management. Per the Release Plan entry, it went to public preview and general availability in June 2026. The mechanism it introduces is called Warehouse and item storage policies.

There are two paragraphs of official description, and it is worth reading both in full rather than trusting a summary, because the summary is where the meaning usually gets lost.

The Business value paragraph:

Transform your warehouse operations with dynamic item placement. You get smarter inventory balancing during inbound processes like purchase and transfer orders, plus automated replenishment. Define storage locations and quantities for each item, either manually or through data import. Your warehouse adapts in real time, maximizing space and efficiency so items are always in the right spot with the right quantities. Automated creation of location directives and work templates speeds up setup and reduces complexity. Replenishment happens automatically as items arrive, thanks to dynamic putaway based on your policies.

The Feature details paragraph:

Warehouse and item storage policies are now available, giving you dynamic control over where and how much inventory is stored. Define preferred storage locations and target quantities for each item, either by editing directly or importing data at scale. The system intelligently balances inventory during inbound processes, ensuring optimal placement for fast fulfillment. Warehouse spatial locations further optimize routes, cutting travel time and boosting picking speed.

That is the whole feature, described by the people who built it. Everything below is just reading it carefully.

The word doing all the work is "define"

Read the two paragraphs again and watch one word.

"Define storage locations and quantities for each item." "Define preferred storage locations and target quantities for each item." "Dynamic putaway based on your policies." Where and how much inventory is stored, under your policies, which you define.

In every sentence that describes the input, you are the one supplying it. You tell the system that item A-4471 has a preferred location and a target quantity. The system’s job, the clever part it genuinely does well, is to keep the inbound flow balanced against what you told it, in real time, as purchase orders and transfer orders arrive. It maximises space and keeps items at their target quantities, faithfully, forever.

The question slotting answers is the one word "define" quietly skips over: how did you know that A-4471 belonged in that location, at that quantity, in the first place. Dynamic item placement does not ask that question and does not answer it. It takes your answer as given and executes it. This is not a criticism. It is the correct division of labour for an ERP: the system executes policy, and a human sets policy. But it means the feature sits entirely downstream of the decision that determines whether any of the walking gets shorter. You can run dynamic item placement perfectly against a set of storage policies that put your busiest item at the back of the building, and it will keep it there, perfectly, at the right quantity, at the wrong location.

"Inbound balancing" is not "re-slotting from demand"

The other phrase to hold onto is where the feature acts: "smarter inventory balancing during inbound processes like purchase and transfer orders."

Inbound. As stock comes in. Dynamic item placement is a putaway-time feature. When goods arrive, it decides how to distribute them across the locations and quantities you defined, and it keeps that distribution healthy over time as more arrives. It is about getting incoming inventory to the right defined places in the right defined amounts.

Slotting is a different verb applied to a different input. Slotting reads twelve months of order lines, the record of what actually shipped and what shipped together, and works out where items should live so that the picking that follows is shorter. It is driven by outbound demand and its history. Dynamic item placement is driven by inbound supply and your current policy. The two touch the same shelves and are otherwise unrelated activities, and the feature is scrupulously accurate about which one it is: it says inbound, and it means inbound.

When Microsoft’s own March announcement described the wave as bringing "inventory rebalancing", this is the feature that phrase points to, and rebalancing here means balancing incoming inventory against defined targets, not recomputing the targets from how the warehouse is actually being picked. The word rebalancing invites the second reading. The feature only performs the first.

What "optimal" means here, because it will be quoted back

The Feature details paragraph contains the phrase "ensuring optimal placement for fast fulfillment", and the word optimal is going to be pointed at anyone who says the feature does not optimise. So it is worth being exact about what it optimises.

It is the same shape as the word optimal inside a location directive, which chapter 1 took apart. There, optimal means the location that best satisfies your configured constraints, not the location that minimises walking. Here, optimal placement means inventory distributed to best satisfy the storage policies you defined and the space you have, so that fulfilment is fast against those definitions. It is optimal with respect to your targets. It is not optimal with respect to a travel model derived from order history, because no travel model derived from order history is anywhere in the feature.

This is a fair and normal use of the word by Microsoft. Optimal always means optimal against some objective, and the objective here is your defined policy. The confusion only arises if a reader supplies a different objective in their head, travel, and assumes the feature shares it. It does not, and it does not say it does.

A worked example, because this is where it becomes obvious

Configuring dynamic item placement requires you to have already done the thing it does not do.

To set it up for one item, you open the storage policy and you enter something like: item A-4471, preferred location AISLE-02-BAY-A, target quantity 40. Now dynamic item placement can do its work. From then on, as A-4471 arrives, the system balances it toward forty units in AISLE-02-BAY-A, automatically, and keeps it there. Excellent. That is real automation and it removes real manual effort.

Now ask the two questions the configuration screen required you to answer before it would proceed. Why AISLE-02-BAY-A, and why forty. Those are the slotting questions. AISLE-02-BAY-A is a good answer only if A-4471 is picked often enough to earn a front location, only if it is not so bulky that forty units will not fit or so light that forty units restocks too rarely to matter, and only if it does not travel on the same orders as something you have parked at the other end of the building. Forty is a good answer only if it balances the pick savings of holding more against the space and the restock cost, which is the net-of-restock question the data-requirements chapter works through. None of that reasoning is supplied by the feature. You typed in the conclusion, and the feature took it as gospel.

Here is the part that matters. Dynamic item placement will execute a bad slotting decision exactly as reliably as a good one. It has no opinion about which it is holding. If AISLE-02-BAY-A is the worst possible location for A-4471, the feature will defend that mistake against entropy for years, keeping forty units of your busiest item precisely where they cause the longest walk, and every dashboard will show the policy being met. A feature that faithfully maintains your storage policy is only as good as the storage policy, and the storage policy is the output of slotting.

And it does not decay gracefully, because it does not watch demand. If A-4471 was a slow item when someone set the target and becomes a fast one in November, dynamic item placement notices nothing, because demand is not one of its inputs. It keeps holding the old target because the old target is still what you defined. That is the correct behaviour for a policy executor. It is also exactly why slotting is not a one-time setup, and why a feature that maintains a policy cannot be the thing that keeps the policy correct.

What it is genuinely excellent at

None of the above is a knock on the feature, and it is important to say what it does well, both because it is true and because the credibility of the rest depends on it.

Dynamic item placement removes a large amount of manual, error-prone work. Holding inbound inventory to defined targets by hand, across thousands of items, is tedious and it drifts. Automating it is a real gain. Microsoft also states that the feature includes "automated creation of location directives and work templates" to speed up setup and reduce complexity, which for anyone who has hand-built directives is a meaningful saving. Automated replenishment as items arrive, dynamic putaway against your policies, real-time balancing so locations stay at their target quantities: these are genuine operational improvements and they are worth having.

The honest summary is that dynamic item placement is a very good pair of hands. Give it the right policy and it will execute it tirelessly and keep it healthy. That is exactly what you want from the execution layer of an ERP. The only mistake is to believe the hands also decide where the stock should go.

The clause that shows how the two halves fit together

There is a phrase in both paragraphs that is easy to skim and is actually the most useful line in either for anyone thinking about slotting. You can define the storage policies "either manually or through data import", or in the fuller wording, "either by editing directly or importing data at scale."

Import at scale is the join between this feature and the work it does not do. A slotting analysis produces exactly one artefact: a table of items, each with the location and the quantity it should be held at, computed from order history. That table is an import file. Which means dynamic item placement is not a rival to slotting, it is the natural executor for its output. You run the analysis outside the system, against twelve months of order lines, and you import the result as storage policies, and from then on dynamic item placement enforces and maintains that result automatically, exactly as intended, and rebalances it at every inbound.

That is the constructive version of this whole article. The feature and the analysis are two halves of one workflow, and the join between them is that import. The failure is only ever to feed the executor policies that were guessed rather than computed, because the executor cannot tell the two apart and will hold either with equal discipline. Given a good slotting plan, dynamic item placement is precisely the tool you want carrying it.

The obvious objection: there is a feature literally called Warehouse slotting

A D365 consultant will have been waiting several paragraphs to raise this, so let us meet it head on. Dynamics 365 does ship a feature called Warehouse slotting. It is fair to ask whether that, and not dynamic item placement, is the thing that does the job. It is closer. It is still not the same thing, and Microsoft’s own wording is where the line is drawn.

Here is how Microsoft introduces the slotting features:

Several warehouse slotting features help warehouse managers intelligently plan picking locations before they release orders to the warehouse and create picking work.

And the anchor description of the feature itself:

The Warehouse slotting feature lets you consolidate demand by item and unit of measure from orders that have a status of Ordered, Reserved, or Released. You can apply generated demand to locations used for picking, based on quantity, unit, physical dimensions, fixed locations, and more. After the slotting plan is established, you can create replenishment work to bring the appropriate amount of inventory to each location.

Read closely, this is a forward-demand feature. It consolidates demand from orders that currently have a status of Ordered, Reserved, or Released, which is to say the orders on the books right now, and it applies that demand to picking locations, then generates the replenishment to fill them. That is genuinely useful and genuinely slotting-adjacent. What it is not is an analysis of your order history. It looks forward at open demand, not back at twelve months of what actually shipped and what shipped together. Microsoft says exactly this in the introduction, in the clause that settles the whole question: the features plan picking locations "before they release orders to the warehouse." Before they release orders. It is positioning inventory for the demand about to go out, not deriving a placement policy from the demand that has already gone out across a year.

The criteria confirm it. The feature applies demand to locations "based on quantity, unit, physical dimensions, fixed locations, and more." Those are capacity and fit questions: how much, in what unit, how large a unit is, which locations are fixed. Every one of them is about getting inventory to fit into locations, and not one of them is velocity, affinity, or travel. "And more" is a hedge, so it would be wrong to claim the list is exhaustive, and right to notice that nothing named is about which location is closest to where the trip ends, or which two items keep leaving on the same order. There is also a Warehouse slotting allocation enhancements feature, which Microsoft says "enables the system to consider existing on-hand inventory at a target location." Same character: a capacity refinement, not a travel analysis.

So the precise answer is better than "D365 has no slotting." D365 has a Warehouse slotting feature, and it does forward-demand consolidation and replenishment planning, by capacity, and it does them properly. What neither it nor dynamic item placement does is the analytical step this cluster keeps returning to: read a year of order lines, work out velocity and affinity and the net-of-restock economics, and compute where each item should live so the picking that follows is shortest. That computation is the input both features assume you already have. Neither performs it.

Where it sits in the stack

It helps to lay the pieces out, because the D365 warehouse module has several features that touch placement and they are easy to blur together.

Location directives decide where a given piece of work is allowed to go, against constraints such as quantity, batch, and license plate. Chapter 1 confirmed all eleven strategy options and none is based on distance, travel, or velocity.

Dynamic item placement keeps inbound inventory balanced to the preferred locations and target quantities you defined. It is the subject of this article.

The Warehouse slotting feature consolidates current open demand and pre-positions inventory in picking locations to meet it, by capacity, then replenishes. Forward-looking, as the previous section showed, not an analysis of history.

Warehouse spatial location, a preview feature, assigns coordinates to locations and sorts a picking trip by distance. Note that Microsoft’s own dynamic item placement text draws exactly this line: "Warehouse spatial locations further optimize routes, cutting travel time and boosting picking speed." Routes. The vendor itself separates placing inventory from routing the trip through it, and calls spatial location the router.

Analytical slotting is the decision that sits above all of them: given your order history, where should each item live and in what quantity, so that the picking that follows is shortest, net of restock and congestion. It produces the numbers you type or import into the storage policy, and the demand assumptions the native feature pre-positions against. It is upstream of the entire stack, and it is the one layer the stack does not compute for you.

Put simply: location directives enforce rules, dynamic item placement executes a policy, the Warehouse slotting feature positions for open demand, spatial location routes a trip, and analytical slotting decides where things should live in the first place, from history. Four of those five ship in the box. The fifth is the one this whole site is about, and it is not a gap in the product so much as a different kind of work: it is analysis of your data, not a feature you switch on.

So do you actually need slotting on top of this?

The practical question for a consultant standing in front of a customer who has just turned dynamic item placement on. The feature is only as good as the storage policies feeding it, so the real question is where those policies came from.

If the preferred locations and target quantities were derived recently from twelve months of order lines, with velocity, affinity, cube, and restock all in view, then dynamic item placement is the perfect executor for a good decision and everything is working as it should. That is the happy case and it is worth naming.

The common case is different. The storage policies were set at go-live, often years ago, by someone reasonable working from intuition and the layout on the day, and they have not been revisited against demand since. Dynamic item placement is now maintaining that original decision with great discipline, which means it is preserving whatever was right about it and also whatever was wrong, and demand has moved underneath it the whole time. The feature has made the policy easier to hold and has done nothing to check whether the policy is still correct, because that is not its job.

That is the moment the slotting conversation belongs, and it belongs as a data question, not a software question. Nothing needs to be bought or switched on. Someone needs to take the order history and work out whether the targets dynamic item placement is so faithfully maintaining are the targets that make the picking short.

The honest bit about the market

To be straight about the competitive picture, since the obvious next question is whether some add-on already fills this in: I could not find a single product positioned as slotting for Dynamics 365 Finance and Operations in the analytical sense, the kind of tool that reads twelve months of order history and computes the placement policy from velocity, affinity, and travel. If one exists, I would genuinely like to see it. What ships in the box, including dynamic item placement and the Warehouse slotting feature, is the machinery to execute a placement policy and to position against open demand, and to do both well. The derivation of the policy from history is left to you, which in practice means left to a spreadsheet, a consultant, or nobody.

That is not Microsoft failing to build something. It is a reasonable line for a platform vendor to draw: give customers powerful, configurable execution, and leave the domain-specific analysis to whoever knows the customer’s data. It does mean that "we turned on dynamic item placement" and "we slotted the warehouse" are two different sentences, and only one of them has happened.

How to check this on your own system this week

For the consultant or the program manager, this takes an afternoon and it settles the question for a specific customer.

Open the Warehouse and item storage policies and look at the preferred locations and target quantities for your top fifty items by pick volume. For each one, ask the person who owns the system two questions: where did this target come from, and when was it last checked against how the item actually sells. If the answers are "go-live" and "never", you have found the thing this article is about, and dynamic item placement is not the fix, because it is the tool that has been dutifully preserving the untested numbers.

Then take a single fast item and compare its preferred location against where the picking actually concentrates. If your busiest items are being held, faithfully, in locations that were reasonable guesses years ago, the feature is working perfectly and the warehouse is still walking further than it needs to. That is the difference between executing a policy and having the right one, and it is the difference this whole cluster exists to make visible.

If you have configured dynamic item placement for a customer, I would like to know how the storage policies were derived, because in my experience the honest answer is usually "the numbers were already there," and that is exactly the point.

For the broader question this deepens, whether Dynamics 365 optimises placement at all, read Can Dynamics 365 optimize inventory placement?.

For why even a correct placement policy is not the whole story once more than one picker walks the floor, read Why putting your fastest movers together slows the whole line down.

For the full ground-up treatment of the problem this sits inside, read Warehouse Pickup Optimization: The Operator’s Guide.