A practical field guide from Automation Ace.
The short answer
Most automation failures come from a small set of “what if” cases that nobody planned for: missing data, duplicates, manual overrides, partial approvals, and external failures. An exception inventory is a simple log of those scenarios collected during discovery, with how often each happens, its impact, and a decision: automate it, route it to a person, or consciously ignore it. Building it up front is the cheapest reliability work you will ever do.
Part of the automation planning playbook. Run it right after process mapping.
Why exceptions matter so much
The happy path is usually easy to automate. Exceptions are where build time goes, and where silent failures, duplicates, and angry customers come from. They are also why automations work in testing but fail in production; see why automations fail when turned on.
The eight exception categories
| Category | Examples | Typical handling |
|---|---|---|
| Missing data | Required field blank; attachment absent | Collect via form, Human in the Loop Collect Data, or hold and remind |
| Bad or unexpected data | Wrong format, out-of-range values, free text where a code is expected | Validate and normalize; route invalid records to review |
| Duplicates | Same lead twice; webhook retried; two systems create the record | Search before create; idempotency keys |
| Manual overrides | A person edits a record the automation also updates | Lock fields, track source, or let humans win |
| Partial approvals | Approved with changes; one of two approvers says yes | Model approval states explicitly; re-route on change |
| Timing and order | Update arrives before create; customer replies after deadline | Queues, waits, and state checks |
| External failures | API down, rate limited, credentials expired | Retries with backoff, alerts, and reprocessing |
| Policy edge cases | VIP customer, regulated data, unusual amounts | Explicit rules or human review |
How to collect exceptions during discovery
- Ask “what if” at every step of the process map: what if this is blank, late, wrong, duplicated, or rejected?
- Ask about the last bad week: “Tell me about a time this went wrong.” Stories surface real exceptions.
- Look at the data: sample 50–100 recent records for blanks, odd formats, and duplicates.
- Check workaround artifacts: sticky notes, side spreadsheets, and “fix-up” tasks reveal hidden exceptions.
- Ask downstream teams what they have to correct when work reaches them.
The discovery question bank has a section dedicated to exceptions.
The exception inventory log
EXCEPTION INVENTORY LOG
# | Scenario ("What if...") | Category | How often? (per month) | Impact if mishandled (L/M/H) | Current handling | Decision: Automate / Route to human / Ignore | Owner
1 | PO number missing on invoice | Missing data | ~15 | H | Email vendor manually | Route to human (Collect Data step) | AP lead
2 | Same customer submits twice | Duplicates | ~20 | M | Merge by hand weekly | Automate (search before create) | Ops
3 | Approver out of office | Partial approvals | ~3 | M | Wait until back | Automate (escalate after 24h) | Finance mgrAutomate, route to a human, or ignore?
- Automate when the rule is clear and the case is frequent: duplicates, formatting, predictable retries.
- Route to a human when judgment is needed or impact is high: missing critical data, large amounts, VIP accounts. See Human in the Loop and collecting missing data.
- Ignore consciously only when rare and low impact, and write that decision down so it is not a surprise later.
- Never ignore silently. Every unhandled exception should at least trigger an alert. See the error handling playbook.
A useful rule: automate the top exceptions by frequency, route the top exceptions by impact, and alert on everything else.
Design patterns for common exceptions
- Duplicates: search before create, unique keys, and dedupe tables. See fixing duplicate records.
- Overrides: track which system or person last changed a field. See preventing conflicting updates.
- External failures: retries, error paths, and safe reprocessing. See reprocessing without duplicates.
- Long waits: durable waits and reminders. See long-running automations.
Every decision feeds the edge-case section of the requirements doc.
Frequently asked questions
What is an exception inventory in automation?
A log of the 'what if' scenarios found during discovery, such as missing data, duplicates, overrides, and partial approvals, with frequency, impact, current handling, and a decision to automate, route to a person, or ignore.
Why do exceptions break automations?
Automations are built around the happy path. Unplanned cases like blank fields, duplicate events, manual edits, or API failures cause silent errors, duplicates, or stalled processes.
How do I find exceptions before building an automation?
Ask 'what if' at every step of the process map, ask about recent problems, sample real records for blanks and duplicates, look for workaround spreadsheets, and ask downstream teams what they fix.
Which exceptions should be automated and which routed to a human?
Automate frequent cases with clear rules, like duplicates and formatting. Route high-impact or judgment-heavy cases to a person. Consciously ignore only rare, low-impact cases, and alert on anything unhandled.
Disclaimer: Templates and checklists are starting points; adapt them to your process, policies, and tools. Product features, limits, and pricing mentioned here change over time, so confirm current details in each vendor's documentation. This article may include links to apps, products, or services; some links may be affiliate links, which means Automation Ace may earn a commission at no extra cost to you.