A failed workflow needs an owner and a next step
Automation exception handling defines what happens when a workflow cannot finish safely. An error message is only the start. A useful exception path preserves the request, identifies who should review it, explains the next action, and records whether recovery actually succeeded.
This guide is about designing that handoff after you have selected a process to automate. For the earlier decision about which work needs human judgment, read what should not be automated in business operations.
1. Separate three kinds of exception
Do not route every problem into the same retry loop. A temporary provider outage, incomplete customer information and a request requiring a judgment call need different actions.
- Temporary technical failure: a request times out or a provider returns a transient error. A limited retry may be appropriate after checking whether the original action already completed.
- Missing or invalid data: a required product reference or customer detail is absent. Retrying the same incomplete request will not repair it.
- Business decision required: the request falls outside the agreed rules, needs an approval or creates a risk the automation is not authorized to decide.
Give each category a named status. Avoid a generic success flag that hides the difference between received, saved, awaiting review and completed.
2. Define the record that survives a failure
Keep a durable reference for the incoming request before performing irreversible downstream actions. The record should identify the current step, relevant external reference, last confirmed outcome, retry count and the person or team responsible for review.
For example, in the WhatsApp to WooCommerce workflow, receiving a message and creating an order are separate events. A missing product detail should lead to clarification rather than an invented order line. The exact fields and retention rules must be agreed for the business.
3. Make retries bounded and duplicate-aware
Set the maximum attempts and the retry interval deliberately. The right limits depend on the provider, urgency and cost of the action. Do not assume that a timeout proves the downstream action failed: the provider may have accepted the order or message before the response was lost.
Use a stable request reference and a documented duplicate-prevention strategy supported by the systems involved. Before a retry, check the last confirmed state where possible. Once the retry limit is reached, stop automatic attempts and move the request into an explicit review queue.
4. Send an actionable notification
A useful alert answers five questions: what failed, which request is affected, what is already confirmed, who owns the next step, and where that person can review the record. Include a short error category and a review link instead of copying private customer data into every notification.
Use a defined notification recipient and a cooldown so a single unresolved incident does not flood the team. The handoff needs an agreed response expectation and an escalation owner; a message sent to an unattended inbox is not a completed operational handoff.
5. Design recovery as a controlled action
The reviewer should be able to correct missing data, reject an invalid request, or resume from a known safe step. Record who took the action and what changed. Do not restart the entire workflow automatically if earlier steps may already have created an order, payment-related record or customer message.
Separate the status of the business request from the status of its notification. A saved enquiry can exist even when its email failed. This separation helps the team recover communication without creating the same enquiry twice.
6. Test the exception paths before release
Test incomplete fields, provider unavailability, a lost response after acceptance, repeated delivery of the same request and exhausted retries. Verify that each case has one understandable outcome and a visible owner. Use test data and an agreed test destination for messages.
At handover, document the statuses, retry limits, alert recipients, recovery steps and monitoring owner. Review that document when the provider or business rules change. A reliable workflow is one the team can understand and recover when the normal path stops.
Explore our business automation services or request a review of a fragile handoff.