# Order management modernization: design for the exceptions

By Devekko · Published 2026-10-28

Give every order state and exception a clear owner.

Order management modernization should make the next valid action on an order clear. A customer, warehouse operator, and finance team can each see a different part of the same transaction. The job is to connect those views without losing the rules that protect stock, payments, and customer promises.

## Map the order at line level

Start with the order lifecycle: received, checked, allocated, released, shipped, canceled, returned, and refunded. Your business may need different states. Define what each state means, which system owns it, and which changes are permitted.

An order header is often too coarse for operations. One line can ship from one location while another waits for stock. A return may concern only one item. Keep the relationship between the order, its lines, shipments, payments, and refunds visible in the design.

[Microsoft's order-orchestration guidance](https://learn.microsoft.com/en-us/dynamics365/intelligent-order-management/orchestration-flows) describes flows from order capture through fulfillment and billing. Use that as a conceptual reference. Your acceptance criteria should reflect the actual channels, stock rules, and service promises your business operates.

## Assign the exception before automating it

List the situations that currently trigger a message, spreadsheet row, or phone call. Common examples include unavailable stock, an unrecognized address, a payment mismatch, a failed warehouse handoff, and a cancellation received after picking starts.

For each exception, identify the person who can resolve it and the information they need. An alert without an owner creates another place to check. A useful queue shows the reason, age, customer impact, permitted actions, and the record of what has already been tried.

## Write an order-state acceptance sheet

| Scenario | Rule to agree | Acceptance evidence |
| --- | --- | --- |
| Split shipment | Which lines can move independently? | Correct status for every line and parcel |
| Short stock | Reserve, backorder, substitute, or cancel? | Approved allocation and customer response |
| Repeated event | How is the same business action recognized? | A retry does not create another shipment |
| Cancellation during picking | Who can stop the warehouse action? | Clear cutoff and handled exception |
| Partial return | Which stock and payment records change? | Item disposition and correct refund scope |
| Failed integration | Who owns retry and reconciliation? | Visible failure, recovery record, and current state |

## Rehearse events that arrive at the wrong time

An integration may retry a message, receive an older status after a newer one, or lose a connection after an action succeeds. Ask the implementation team how it distinguishes a retry from a new instruction. Each consequential action needs a durable identity and a defined recovery path.

In an illustrative test, an order is sent to the warehouse, but the acknowledgment is lost. The integration retries. The acceptance condition is one fulfillment instruction, with both attempts traceable. Counting successful API responses would miss the business problem of duplicate physical work.

Another test sends a cancellation while a picker is working. The system must reflect the agreed operational cutoff. It should show a resolvable exception when automatic cancellation is no longer safe, rather than silently claiming the order was stopped.

## Decide whether the missing piece is a separate OMS

Some businesses can meet their requirements by improving their ecommerce, ERP, or warehouse platform and the connections between them. Others need a dedicated order-management layer. Compare those options against the same difficult scenarios.

Ask who will configure the rules, investigate exceptions, maintain connectors, and accept vendor changes. Include these responsibilities in the cost comparison. A central screen may be useful, but it does not by itself create clear ownership.

## Measure effort and customer impact together

Track manual touches per order, unresolved exceptions by age, and time to dispatch. Segment by channel or order type where the work differs. Pair speed with accuracy so faster processing does not hide more corrections.

Use the [ecommerce integration guide](/services/enterprise-modernization/articles/ecommerce-systems-integration) to test the storefront handoff and the [warehouse guide](/services/enterprise-modernization/articles/warehouse-modernization) to test what happens after release. Accept the whole path with the people who operate it.