Why does your pick path zig-zag? Your location format is a…

Why does your pick path zig-zag? Your location format is a sort key

A location name is a string, and every mechanism that orders pick lines orders that string. So the naming scheme somebody chose in week three of your implementation is load-bearing on every shift's walk — and the fix is probably not the one you would reach for.

The name is a string, and the string is what gets sorted

Microsoft is explicit that the name is a constructed thing rather than a label. Configure locations in a WMS-enabled warehouse (ms.date 2026-05-04) defines the object:

"Location formats are a naming system that you use to create unique and consistent names for the different location bin positions within a warehouse. Use separators as part of the location format to make it easier to identify components of the location, such as the aisle number."

A format is a list of segments. Each segment has a Segment description — "For example, it could be Aisle" — a Length, and a Separator, which "determines which character or symbol is used between the first and second component of the name."

That structure matters because sorting happens downstream of it, and the sorter does not know what an aisle is. It knows what a string is.

Location format — What it holds: Segments, their lengths, their separators · Where it is set: Warehouse management > Setup > Warehouse > Location formats
Location profile — What it holds: Which format applies, plus capacity and mixing policy · Where it is set: Warehouse management > Setup > Warehouse > Location profiles
Zone and zone group — What it holds: Logical grouping used as filters in templates · Where it is set: Warehouse management > Setup > Warehouse > Zones

The profile is where the format is attached to real locations, and Microsoft's own emphasis is worth keeping: "The definition of location profiles is very important."

A fixed-length segment stops aisle 10 sorting before aisle 2, and nothing fills it in for you

The classic complaint is that A10 sorts before A2. That is what a text sort does with variable-length segments, and the location format has a field whose entire job is to stop it:

"In the Length field, enter a number. This field determines how many characters this part of the location name must have."

A fixed length is a zero-padded segment. 02 and 10 sort in the order a human expects; 2 and 10 do not. Microsoft documents the field and what it does to the name's width; the sort consequence is ordinary text-sorting behaviour rather than a claim on the page. Either way it is enforced at the format, not left to whoever types the location in.

The Location setup wizard then generates locations from numeric ranges, and Microsoft's example shows the shape:

"The From number and To number fields define how many locations will be created. For example, if you set From number to 1 and To number to 3 for all four lines in the location format, 81 locations will be created (3x3x3x3)."

So the supported path produces consistent, fixed-width, numerically ordered names. A location name that sorts wrongly is one whose segment is shorter than a Length value would have forced. The defect is in the names, not in the product — and the field is one somebody has to fill in, not a default that protects you.

The sort code you are about to look for is on the other side of the fence

Search the documentation for warehouse sorting and you will land on sort codes. Read the scope line before you plan anything around them.

Inventory locations (ms.date 2026-05-04) documents them clearly:

"Use sort codes to optimize the handling of picking lines, which describe the information that is required for picking items from inventory, including the picking order. Sort codes can be specified by the aisle and other coordinates, or assigned manually for the location."

That is exactly the feature you want — and by that page's own two opening statements, not on your side of the fence if you run WMS (warehouse management system — the module that directs work on the scanner):

"Inventory locations determine where you store and pick items in warehouses that don't use warehouse management processes (WMS)." "This article applies to features in the Inventory management module. It doesn't apply to features in the Warehouse management module."

The same boundary appears on warehouse configuration overview (ms.date 2025-11-20), whose opening Note reads: "This article applies to features in the Warehouse management module. It doesn't apply to warehouse features in the Inventory management module."

Two location models, two documentation sets, one word.

If you are WMS-enabled, ordering comes from work and wave configuration rather than from a code on the location record. The cluster profile's own sorting criteria "control the order in which the worker performs the work" (ms.date 2026-04-24).

Chapter 11 gives that setting its own article.

Three mechanisms get confused for each other, and they live in different places:

Sort code on the location — What it orders: Picking lines, by aisle and other coordinates or manually · Which documentation set it is published in: Inventory management — a page scoped to warehouses that do not use WMS
Sorting criteria on the cluster profile — What it orders: "the order in which the worker performs the work" · Which documentation set it is published in: Warehouse management
Sort picking work lines wave method — What it orders: Pick lines within a work record, by measured distance · Which documentation set it is published in: Warehouse management, preview, version floor

What actually makes the path zig-zag, and why renaming will not fix it

Here is the part that survives a correct format. Ascending coordinates and walking order are different things, and no naming scheme reconciles them.

A picker walking a serpentine route goes up aisle 1 and down aisle 2. Sorted ascending, aisle 2's positions run against the way the picker faces. Names right, sort right, walk still wrong at every turn.

That is why the coordinate feature exists. Warehouse spatial location [PP] (ms.date 2026-04-24) replaces the sorted string with measured distance: X, Y and Z on the location record, plus a City Block distance model Microsoft offers for aisle-based buildings.

The distance models and the version floor are on the setup page (ms.date 2026-04-24), which states "10.0.49 or later" and that coordinates are read "directly from the fields on the location record" — maintained by you, one location at a time.

It is preview: the overview page opens "This article is prerelease documentation and is subject to change."

Derive those coordinates mechanically from the location name and you have re-encoded the naming convention as geometry, errors included. A format that sorts is a prerequisite for the coordinate work, not an alternative to it.

Ten characters, and it is a published ceiling

One constraint deserves naming because it decides naming schemes:

"The total of all components in the name, including the separators, can't exceed 10 characters."

Four segments and three separators leave seven characters of actual coordinate. Anyone who has tried to fit site, building, aisle, rack, shelf and bin into a scheme that also sorts has met this ceiling.

It is also the reason a rename is expensive. Every location, every fixed location, every printed label and every operator's memory is keyed on that string.

How we optimize on top of a format that sorts, and where we would draw the line

Pick-Path & Slotting Optimizer decides which orders travel together and which item earns which slot, and writes the answer back into the wave, cluster and slotting objects Dynamics 365 already executes, behind an approval step. Dynamics is the system of record for the warehouse; 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.

We would not sell a slotting optimizer into a building whose location format does not sort. Every downstream sequence inherits it — including a coordinate-based one derived from the same names — so the model would optimize on a known-wrong ordering.

We would not run a rename project for you either. That is your implementation partner's work and it touches labels, fixed locations and training. We will tell you plainly whether it is a prerequisite.

What to do this week

Open one location format and look at the Length fields. Warehouse management > Setup > Warehouse > Location formats. Blank or inconsistent lengths are how variable-width segments get in, and a text sort is unforgiving.
Sort your locations as text and read the first twenty. If aisle 10 appears above aisle 2, the defect is in the data — and the format is where it is prevented for everything created afterwards.
Check which module you are actually in before you plan around sort codes. If Use warehouse management processes is set, the sort-code page is documented as not applying to you.
Walk one wave with the paper in your hand. Where the sequence sends someone back down an aisle they have already walked, that is the serpentine problem, and no naming scheme will fix it.

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 looking at a location rename or a slotting project, book a fifteen-minute call and we will walk your format with you — whether it sorts, and whether that is your real constraint. No deck. https://cognilium.ai

Why does your pick path zig-zag? Your location format is a sort key