Exception handling

What is exception handling?

Exception handling is how a system or process detects, classifies, and responds to things that go wrong. The route it takes can be to retry, to compensate, to stop, to fall back to an alternative, or to hand the work to a person.

An exception is not always a software bug. An unreachable API is a technical problem. An invoice with no purchase order number can be a valid business situation that needs someone to look at it. Good exception handling keeps errors from disappearing quietly and stops a process from reporting success after it only half finished.

Business exceptions versus system errors

Technical errors come from infrastructure, code, or communication: timeouts, authentication failures, unavailable services, unexpected data formats. Some are temporary and safe to retry once the underlying service recovers.

Business exceptions happen when the input does not meet the rules of the process: a missing document, a disputed amount, a customer without a valid contract. Running the same step again does not change the content, so a retry is the wrong answer. This split is common across automation tools. UiPath retries an application exception when auto-retry is on, but by default does not retry a business exception. Power Automate work queues carry separate IT and business exception statuses for the same reason.

A rejection is sometimes just a normal outcome. A credit application declined by the rules does not need to show up in monitoring as a system failure. Deciding what counts as an error, and what is simply an answer you did not want, is half the work.

Retry, alternative, compensation, or a person?

Use a retry for temporary faults when repeating the step is safe. Exponential backoff eases the pressure on a service that is still recovering, and idempotence stops a repeated request from creating duplicate transactions.

An alternative path can use a second data source or a different route, as long as the result meets the same requirements. A stale cache is not a safe substitute for every decision. Compensation runs a business counter-action, such as releasing a reservation. It does not undo history and can itself fail, which is why patterns like the saga pattern model each step together with the action that reverses it.

Human handling fits missing context, judgement calls, and cases with no reliable rule. Give the person the cause and the relevant data, not a generic error message.

A worked invoice example

A flow reads an invoice and tries to match it to a purchase order. The ERP API returns a temporary timeout, so the connector retries within a bounded retry policy.

After the service recovers, the purchase order number turns out not to exist. The flow creates an item in an exception work queue with the invoice, the vendor, and the failed check. An employee chooses the right order or sends the invoice back. If a booking already happened but a later step failed, the process checks whether a business compensation is needed, because a clean technical rollback across several systems is not always possible.

Every route keeps the same correlation ID, so the original run, the retries, the human correction, and the resumed step can all be found together.

Exception handling in Power Automate

Cloud flows group actions into scopes and use the Configure run after setting to build a try, catch, and finally pattern. A catch scope can run only when the try scope fails, times out, or is skipped, and a Terminate action makes the final status explicit rather than leaving it ambiguous.

Desktop flows offer error handling per action and per block. A flow can retry, jump to another step, or read the last error. Use continue-on-error only when the later steps can cope with the incomplete state. Record a link or ID to the run so support can open the technical context without guesswork.

Logging, monitoring, and ownership

Log the process ID, the step, the fault category, the timestamp, and the recovery status. Keep passwords and full sensitive payloads out of the log, and give every fault a stable code alongside its readable text so it can be counted and searched.

Monitor the count and age of each exception category. A queue that only grows is delayed process failure, not a quiet day. Assign an owner and a deadline per category, and write recurring recovery steps into a runbook. When the same exception keeps returning, fix the source rather than the symptom.

Test the failure paths on purpose by simulating timeouts, duplicate events, and invalid input. A happy path test proves the process works when nothing goes wrong. It says nothing about whether recovery works.