A workflow sends a paid order to a fulfilment system. In a demonstration, the order arrives, the destination accepts it and the status updates. In daily operation, a product identifier may be missing, an address may change or a connection may fail after the destination has already created the record.
Exception handling is the work of deciding what happens next. Which cases can be retried? Which need a person? How do you avoid repeating an action? How can operations tell whether the order is waiting, failed or complete?
Answer these questions while designing the workflow. They determine whether automation removes manual checking or merely moves it into several dashboards.
Start with one business outcome and its owner
Choose a bounded outcome, such as handing an eligible order to a warehouse. Write down the trigger, required data, destination and evidence that the handoff is complete. Identify the owner of each relevant state: payment status, stock availability, warehouse acceptance and customer communication may belong to different systems.
Define what happens when those states disagree. An order marked cancelled in the store may already have entered warehouse processing. The workflow needs an agreed decision or escalation, rather than assuming that overwriting a field reverses the physical work.
For inventory allocation and concurrent purchases, use a separate design review. Our guide to ecommerce overselling examines that problem; the focus here is recovery when information moves between systems.
Decide whether existing automation is enough
Review the platform's available workflow features and connected applications first. Shopify Flow supports triggers, conditions and actions, including actions involving external services. An existing workflow may cover the requirement without a custom application. Shopify Flow reference
Assess the actual features available to your store and connected services. Can an operator see the failed record? Can the workflow represent the decision you need? Does it provide a suitable recovery path? Who owns changes when a business rule evolves?
Custom integration may be justified by a gap in those requirements. Document the gap before choosing an approach. Avoid assuming that every cross-system process requires custom code, or that an installed connector covers every exception.
Separate failures that can be retried from decisions
A temporary outage may justify another attempt. A missing warehouse product code needs corrected data. An ambiguous customer match may require a reviewer. Treating all three as the same failure produces either repeated errors or unnecessary manual work.
For each exception, specify a category, the next action and an owner. Set a bounded retry policy with increasing delay where appropriate, taking the destination's documented limits into account. After retries are exhausted, keep the item visible and explain why it stopped.
Some failures are uncertain: a request times out, but the destination may have accepted it. Before sending it again, determine whether the first operation completed or use the destination's supported idempotency mechanism. A timeout alone does not prove that nothing happened.
Make repeats safe at the business-operation level
Deduplication recognises work already seen. Idempotent processing ensures a repeated attempt does not create an unintended additional effect. Both matter when one received event can trigger several downstream actions.
Shopify's webhook reference describes delivery and event identifiers that help distinguish deliveries and related events. Match your handling to the current documentation and the action being processed. Shopify webhook reference
A useful acceptance test repeats the same input and checks the destination. Did it create another fulfilment request, another stock adjustment or another customer notification? Then test an interrupted operation where only some steps completed. The workflow needs enough durable state to recover without blindly repeating every step.
Use identifiers appropriate to the business operation and destination. An inbound-event identifier by itself does not establish that every outbound side effect is protected against duplication.
Expect delayed and missing updates
Do not assume events will always arrive in the order business actions occurred. Shopify documents that webhook ordering is not guaranteed. It also recommends reconciliation because deliveries can be missed or mishandled. Shopify webhook behavior
Define how the workflow determines the current state of a record. Depending on the integration, that may require checking source data before applying a change. Avoid a generic rule that every arriving message can overwrite the destination.
Reconciliation compares relevant records between systems and identifies differences. Decide its scope, frequency and ownership around business risk and API constraints. A difference should lead to a supported correction or a visible exception. It should not silently trigger a destructive overwrite.
Give operations a useful exception queue
An exception queue can be a feature in an existing tool or a scoped part of an integration. Its purpose is to make unfinished work understandable and actionable.
For each item, show the affected order or record, the failed step, the reason, the last attempt and the available next action. Include the destination's reference when it exists. An operator should be able to distinguish “never sent” from “sent, outcome uncertain” and “accepted downstream, local update failed.”
Define who can correct data, retry a step, skip it or escalate it. Record those actions so another person can understand the history. Customer refunds, cancellations and other consequential decisions should follow the business's approval process; they should not become an accidental side effect of a generic retry button.
Monitor unfinished work as well as errors
A system can produce few error messages while leaving orders waiting indefinitely. Track the age of unresolved work, repeated failures, reconciliation differences and the stage at which records accumulate.
Give each alert an owner and a useful response. An alert that says “integration failed” is less actionable than one identifying the affected workflow, its current impact and where to inspect the waiting records. Avoid placing unnecessary customer details or credentials in logs and notifications.
Monitoring requirements should also include the monitor itself: who notices if scheduled reconciliation stops or the exception queue is no longer receiving updates?
Test the recovery path before release
Build an acceptance list from the workflow's actual risks:
- Repeat an input and verify there is no unintended second business action.
- Make required reference data unavailable and confirm the item is held with a clear reason.
- Interrupt the connection and check the retry behavior.
- Simulate an uncertain result and demonstrate how completion is established before retrying.
- Deliver an older update after a newer one and verify the agreed state rules.
- Introduce a record difference and demonstrate reconciliation.
- Complete an authorised manual correction and verify the recovery history.
Run these checks in a suitable test environment. Preserve the results and unresolved limitations alongside the handover instructions.
Agree what successful operation looks like
Before launch, decide who owns the queue, what needs escalation and how business-rule changes are approved. Define maintenance separately from implementation so neither party assumes someone else is watching.
Start with a workflow small enough to explain and recover. If your team cannot describe what happens to one failed order, adding more automated steps will make that uncertainty harder to manage.
For help mapping the workflow and its recovery requirements, explore ecommerce automation services or discuss your workflow.