Failure with an owner
What is automation exception handling?
Automation exception handling is what keeps a failed workflow from becoming a missed customer, duplicate action, corrupted record, or forgotten promise. The failure must become visible with its evidence, current state, and a named owner. When the automation cannot safely finish, the responsible owner or employee has to review the problem, correct it, and complete the email, text, post, callback, booking, or record update manually when needed.
Exception types
Classify the condition before acting
Different failures require different dispositions.
Invalid or incomplete business input
A missing identifier, unsupported status, invalid product code, conflicting customer instruction, or failed eligibility rule will not become valid because the same action runs again. Preserve the record and route it for correction, clarification, rejection, or policy review.
Distinguish malformed data from a valid business value the current automation did not anticipate. The second case may reveal a rule gap rather than user error.
Transient technical failure
A temporary network interruption, throttling response, short service outage, or resource contention may succeed later. Retry only when the returned condition and operation support that conclusion.
Authentication failure, forbidden access, missing resources, and most invalid requests usually require correction rather than repeated traffic.
Timeout or uncertain result
A timeout proves that the caller stopped waiting; it does not prove that the receiving system did nothing. Before retrying, query by an idempotency key, receipt identifier, or authoritative record to determine whether the side effect occurred.
When certainty is impossible and repetition could charge, message, book, delete, or update twice, stop and route the case to an approved review path.
Business rejection or changed state
An approval can be denied, inventory can be exhausted, a customer can cancel, or another actor can change the record before the workflow writes. These are operating outcomes, not necessarily technical errors.
The process needs a branch that preserves the decision and informs the affected roles rather than disguising it as a generic failed connector.
Disposition
Choose one permitted recovery
Recovery policy belongs to the business process owner, not to a catch-all error block.
Retry
Use a finite count, appropriate delay or backoff, timeout, and total retry budget for a condition likely to clear. Respect service-provided retry guidance and avoid cascading retries across several layers.
The operation must be safe to repeat or protected with idempotency. After the limit, change the state and alert the recovery owner rather than resetting the count forever.
Correct and resume
A person or approved system can supply missing data, repair a mapping, restore permission, or select the permitted branch. Resume from a known checkpoint after revalidating current state.
Do not require an operator to rerun the entire process when earlier effects are already complete and independently verifiable.
Compensate
A compensating action applies business-specific work that offsets a completed side effect, such as canceling a reservation or issuing an approved reversal. It does not always restore the exact prior state and can itself fail.
Microsoft's architecture guidance emphasizes that compensation depends on domain rules, concurrent changes, progress tracking, and idempotent recovery. Irreversible or consequential effects may require human authority.
Cancel, escalate, or accept a partial state
Some work should stop without undoing valid completed steps. Other cases need escalation because the policy, financial consequence, customer commitment, or safety risk exceeds the automation's authority.
Define the valid terminal state, notifications, remaining obligations, and evidence. Partial completion must be explicit rather than a green status on the last step that happened to run.
Evidence
Preserve enough state to recover safely
An alert saying “flow failed” is not a recoverable case.
Record process and business identifiers
Capture the run identifier, business-record identifiers, step, input reference, prior state or version, attempted effect, response or error class, retry count, timestamps, rule version, and current disposition needed to diagnose and reconcile the case.
Keep secrets and unnecessary personal payloads out of logs and broad notifications. Authorized operators can retrieve protected details through the controlled system when needed.
Know which effects completed
Record acknowledgments and receipt identifiers from external systems. Reconcile against the authoritative state rather than treating a client response alone as proof.
For multi-step work, preserve checkpoints and compensation status so recovery can resume without repeating already completed actions.
Human recovery
A queue is useful only when someone works it
Dead-letter storage preserves failed work; it does not resolve it.
Define the recovery workspace
Give authorized operators one view of new, assigned, aging, corrected, retried, compensated, canceled, and closed exceptions. Show the affected customer or record, prior effects, evidence, and permitted actions without forcing the operator to reconstruct the failure across unrelated logs.
Assign an owner, backup, response expectation, escalation threshold, and pause authority. The operator must be able to correct the data, safely retry, or finish the promised work manually and record the outcome. An alert sent to an unmonitored mailbox is not recovery.
Control redrive and replay
A dead-letter queue can isolate messages that exhausted processing attempts, but retention and redrive must be configured. Before replay, confirm the defect is fixed, destination state is safe, duplicate controls still work, and the replay rate will not recreate the outage.
Preserve the relationship between the original failure and the replayed result. Do not delete the only diagnostic evidence merely because the second attempt succeeded.
Verification
Test recovery, not only failure detection
An exception branch is incomplete until the held work reaches a valid state.
Force representative failures
Test invalid input, duplicate delivery, authentication expiry, forbidden access, throttling, timeouts before and after a side effect, unavailable dependencies, stale versions, rejected approvals, compensation failure, full queues, expired retention, and unresponsive owners.
Verify additional effects stop where required, evidence is preserved, the correct owner is notified, permitted actions work, and replay cannot duplicate completed work.
Define recovery evidence
A case is recovered when the authoritative systems and human commitments reach an approved terminal state, the disposition is recorded, necessary notifications occur, and no duplicate or missing effect remains.
Measure exceptions by class, age, recurrence, manual time, recovery time, retry volume, duplicate suppression, compensation success, reopened cases, and unresolved business impact. A falling exception count is not automatically good if detection stopped working.
Common questions
What business owners usually want to know.
Should every automation error be retried?
No. Retry only a condition likely to clear and only when repetition is safe. Invalid input, denied permission, business rejection, and uncertain prior effects usually need correction, reconciliation, or human review.
What is a dead-letter queue?
It is a queue or holding area for messages that could not be processed under the normal retry policy. It preserves failed work for diagnosis or controlled redrive, but it still needs retention, monitoring, ownership, and replay rules.
Is compensation the same as a database rollback?
No. Compensation performs business-specific actions that offset completed effects across a longer process. It may not restore the exact original state, can face concurrent changes, and can itself fail.
When has an exception been recovered?
When authoritative records and human commitments reach an approved terminal state, the disposition and evidence are recorded, required notifications occur, and no known duplicate or missing effect remains.
Research
Sources and further reading
Reviewed 2026-08-24. Use these references to check the details and continue your own research.
Need help applying this to your business?
Tell us where the process breaks down today. We will ask the questions needed to find the cause and decide what is worth fixing first.