Which demand documents can Dynamics 365 actually cross-dock?

The question has two answers, because there are two cross-docking features. Almost every summary you will read collapses them, quotes the narrower one's limits, and concludes the product barely cross-docks at all.

Two features, and the limits you have heard belong to one of them

Opportunistic cross-docking — What it is documented as: Cross-docking from a production line to an outbound dock, used "if there is a demand for shipping the product" instead of putting it away · Where it is documented: Production control
Planned cross-docking — What it is documented as: A cross-docking template evaluated at release to warehouse, where "the inventory quantity that is required for an order is directed straight from receipt or creation to the correct outbound dock or staging area" · Where it is documented: Warehouse management

Planned cross docking [GA] (ms.date 2025-06-17) states the payoff plainly: it "lets workers skip inbound put-away and outbound picking of inventory that is already marked for an outbound order. Therefore, the number of times that inventory is touched is minimized, where possible."

Both features are real, both are supported, and they answer the headline differently. So the first thing to establish in any cross-docking conversation is which one is being discussed.

Opportunistic cross-docking: three limits, and Microsoft hedges every one

Cross-docking from production orders to outbound docks carries the three sentences that get quoted. Read the first word of each:

Work order types — "Currently, cross-docking can be configured for only two work order types" — Finished goods put away and Co-product and by-product put away
Document type — "Currently, the only document type that is supported is Transfer orders."
Strategy — "Currently, there is only one strategy: Date and time."

Every one opens with Currently. That is a statement of present scope, not an architectural commitment, and Microsoft goes further on the same page — the sequence number on a cross-docking policy "will become relevant only when more work order types are supported."

A vendor explaining what a field will be for when it supports more types is telling you the limit is a roadmap position rather than a design boundary.

And the page's date matters. Its ms.date is 20 June 2017, with updated_at 7 May 2025 — the oldest source in this cluster by some distance. So those three "Currently" statements are dated 2017 and carried forward. Treat them as what is documented, confirm them in your version, and do not repeat them as permanent.

One useful thing that page does settle: the scenario "is supported for batch and serial controlled items, both with the batch and serial number dimensions defined above and below location in the reservation hierarchy" — which is unusual, because chapter 2 is largely about the things that do differ by that choice.

Planned cross-docking: a template, a supply-source list, and sales orders

The planned feature is configured as a cross-docking template at Warehouse management > Setup > Work > Cross docking templates, with a Supply sources FastTab where "you specify the types of supply that are valid for this template."

Microsoft's worked scenario is the answer to the headline question: a purchase order as supply and a sales order as demand. The release-to-warehouse action "creates a shipment and load line for the sales order line, and tries to allocate inventory", and the shipment's load line then shows a Planned cross docking quantity.

That is the wave boundary, and it is why chapter 4 matters here. Microsoft's own scenario even reproduces the message you get when the wave finds nothing to allocate: "No work was created for wave XXXX. See the work creation history log for details." — expected, "because there's no inventory in the warehouse."

At receipt, the split is two work records: one with work order type Cross docking "directed to the final shipping location so that it can be shipped out immediately", and one with work order type Purchase orders carrying "the remaining quantity" to storage.

The template's planning fields are where the policy lives. Demand requirements takes None, Marking or Order reservation, and Locating type decides "whether the cross-docking work should use the staging/load locations from the shipment, or whether it should use location directives to find its own".

Validate time window enables a Maximum time window, which "defines the maximum period that is allowed between supply arrival and demand departure."

There is also a directive-code option, enabled by the Cross docking templates with location directives feature — and Microsoft notes that "as of Supply Chain Management version 10.0.29, the feature is turned on by default." Where a directive code is set, "the system will search location directives by directive code when work is generated", which is the same bypass chapter 6 describes.

The limit that actually bites, and it is not a document type

Here is the constraint most likely to break a design, and it is in a Note rather than in a limits section:

"The query for cross docking templates has only the InventTable (standard items) table and the inner-joined WHSInventTable (warehouse management processes (WMS) items) table. If you want to add other tables to the query, you can join them by using only exist joins or not exist joins. … Therefore, filtering by source documents such as sales order lines or customers can't be done out of the box."

Read that against the question in the title. Planned cross-docking will happily serve a sales order — but you cannot write a template that applies to these customers, these sales orders, or this channel. Template selection is driven from the item, not from the document.

So the honest answer to "which demand documents can it cross-dock" has two halves. Which types: more than the opportunistic page's single type, including the sales orders in Microsoft's own scenario. Which specific documents: not selectable in the template query, by that Note.

That is a sharper and more useful limit than a list of supported types, and it is the one nobody quotes.

Three Notes that will cost you a day each

All three are on the planned cross-docking page, all are Notes, and none is in a section a reader would think to check.

Cancellation does not unregister. "Inventory transactions are not unregistered when crossing-dock work is canceled, even if the setting for this capability is turned on in Warehouse management parameters." Microsoft's own typo is reproduced.

Work class IDs must match. "The work class IDs for the Pick and Put work types must be the same." That is the opposite of chapter 5's advice for ordinary outbound work — work templates and location directives is where different work classes are how you split tasks between people.

Query on Start location, not Location. If you want the cross-docking work template applied at a specific location, "you must filter on the Start location field, not the Location field, because work creation for the inbound processes (purchase, cross docking, and replenishment) starts from the put line."

That last one is a genuine trap: the field you would reach for is populated later, by the location directive, from the put location.

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.

Cross-docking is where that boundary is easiest to see. The template asks whether supply and demand fall inside a time window. Whether a given order should be cross-docked at all — given today's dock capacity, labour and the rest of the wave — is a different question, and no field on the template is being asked it.

We would not write a cross-docking template for you. It encodes a physical policy about docks and trailers, and it is your implementation partner's work.

We would also not build the source-document filter the Note rules out. That is an extension to a vendor's query framework, which is a different business from ours and a maintenance liability for you.

What to do this week

Establish which feature you actually run. Cross-docking policies under a work policy point to the opportunistic flow; a cross-docking template with a supply-source list is the planned one.
If someone told you the answer is "transfer orders only", check which page they read. That sentence is on the production page, it opens with "Currently", and its date is 2017.
Read your template's Maximum time window against real dock behaviour. It is the field that decides whether supply and demand are considered a pair at all.
Check whether anyone has tried to filter a template by customer or sales order. The Note says that cannot be done out of the box, so a design that assumed it needs revisiting rather than debugging.

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 cross-docking scope is holding up a design, book a fifteen-minute call and we will read both feature sets against your flow. No deck. https://cognilium.ai

Which demand documents can Dynamics 365 actually cross-dock?