Order Management
Fulfilment integrations
Plan fulfilment integrations around accepted warehouse work, safe order changes, accurate dispatch updates and visible failure recovery.
A fulfilment integration should connect four outcomes: the right order reaches the warehouse, the warehouse accepts the intended work, changes are acknowledged, and completed quantities return to the storefront. Name the system that owns each decision and the record that proves each hand-off succeeded.
Map the hand-offs
Follow an order through the storefront, any order management system (OMS), the warehouse management system (WMS) and the shipping connection. For each transfer, record the sending event, receiving record, shared identifiers and person responsible for a failure.
| Hand-off | Question to settle |
|---|---|
| Store to warehouse | Which lines may be released, and what proves the warehouse accepted them? |
| Change after release | Can active work be stopped or revised, and who confirms the physical position? |
| Warehouse to store | Which lines and quantities were fulfilled, and which shipment carries them? |
| Failure and recovery | Where is a missing or rejected transfer visible, and how is a retry checked? |
Keep payment review, warehouse progress, fulfilment and carrier handover distinct. A tracking number can exist before a parcel reaches the carrier. Define what the operation means by “dispatched” before using that word in a status or customer message.
Separate authority from transport
Write down which system owns order and financial processing and which system owns warehouse execution. In Microsoft Dynamics 365 Warehouse management only mode, an external ERP can manage order and financial processing while Supply Chain Management handles logistics operations; an owner inventory dimension can distinguish inventory shared across source systems.
This division gives each exception a clear decision-maker: the warehouse can report what work it can perform, while the order-owning system remains responsible for the commercial record. Document the boundary and the record each system must return before treating a hand-off as complete.
System Ownership in Fulfilment Integrations
- Order & Financial Processing
- External ERP (e.g., Microsoft Dynamics 365 Supply Chain Management)
- Warehouse Execution
- Warehouse Management System (WMS) – e.g., Dynamics 365 WMS only mode
- Inventory Ownership Dimension
- Used to track stock origin across systems; critical for reconciliation
Keep the records connected
Use stable source order and line IDs, plus a separate reference for each warehouse instruction or fulfilment part. Map sellable variants and units explicitly. An instruction may also need the assigned location, delivery method, quantity, destination and any hold or handling requirement.
Return actual fulfilled quantities against the same lines, with shipment and tracking references where available.
An order number or SKU alone may be ambiguous across systems. Agree which identifiers are unique and how the receiving record links back to its source. Retain the original ordered quantity when work is split or reduced so the remaining obligation stays visible.
Shopify’s Order object includes fulfilment orders containing purchased line items. Its fulfilment-service workflow distinguishes a request from its acceptance and allows cancellation requests.
Microsoft’s Warehouse management only mode shows an inbound pattern: an external inbound shipment-order message is processed into orders before warehouse receiving operations.
Where inventory is shared across source systems, the ownership dimension can help the warehouse record which source owns the stock. Include that ownership in the records used to investigate a mismatch, rather than relying on an order reference alone.
Check acceptance and completion
A successful export or HTTP response proves only that step. Compare the intended order lines and quantities with the warehouse records actually accepted for work. Record rejections and their owner.
If a response is lost, look for an existing instruction before sending another; a retry must not create a second pick for the same work.
On the return path, update only confirmed line quantities and attach tracking to the relevant fulfilment or shipment. Leave unfinished quantities open.
In Shopify’s GraphQL Admin API, fulfillmentCreate accepts line quantities, tracking information and a customer-notification choice. If line items are omitted for a specified fulfilment order, it fulfils all items in that fulfilment order. A partial dispatch therefore needs explicit line and quantity handling.
Define acknowledgement states
For a Shopify fulfilment service, a request is not the same as accepted work. The service has a dedicated location, can accept or reject fulfilment requests, and can query its assigned fulfilment orders to determine which actions are available.
Record these states separately rather than treating a sent request as warehouse acceptance.
Orders can contain more than one delivery method, such as shipping and pickup. Assess each delivery group or fulfilment order independently so that a response for one method or location does not stand in for the whole order.
After a request is approved, a merchant can submit a cancellation request before the order is shipped. Preserve that request and the service’s response as distinct records; the request itself does not establish that warehouse work was cancelled.
Give exceptions an owner
Put edits, cancellations, missed events and rejected imports in a visible queue with the source reference, last confirmed state, affected lines and next action. Shopify cautions that some fulfilment apps might not recognise order edits. Its webhook guidance also recommends detecting duplicate deliveries.
Check current source and warehouse records before replaying an uncertain message.
When assessing a connection, follow an ordinary order and a few relevant exceptions through the sending record, warehouse response, work created and returned fulfilment.
Make event evidence verifiable
If Shopify webhooks carry changes between systems, configure the subscribed topics and delivery destination deliberately. For HTTPS deliveries, verify the HMAC signature in the X-Shopify-Hmac-SHA256 header against the raw request body before trusting the payload.
Use the webhook delivery ID to recognise duplicates, and retain enough delivery evidence to connect an event to the receiving record and any resulting action. This supports reconciliation when an event is repeated or its processing outcome is uncertain, without treating the event itself as proof that warehouse work occurred.
Webhook Verification for Event Integrity
- Pros
- HMAC signature verification ensures payload authenticity; delivery ID prevents duplicates
- Cons
- Lost responses require rechecking existing records to avoid double processing
In this guide
- Connecting store orders to a warehouse systemMap store order lines to warehouse instructions, confirm acceptance and prevent duplicate work when an import must be retried.
- Syncing dispatch confirmation back to a storefrontReturn the right dispatched lines, quantities and tracking details to a storefront without closing unfinished parts or duplicating notifications.
- Handling orders modified after warehouse releaseHandle late order edits by checking live warehouse work, confirming a stop or revision and reconciling the final parcel and order.
- Monitoring a failed order importFind where an order import failed, inspect the rejection, retry safely and reconcile the accepted warehouse work.
