Can Dynamics 365 run as a standalone WMS beside another ERP?

Yes — Microsoft ships a mode for exactly that, and publishes the limits as a table you can read before you commit. The row everyone quotes is the production one, and it is narrower than the way it is usually repeated.

Yes, and the disqualifying limits are published

Warehouse management only mode overview [GA] (ms.date 2025-11-20) defines the thing:

"Warehouse management only mode lets you set up a legal entity in Microsoft Dynamics 365 Supply Chain Management that's dedicated to warehouse management processes. This legal entity can then provide warehousing services to other legal entities in Supply Chain Management. Alternatively, it can provide warehousing services to external enterprise resource planning (ERP) systems or order management systems."

For the standalone-beside-another-ERP case, Microsoft states the pitch directly: you "can now quickly deploy our advanced WMS functionality without having to set up or maintain areas of Supply Chain Management that you don't need."

This is also the feature Microsoft named as the replacement when it deprecated scale units — the register says "formally deprecated as of Supply Chain Management version 10.0.40 and will be completely removed for all customers one year after the release of that version", so removal is still written in the future tense on a page dated 24 June 2026. Deprecated is what it says; retired is what it would be easy to write. Per the deprecation register, warehouse management only mode "replaces some of the functionality planned for scale units and adds many new architectural and integration possibilities." Chapter 7 has that calendar; the word some is Microsoft's.

Two scenarios, three deployments, and a hybrid that changes the answer

Microsoft names two basic scenarios and then publishes three deployment shapes:

External ERP system — Dynamics runs warehousing while "an external system is used to handle all orders and financial processing"
External shared warehouse — "logistic operations run in a separate legal entity" sharing services "with other legal entities that manage all the order and financial processing", tracking ownership "by using an owner inventory dimension"
Both at once — Dynamics handles warehousing "plus a wider range of processes (such as sales, purchase, and production orders)" and warehouse operations for external systems

The third is the one that matters for how you read the limits:

"The following high-level diagram shows an example where a system uses Supply Chain Management to handle warehousing, plus a wider range of processes (such as sales, purchase, and production orders). At the same time, it also uses Supply Chain Management to handle warehouse operations for other ERP and order processing systems."

And: "For this type of implementation, the same warehouse instance can handle all the logistic warehouse processes for both internal and external integrations."

Production orders appear in that sentence. Hold onto it until section 5, because it is the reason the production limitation is not the disqualifier it is usually described as.

The lightweight documents are the whole design

Everything in the unsupported list follows from one design decision:

"Warehouse management only mode uses lightweight source documents that are dedicated to inbound and outbound shipment orders. Because these documents focus exclusively on warehouse management, they can replace multiple types of more general-purpose documents (such as sales orders, purchase orders, and transfer orders) from a pure warehouse management perspective."

A lightweight document carries less. So the things it cannot do are the things the heavier documents were carrying — vendors and customers, registration state, transportation charges. Read the table with that in mind and it stops looking like a list of gaps and starts looking like a consequence.

The unsupported list, quoted

Microsoft's own scoping sentence comes first, and its hedge is load-bearing:

"The following high-level processes aren't supported out of the box when Warehouse management only mode is processed. The list is most relevant to existing customers who already run warehouse management processes and are considering adopting the Warehouse management only mode functionality."

Production flows — "Inbound and outbound shipment orders don't support production order, batch order, or kanban processing, including material consumption and reporting as finished via the Warehouse Management mobile app. In addition, you can't use cross-docking from production orders to outbound docks in combination with inbound and outbound shipment orders."
Inbound app flows — No goods in transit "where the receiving process is handled against a container", and no sales return orders "that support return reason codes and disposition codes as part of the flow for the Return order receiving (and put away) mobile device menu item. Instead, you must use the blind return process."
Transportation management — "The transportation management engines that are currently supported for purchase order loads aren't supported for the inbound shipment order processes… charges can't be assigned, and direct invoicing can't be processed, for either inbound shipment orders or outbound shipment orders. Therefore, the apportionment weight engine can't be used to generate freight bills."
Creating orders from the app — "The process of creating outbound shipment orders from the Warehouse Management mobile app isn't supported."
Internal order data to external systems — For supported Supply Chain Management orders, "no business events or related inbound and outbound on-hand information is provided to external systems for these types of processes." Use "Warehouse inventory update logs" instead
Order-committed reservations — Version-dependent — see section 6
Catch weight items — "Items that are enabled for catch weight processing aren't supported for inbound or outbound shipping orders."
Vendor and customer account policies — "Representations of vendors and customers aren't used for inbound or outbound shipping orders. Therefore, you can't use related order processing policies with this type of setup" — no customer- or vendor-specific product filters, no nonconformance management
Order line registration — "Inbound and outbound shipment order lines don't support the manual registration and un-registration processes that are supported by other types of order lines (such as purchase, sales, and transfer order lines)."

Three rows cost money rather than features. No business events for internal orders closes the obvious notification path for transfer, sales, purchase and production orders, and Microsoft names the alternative rather than leaving a gap.

No charges and no direct invoicing keeps freight billing in the other system. And no manual registration removes a correction mechanism your warehouse team may use daily.

Production: read what the row actually scopes

Here is the sentence again, with the subject in bold:

"Inbound and outbound shipment orders don't support production order, batch order, or kanban processing…"

The subject is the lightweight documents. It is not the legal entity, the mode, or the warehouse instance. And the third deployment diagram in section 2 describes Supply Chain Management handling "production orders" alongside warehouse operations for external systems, in "the same warehouse instance".

So the accurate version of the limitation is narrow and useful:

If a manufacturing process must be driven through inbound and outbound shipment orders, that is unsupported.
If production runs on regular production orders in Supply Chain Management while the warehouse also serves an external ERP through shipment orders, that is the third documented deployment.

So the disqualifier is needing production driven through the lightweight documents — not where the orders come from. Read the two bullets above in order and the distinction is Microsoft's, not ours: a manufacturer whose order capture sits in the external ERP is the third documented deployment so long as production runs on regular production orders in Supply Chain Management. It is only a disqualifier when the manufacturing process itself has to run through the shipment orders.

Chapter 8's material lands here too: the same row rules out combining cross-docking from production orders with inbound and outbound shipment orders — which is the opportunistic flow, one of the two cross-docking features that chapter distinguishes.

Three rows that turn on decisions made elsewhere

The reservations row is the one to check against your version, and it quotes cleanly:

"In Supply Chain Management version 10.0.46 and later, order-committed reservations are fully supported as part of the allow reservation on demand order capability." "In Supply Chain Management version 10.0.45 and earlier, outbound shipment order line transaction reservations don't support reservations on inventory dimensions below the location in the reservation hierarchy. However, these reservations are supported for sales order line transactions."

That is chapter 2's decision deciding a chapter 12 question. If your batch sits below location and you are on the earlier versions, outbound shipment order lines behave differently from sales order lines for the same item.

The catch-weight row is a straight exclusion, and it is the second time catch weight has closed a door in this cluster — chapter 1 records it on the published validation list for migrating an item to warehouse processes. If you run catch-weight items, check both.

And the registration row is the one operations people notice. Manual registration and un-registration exist for purchase, sales and transfer order lines and not for shipment order lines, so a team that fixes receipts by re-registering will need a different habit.

Two documented ways to desync the two systems

The overview tells you what is unsupported. The companion page, warehouse management only mode with external ERP systems (ms.date 2026-05-22), tells you how it goes wrong in practice — and both failures are about on-hand quantities rather than about features.

Microsoft splits the process steps by owner: "Steps that start with ERP are done by the ERP system. Steps that start with WOM are done by Supply Chain Management in Warehouse management only mode."

Inbound ends when Dynamics runs a receiving completed process that triggers "business events for the external systems". Outbound ends when loads are ship confirmed and a shipment packing slip is created.

Desync one: acting on the balance instead of the change. Microsoft's warning is blunt — "It's important to act only on the updated quantities. Otherwise, the systems can go out of sync because of the updates."

Its worked example is the clearest thing on the page. A counting journal adds one piece, and "the journal posting changes from 10 pcs to 11 pcs in Supply Chain Management. The external system considers only the updated quantity of 1 pcs." An integration that took the posted balance instead would overwrite a receipt the other system had not been told about yet.

Desync two: double counting the same movement. If you turn on the faster synchronisation path, there is an Important callout waiting:

"When the Enable warehouse inventory update logs option is enabled, be sure to uptake the updates in the external systems in such a way that they don't cause double updates in combination with the data that's used as part of the Shipment receipts and Shipment packing slips messages."

The log itself is for "integrations that require very quick on-hand inventory synchronization processes", enabled per source system for inbound and outbound shipment orders. Microsoft states the cadence: "By default, the Publish warehouse inventory update log updates background process runs every 10 minutes."

There is also a reconciliation report — Create source system on-hand inventory under Warehouse management > Inquiries and reports > Physical inventory reconciliation.

One parameter on it matters, because registered and picked quantities sit in limbo until the journals post: "To include this part of the physical on-hand inventory in the export, be sure to enable the Include Registered and Picked inventory quantities parameter."

And one configuration trap that fails messages rather than quantities. If you use the owner dimension for shared inventory:

"The Warehouse inventory owner configuration must contain a mapping for every Owner value that a source system sends in the order line. If a mapping is missing, the order message fails to process. This requirement also applies when the source system sends an empty owner value."

An unmapped owner — including an empty one — fails the order message. That is the kind of detail that turns up on day three of a pilot.

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

This mode is the cleanest case for that design. The wave, cluster, work and slotting objects are the same objects whichever document set feeds them, so an optimizer writing into them does not need to know whether demand arrived as a sales order or as an outbound shipment order.

We would not build the ERP integration. Mapping another vendor's order documents onto inbound and outbound shipment orders is your implementation partner's deliverable, and it is the work Microsoft's own external-ERP guidance is written for.

We would also not model against a warehouse whose inbound data arrives through a path nobody has reconciled. If the external system's on-hand and the warehouse's on-hand disagree, that is a data problem, and an optimizer on top of it produces confident answers about a building that does not exist.

What to do this week

Read the unsupported table against your own order flow, row by row. It is nine rows and it is the honest scoping document for this decision — Microsoft published it for exactly this evaluation.
Establish where production orders will live. If they stay in Dynamics, the production row constrains much less than its reputation; if the manufacturing process itself must run through the shipment orders, it is the disqualifier.
Check your version against the reservations row. The behaviour for outbound shipment order lines below location differs across the versions named, and your batch position decides whether that matters.
Ask your warehouse team how often they manually re-register a receipt. That mechanism does not exist for shipment order lines, and it is the kind of daily habit nobody lists in requirements.

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 weighing Dynamics as the warehouse layer beside another ERP, book a fifteen-minute call and we will read the unsupported table against your order flow. No deck. https://cognilium.ai

Can Dynamics 365 run as a standalone WMS beside another ERP?