Cluster picking: process by location, or process by position?

Cluster picking: process by location, or process by position?

One field on the cluster profile decides whether your picker takes a consolidated quantity and then sorts it into positions, or picks each position separately. Choosing the second option and pressing Save deletes the cluster sort criteria you already have.

One field, three options, and a save that deletes

Set up cluster picking [PP] — the product page carries no preview banner; the feature's own release-plan entry does, and the status section below quotes it — (ms.date 2026-04-24, updated_at 2026-04-24) describes the field's job in one sentence:

"The cluster picking strategy controls whether workers pick inventory for all cluster positions at a location in a single step, or handle each position individually. Set this option as part of the cluster profile."

The prerequisite is a version floor and nothing else: "To use the cluster picking strategy feature, you must be running Supply Chain Management version 10.0.48 or later."

Before the strategies, the constraint that makes this a real commitment. Once a work order is in a cluster, "the worker must use cluster picking to perform the picking work for the order. The worker can't use other picking methods. If you mistakenly assign a work order to a cluster, the worker must break the cluster and then re-create it."

The three strategies, in Microsoft's words

The field is Cluster picking strategy, on the General FastTab of a cluster profile at Warehouse management > Setup > Mobile device > Cluster profiles.

• *Process by location — "At each pick location, the worker picks the total quantity across all cluster positions in a single step. The system then presents a sort step where the worker distributes the picked quantity to each position. You can fully customize cluster sort criteria. This strategy is the default.*"
• *Process by position (tracked items) — "the worker handles each cluster position one at a time, but only for items tracked by batch or serial number that are below the location level. The Process by location* strategy still applies to non-tracked items at the same location."
• *Process by position (all items)* — "the worker handles every cluster position one at a time, regardless of whether the item has tracking dimensions."

The middle option is the interesting one, and it has two conditions inside it. It applies only to items tracked by batch or serial number below the location level — which is chapter 2's decision, arriving in a scanner screen. And it is a mixed mode: non-tracked items at the same location keep the by-location flow.

There is a further exclusion in a Note: "When you select Process by position (tracked items), the system excludes serial-tracked items where the serial number is captured at packing from by-position processing. Because the serial number isn't required until packing rather than picking, those items continue to use the Process by location flow."

So one location can run two flows at once, decided per item by tracking dimensions and by when the serial is captured. That is worth knowing before you tell a supervisor what the screens will look like.

The sort step is the thing being removed, and Microsoft says why

Under the default strategy, Microsoft's published sequence at one location ends with a distribution step: the device "shows the total quantity to pick for all cluster positions at that location", the worker "picks the consolidated quantity in a single scan", and then "The device presents the sort step. The worker distributes the picked quantity to each cluster position."

Here is the sentence the whole feature exists for, and its hedge is reproduced:

"For items without tracking dimensions, this flow is efficient. For batch- or serial-tracked items, however, the sort step requires the worker to assign specific batch or serial numbers to specific positions, which can be complex and error-prone."

Note can be, not is. Microsoft is describing a risk, not asserting that every site experiences it.

With either by-position option, "the sort step is eliminated", and the reason it can be is mechanical: "Because each pick step is already tied to a specific position, batch and serial numbers are captured per position at the moment of picking. No post-pick distribution is needed."

Microsoft publishes both flows for a two-position cluster picking a serial-tracked item, and the difference is legible at a glance:

• "Pick 3 units from location A-01-01" — scans item and license plate — "Position 1 – Pick 1 unit from location A-01-01" — scans item and serial number
• "Sort: assign quantity to Position 1" — enters 1, confirms 1 unit — "Confirm Position 1"
• "Sort: assign quantity to Position 2" — enters 2, confirms 2 units — "Position 2 – Pick 2 units from location A-01-01" — scans item and serial numbers
• "Put cluster to staging" — confirms location — "Confirm Position 2", then "Put cluster to staging"

Same location, same order set, same quantities. The by-position column has more steps and each one carries less to remember, which is the trade being made.

The save that deletes, and the switch back that does not restore

This is the warning to take away from the article. It is an Important callout, and it is destructive:

"When you save a cluster profile with Process by position (tracked items) or Process by position (all items) selected, the system automatically deletes any existing sort criteria and creates the following four default sort fields: 1. Location (ascending) 2. Item number (ascending) 3. Work ID (ascending) 4. Line number (ascending)"

Any existing sort criteria. If somebody spent a year tuning the cluster sequence for your building, selecting a by-position strategy and saving replaces that work with Microsoft's four defaults.

You can edit the defaults afterwards — "You can manually edit these sort criteria after they're created" — but Microsoft immediately explains why the first one matters:

"changing the sort order can lead to a suboptimal picking route. For example, if the sort criteria no longer group work by location first, the system might direct the worker to pick one position at a location, then travel to a different location for another position, and then return to the original location to pick the remaining position there. This change results in unnecessary travel between locations."

That is a vendor describing a re-walk in plain terms, on the page for the feature that causes it. It is also the clearest statement in the documentation that sort criteria are a travel decision, which is the pillar's argument arriving in a specific screen.

Now the asymmetry, which the brief did not know about and which decides how you should sequence the change:

"If you switch back to Process by location after previously using a Process by position strategy, the auto-created sort criteria remain in place. You can then edit or remove them as needed."

Switching in deletes. Switching back does not restore. The four defaults stay, and your original criteria are gone — so the reversal is a reversal of the picking flow only, not of the configuration change that came with it.

There is one practical consequence and it is not in the documentation: record your existing cluster sort criteria before you change this field, because nothing on Set up cluster picking describes a way to bring them back after the save. That is a claim about that page, which is the page that documents the deletion.

Ascending and descending: read Microsoft's own examples twice

The Cluster sorting FastTab is where the criteria live. Each row takes a Sequence number, a Field name — "if you select the WMSLocationId field, the work is sorted by location" — and a Sorting value.

Here are both values, quoted exactly as published:

"Ascending – Work is sequenced in ascending order based on the sorting criteria. For example, if you use the WMSLocationId field as sorting criteria, and your location IDs are 1, 2, 3, and 4, workers pick from location 4 first." "Descending – Work is sequenced in descending order based on the sorting criteria. For example, if you use the WMSLocationId field as sorting criteria, and your location IDs are 1, 2, 3, and 4, workers pick from location 1 first."

Read the worked examples against their labels. Ascending is illustrated by picking the highest location first; descending by picking the lowest. Both examples read the opposite way round from the plain meaning of the words.

This article does not resolve that. It is reproduced character-exact because it is what the page says, and because the alternative — quietly "correcting" it — would tell you the sequence behaves in a way we have not established. Neither the label nor the example is safe to design a pick route from. Set one criterion in a sandbox, run one cluster, and watch which location the device asks for first.

That is a five-minute test, and it is worth more than either sentence above.

Its status: this is a public preview, and the product page does not say so

The product page documents the strategy with a version floor of 10.0.48 or later, and — measured on the page as fetched — carries no preview banner and no feature-management requirement. Which is the whole reason this section exists.

The 2026 release wave 1 plan (ms.date 2026-07-28) has a Warehouse management row titled "[Enable precise serial and batch capture in cluster picking]", and that row is a link. Its own entry (ms.date 2026-05-06, updated_at 2026-05-21) says what it covers:

"This feature lets you control how serial and batch numbers are captured during cluster picking for items tracked below the location level in the reservation hierarchy. You get two new strategies in the cluster setup: capture serial and batch numbers once before distributing items or capture them separately for each cluster position. The new Enum in the cluster setup UI makes it easy to choose your preferred mode".

Two new strategies in the cluster setup, for items tracked below the location level, selected from a new enum in the cluster setup UI. That is the field this article is about, described in different words.

And the same entry carries the status. It opens with an Important callout:

"Some of the functionality described in this release plan has not been released. Delivery timelines may change and projected functionality may not be released".

Its availability table reads Public preview — a check mark, and Apr 24, 2026 — against General availability of Jun 2026 with no check mark. The plan's legend is explicit about how to read that: "Released features show the full date, including the date of release", and the check mark "shows which features have been released for public preview and general availability."

So it is [PP]: publicly previewed since April 2026, not generally available, whatever the calendar now says about June. This article carries that label throughout.

The product page's silence is not a counter-argument, and it is the practical point. A reader who configures this from the documentation sees a version requirement and no warning at all. If you are planning a rollout on the by-position strategies, the status is on a roadmap page you would have to go and find.

How we optimize around this, 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.

Cluster composition is what we optimize here. The strategy field decides how a picker handles the positions in a cluster; which orders belong in the cluster together is a different question, and the profile is not being asked it. Microsoft's re-walk example is what happens when composition and sequence disagree.

We would not change your cluster picking strategy. It rewrites sort criteria on save, it changes what a worker sees on every pick, and it belongs to whoever answers for the shift.

We would not write cluster sort criteria either. After the ascending example above, we would not claim to know what a criterion does in your version without watching it run — and neither should anyone else selling you a pick path.

What to do this week

1. Export your current cluster sort criteria and keep the file. Selecting either by-position strategy and saving deletes them, and nothing documented brings them back.
2. Check your version against the floor. The strategy field requires 10.0.48 or later, so on an earlier version this decision is not yet available to make.
3. Find out whether your tracked items sit below location. The tracked-items strategy applies only to batch- or serial-tracked items below the location level, so chapter 2's answer decides whether the middle option does anything for you.
4. Run one cluster in a sandbox and watch which location comes first. The documented ascending example picks the highest location ID first. Whatever your version does, you want to have seen 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 cluster-pick tracked items and are looking at this field, book a fifteen-minute call before you save it and we will walk the consequences with you. No deck. https://cognilium.ai

Sources

• Set up cluster picking
• New and planned features for Dynamics 365 Supply Chain Management, 2026 release wave 1
• Enable precise serial and batch capture in cluster picking

Sources

• learn.microsoft.com — set up cluster picking
• learn.microsoft.com — planned features
• learn.microsoft.com — enable precise serial batch capture cluster picking