TL;DR
Whether a wave stops when no location can be found is a setting on the Location directive failures page. Two documented conditions make a directive line skip silently rather than fail. And Microsoft ships a coverage view that colours which directives, lines and actions were evaluated and which one found a location.
Work creation failed at 07:05. Which location directive did it stop on?
Two questions hide inside that one, with different answers. Whether a wave stops when no location can be found is a setting you chose. Which directive it stopped on is answered somewhere else — somewhere the failure message does not point you at.
Whether it stops is a setting, and it is set per work order type
Microsoft's own worked example ends on the sentence that matters. A putaway directive tries to consolidate, then tries an empty location, and then:
"Unless you define a third action to handle an overflow scenario, two outcomes are possible when there's no more capacity in the warehouse: work can be created even though no locations are defined, or the work creation process can fail. The setup on the Location directive failures page determines the outcome. You can choose whether to select the Stop work on location directive failure option for each work order type."
That is from work with location directives [GA] (ms.date 2025-11-19). Two things follow that are worth saying out loud.
Work can be created with no location on it. A supported outcome, not a bug — and what a picker is holding when nobody can explain the blank line.
The choice is per work order type, so purchase-order putaway and sales-order picking can behave differently in the same building. The page is Location directive failures.
Chapter 4 has the matching switch one level up: Continue wave processing when work creation fails on the wave template. Two switches, two objects, and they can disagree.
Three sequences, and a directive code that skips the first one
- Header — What its sequence decides: Which directive is tried first · Microsoft's wording: "the sequence that the system tries to apply each location directive in for the selected work order type. Low numbers are applied first"
- Lines — What its sequence decides: Which quantity band applies · Microsoft's wording: "the sequence that each location directive line should be processed in for the selected work type"
- Actions — What its sequence decides: Which strategy is tried first · Microsoft's wording: "the sequence that the actions are processed in for the selected work type"
The overall behaviour is on the companion page, control warehouse work by using work templates and location directives: "The system first finds all location directives that match a particular work line … It then sequentially evaluates the directives that it has found."
Now the exception that breaks a lot of mental models, from a Tip on the directive page:
"If you set a directive code, the system doesn't search location directives by sequence number when it needs to generate work. Instead, it searches by directive code."
So if your work template line carries a directive code, reading the sequence list top to bottom is reading the wrong list. Chapter 5 is where that code gets set.
Two documented ways a line is skipped without failing
Unit conversion. On the Unit field: "Every time that it reaches a location directive line, the system tries to convert the demand unit to the unit that is specified on the line. If the unit of measure conversion doesn't exist, the system moves on to the next line."
A missing conversion is a skip, not an error — the line you configured for pallets is never consulted for an item whose unit sequence group does not reach pallets.
Batch-enabled with no strategy. On the Batch Enabled check box: "If you select this check box, and set the Strategy field to None, the system moves on to the next action line."
A ticked box and an unset dropdown produce a silent pass, and both look like working configuration.
One more that changes timing rather than outcome — Immediate replenishment template: "If you leave this field blank, item replenishment doesn't start until all lines of the location directive are processed."
And a documented interface wart, from an Important callout: "The log for a failing test might indicate that a location directive did find a location, but that location didn't match the expected location."
Which directive did it stop on? Two answers, for two different moments
For the failure that already happened, Microsoft points at the work creation history log — acceptance tests exist, in its words, so you can verify outcomes "without having to go through the regular warehouse processes and inspect the work creation history log." That is the 07:05 answer.
For every failure after this one there is a better answer, and it is a feature rather than a technique.
Test location directives with acceptance tests (ms.date 2025-09-09, updated_at 2025-12-30) documents given-when-then tests against your directive set, reached from Warehouse management > Setup > Location directives > Acceptance tests.
"Select Coverage to switch to and from the coverage view. The coverage view uses colored highlighting to indicate which location directives, lines, and actions were used to determine the result of a selected test. Records that are marked yellow were evaluated but didn't find a location. Records that are marked green did find a location."
Evaluated but found nothing, in yellow. Found something, in green — the question in the title, at all three levels at once.
Two properties make this usable live: "Acceptance tests for location directives have no operational impact on the warehouse", and the simulated conditions "don't influence the actual inventory levels in the warehouse."
You can also simulate an empty building — Inventory levels takes Current on-hand inventory or No inventory, the second clearing the item's inventory for the test.
One scope limit, in a Note: you "can't create acceptance tests for location directives where the Scope option is set to Multiple items", with a recommendation to prefer Single item or order and All.
What a test result actually tells you, and the trap in the callout
A test asserts one expected outcome. You "must set one (and only one)" of four Then conditions: Exact location, Location matching regular expression, Location with profile, Location in zone.
The regular-expression option covers today's problem: it is "validated against the resulting location, even if the resulting location is blank (no result)", so a blank result is a legible answer rather than an error.
- Result — Passed, Failed or Skipped
- Resulting location — "The location that was found by the test. If no location was found, this field is blank"
- Locations evaluated — "The number of locations that were evaluated during the test"
- Duration (ms) — "The duration of the test in milliseconds"
- Log — "a work creation history that will help you understand the outcome"
Now the trap, from an Important callout: "To determine the result of the test, the system compares the Resulting location value with the Then condition."
A failed test does not mean work creation failed. It means the directive chose somewhere other than where you said — different, and often more useful.
There is also Run tests after change, which runs every test each time you change a directive.
The number nobody looks at, and it predicts tomorrow's slowness
Locations evaluated is the field to watch, because Microsoft ties it directly to daily performance: "For efficient warehouse operations, you should try to have as few locations as possible evaluated."
Its prescription is the sequence advice again: "have many location directives, the first of which are the most specific and the last of which are the most general. You can also segment your warehouse by keeping certain types of items in dedicated zones."
The Duration (ms) field carries a related warning: "One typical cause of a slow response is the use of location directive queries where the defined ranges or sort orders don't match an index on the table."
How we optimize above this, and where we would draw the line
Pick-Path & Slotting Optimizer decides which orders travel together and which item earns which slot, writing the answer back into the wave, cluster and slotting objects Dynamics 365 executes, behind an approval step. Dynamics is the system of record; the optimization above it is a modelling problem.
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.
The directive set is the clearest boundary in this cluster. A directive faithfully evaluates the rules it was given, in the order given. Whether stock should be in the location it keeps reaching for is a slotting question — a directive reaching three actions deep every time is not broken, it is a slotting plan that stopped matching demand.
We would not edit your location directives. That set encodes physical policy, its sequence is load-bearing, and it is your implementation partner's work.
We would also not model a building whose directives fail regularly. The walk we would optimize is not the one you are getting.
What to do this week
- Open the Location directive failures page and read it per work order type. That is your answer to "does the wave stop", and it can differ between putaway and picking. 2. Write one acceptance test for the directive you distrust most. Set the expected outcome as a regular expression so a blank result is a legible answer. 3. Turn on the coverage view and look for yellow. Evaluated and found nothing, at three levels, is the diagnosis you have been reconstructing by hand. 4. Check the units on every directive line against the item's unit sequence group. A missing conversion skips the line silently.
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 your work creation fails and nobody can say why, book a fifteen-minute call and we will read your directive sequence and coverage with you. No deck. https://cognilium.ai
Sources
- Work with location directives
- Test location directives with acceptance tests
- Control warehouse work by using work templates and location directives
- Wave templates
Sources
Share this article
Warehouse Methods
Topic Cluster
The methods behind the articles — slotting, batching, routing — and the data each one needs.
Mudassir Marwat
Founder & CEO, Cognilium AI
Mudassir Marwat
Founder & CEO, Cognilium AI
Mudassir Marwat's argument is that ERP systems record decisions they never optimise.
