By Ontix
Business Automation / 3 min read
Workflow Error Recovery: Retries, Alerts and Clear Owners
How to design business automations that fail safely, with retries, alerts, review queues and clear ownership so no task disappears silently.
Every automation eventually meets a failure: an API times out, a field is missing, a service is down or a rule cannot decide. What matters is what happens next. A workflow that fails silently can look healthy while customers wait, so error recovery deserves design time before launch, not after the first incident.
Why silent failure is the real risk
When an automation breaks loudly, someone fixes it. When it breaks quietly, a lead is never assigned, an invoice is never sent or a record is never updated, and nobody notices until a customer asks. The goal of recovery design is to make every failure visible and every failed item recoverable.
1. Preserve the input first
Before the workflow does anything else, keep the original request. If a later step fails, you can retry from the stored input instead of asking the customer again. Put the raw data in a queue or log before transforming it.
2. Classify the failure
Different failures need different responses.
| Failure type | Example | Typical response |
|---|---|---|
| Temporary | Service timeout, rate limit | Retry automatically with a delay |
| Data problem | Missing required field, bad format | Send to a review queue with the reason |
| Rule gap | No rule matches the request | Assign to a default owner and alert |
| Hard failure | Credentials expired, tool removed | Stop, alert an operator and hold the items |
Treating them all the same either floods people with alerts or hides real problems.
3. Retry sensibly
Retrying is right for temporary problems, but do it with limits. Wait longer between attempts, cap the number of tries and stop when the cap is reached. Endless immediate retries can make an outage worse and may create duplicates if the original action partly succeeded.
4. Make steps safe to repeat
Design actions so that running them twice does not do harm. Check whether a record already exists before creating one. Use a stable identifier for each request. This protects you from duplicate invoices, double bookings and repeated messages when a retry overlaps with a slow success.
5. Alert the right person, not everyone
An alert should say what failed, which item it affected, what the workflow already did and what a person needs to decide. Send it to a named owner with a way to see the item directly. Group repeated identical failures so one outage produces one useful message, not hundreds.
6. Give failed items a home
A review queue is where items go when automation cannot complete them. Each entry should show the original input, the step that failed and the reason. Someone should own the queue and clear it on a schedule. A queue nobody reads is just a slower form of silent failure.
7. Never tell the customer something that is not true
If the workflow could not complete a booking or a payment step, the customer-facing message should not say it did. Acknowledge honestly and set a realistic expectation, then let the recovery process finish the job.
8. Test the failures on purpose
Disconnect a tool in a test environment. Send malformed data. Submit the same request twice. Remove a required field. Watch what each person sees: the customer, the owner and the operator. Fix the gaps before real traffic finds them.
Monitor over time
Track failed runs, retry counts, items waiting in review and the time to resolve them. A rising number of items in one category usually points to a rule that needs rewriting.
If you want workflows with retries, monitoring and alerts designed in from the start, see Ontix business automation.