# Workflow Exception Handling: How to Route What Automation Can't Finish

> Workflow exception handling for AI automation: the four exception types, when to retry, when to route to a person, and how to design a review queue that works.

- Canonical: https://buffersoltech.com/blog/workflow-exception-handling
- Author: BufferSol Editorial Team
- Published: 2026-10-21 · Updated: 2026-10-21

## Key takeaways
- Every automated workflow needs a plan for the items it cannot finish. Without one, exceptions pile up in an inbox and people stop trusting the automation.
- Sort exceptions into four types: transient technical errors, permanent technical errors, business-rule exceptions and AI uncertainty. Each needs a different route.
- Retry only what retrying can fix, such as timeouts and rate limits, with backoff and a maximum number of attempts.
- Route business exceptions to a person with the reason and evidence already written, so they can act in seconds.
- Review the exception queue every week. It is the best map of what to improve next.

Workflow exception handling is the part of an automated process that decides what happens to items the automation cannot finish. Good exception handling sorts each problem by type. Temporary technical errors are retried automatically. Permanent technical errors alert an engineer. Business-rule exceptions go to a person with the reason explained. Low-confidence AI results go to review. Every exception is logged so the process can improve.

This post explains the four exception types, the routing rule for each, and how to design a review queue people actually use. For the wider design of AI workflows, see our [guide to AI workflow automation](/blog/ai-workflow-automation-guide).

## Why exceptions decide whether automation is trusted

The happy path is the easy part to build. What people remember is what happens when something goes wrong: an invoice that vanished, a customer who never got a reply, a record half updated. If exceptions land in a shared inbox with no context, reviewers spend longer working out the problem than they would have spent doing the task by hand, and the team quietly goes back to the old process.

So treat the exception path as a feature with its own design: who sees what, where, with what information and within what time.

## The four types of exception

```infographic
{"type":"compare","title":"Four exception types and how to route each","columns":["Examples","Route"],"rows":[
{"label":"Transient technical","a":"API timeout, rate limit, temporary outage","b":"Retry automatically with backoff and a maximum number of attempts"},
{"label":"Permanent technical","a":"Invalid credentials, missing permission, broken integration, bad data format","b":"Stop retrying; alert the engineering owner with the error"},
{"label":"Business rule","a":"Price or quantity mismatch, duplicate, missing purchase order, out-of-policy request","b":"Send to the business reviewer with the reason and evidence"},
{"label":"AI uncertainty","a":"Low extraction confidence, unclear classification, conflicting fields","b":"Send to review with the AI's best guess and the source document"}
],"source":"BufferSol exception routing pattern"}
```

### Transient technical errors

These fix themselves if you wait. Workflow engines handle them well. Temporal's documentation on [retry policies](https://docs.temporal.io/encyclopedia/retry-policies) explains that "Temporal's default behavior is to automatically retry an Activity," with exponentially growing delays. AWS Step Functions takes the opposite default: its [error-handling guide](https://docs.aws.amazon.com/step-functions/latest/dg/concepts-error-handling.html) says that when a state reports an error, it "defaults to failing the entire state machine execution" unless you add `Retry` and `Catch` rules. Know your engine's default before you rely on it.

Whichever engine you use, set a maximum number of attempts and increasing delays between them. Step Functions, for example, defaults to three retry attempts with the interval doubling each time. Without a limit, a retry loop can run up costs or hammer a struggling system.

### Permanent technical errors

Some errors will fail the same way every time: invalid credentials, a permission the workflow does not have, a field in the wrong format. Retrying them wastes time. Temporal supports marking these as non-retryable errors, which it describes as "errors that will not be retried, regardless of a Retry Policy." Route them to the engineering owner with the error details, and decide whether the item waits for a fix or goes to a person to finish by hand.

### Business-rule exceptions

These are the most common in practice, and they are not errors at all. The workflow did its job: it found something that needs a decision. An invoice that does not match its purchase order, a request outside policy, a likely duplicate. Route these to the person who owns that decision, with the reason written in plain language.

### AI uncertainty

In AI workflows, a step can return a result it is not sure about: a blurry scan, an email that fits two categories, fields that contradict each other. Send these to review with the AI's best guess and the source side by side, so the reviewer confirms or corrects rather than starting from scratch. OpenAI's [practical guide to building agents](https://cdn.openai.com/business-guides-and-resources/a-practical-guide-to-building-agents.pdf) makes the same point for agents: when failure thresholds are exceeded, such as repeated attempts to understand a request, escalate to a person.

## Designing the exception queue

Our [intelligent invoice processing](/portfolio/intelligent-invoice-processing) workflow shows the pattern. Clean invoices go to approval in Slack and then to the accounting system. Anything that fails a check lands in a review queue with the reason already explained, so the reviewer starts from an answer rather than a blank screen.

A queue that works has these properties:

1. **One reason per item, in plain language.** "Invoice quantity 120, receipt shows 100" rather than "validation failed".
2. **Evidence side by side.** The document and the record it was checked against.
3. **A recommendation.** What the workflow would do if the reviewer agrees.
4. **Clear actions.** Fix and resubmit, approve anyway, reject, or reassign.
5. **Grouping by reason.** Reviewers clear ten duplicates faster together than mixed in with other cases.
6. **Time targets and reminders.** Items should not sit unseen; escalate if they age.
7. **Resubmission into the flow.** After a fix, the item re-enters the workflow at the right step, not at the start.

In our [AI customer support agent](/portfolio/ai-customer-support-agent), the same idea applies to conversations: unusual cases and refunds above a threshold go to a person with a summary and a suggested reply.

## Idempotency: making retries safe

Retries are only safe if repeating a step cannot cause harm. If a workflow posts an invoice, times out waiting for the reply, and then retries, the invoice might be posted twice. The step has to be idempotent: running it again with the same input has the same effect as running it once.

Common ways to get there:

- Send a unique key with each write, such as the invoice number plus supplier, and have the target system reject duplicates.
- Check whether the record already exists before creating it.
- Record each completed step in the workflow's own state, so a resumed run skips work that is already done.

Durable workflow engines help with the last point, because they record which steps have completed. They cannot make an external API idempotent for you, though. That still needs a design decision for every step that writes to another system.

## Who owns each type of exception

Routing only works if every route ends with a named owner. A simple ownership table avoids the "everyone thought someone else had it" problem:

| Exception type | Owner | Response target to agree |
| --- | --- | --- |
| Transient technical | The workflow itself, then on-call engineer if retries run out | Automatic, then same working day |
| Permanent technical | Engineering owner of the integration | Same working day |
| Business rule | Process owner or the team that owns the decision | Agreed per process, for example within one working day |
| AI uncertainty | Trained reviewer in the business team | Agreed per process |

Write the table down before launch and review it when people change roles.

## Logging and learning from exceptions

Log every exception with its type, reason, the reviewer's decision and the time it took. Then review the queue weekly with the process owner. Three questions are enough:

- Which reasons are most common, and can a rule, a lookup or a better prompt resolve any of them automatically?
- Which reasons were the workflow's mistakes, and should they become evaluation cases?
- Are any exceptions waiting too long, and does the routing or staffing need to change?

Over time, the exception rate is one of the clearest measures of how well the automation fits the process.

## Common mistakes

- Retrying everything, including errors that can never succeed.
- No maximum retry count, so a failing step loops quietly in the background.
- Sending all exceptions to one shared inbox with no reason attached.
- Making reviewers restart an item from the beginning after a fix.
- Treating the exception rate as a failure metric to hide, rather than as the map of what to improve.

## Getting started

List the ways your current process goes wrong, sort them into the four types and write the route for each before you automate anything. Our [autonomous workflows](/services/autonomous-workflows) team can help you design those routes, or you can [talk to an engineer](/contact) about your process.

## Frequently asked questions
### What is an exception in workflow automation?
An exception is any item the workflow cannot complete on its own path. It can be technical, such as an API timing out, or business-related, such as an invoice that does not match its purchase order. In AI workflows it also includes cases where the AI step is not confident enough in its result. Each kind needs its own handling.

### Should failed steps be retried automatically?
Only when retrying can help. Timeouts, rate limits and temporary outages often succeed on a later attempt, so retry them with increasing delays and a maximum number of attempts. Errors such as invalid data, missing permissions or a rejected payment will fail the same way every time, so they should be routed to a person or an engineer straight away.

### What should an exception queue show the reviewer?
The item itself, the reason it was stopped in plain language, the evidence behind that reason (for example the invoice line and the purchase order line side by side), what the workflow recommends, and the actions available: fix and resubmit, approve anyway, reject or reassign. Group items by reason so a reviewer can work through similar cases together.

## Sources
1. [What is a Temporal Retry Policy?](https://docs.temporal.io/encyclopedia/retry-policies), Temporal Technologies
2. [Handling errors in Step Functions workflows](https://docs.aws.amazon.com/step-functions/latest/dg/concepts-error-handling.html), Amazon Web Services
3. [A practical guide to building agents](https://cdn.openai.com/business-guides-and-resources/a-practical-guide-to-building-agents.pdf), OpenAI