Exception handling in automation: a practical process

The exception handling process is how an automated workflow detects an error, classifies it, takes a safe action (retry, compensate, or stop), and records what happened so the right person can recover the work. In practice you design for three broad categories: transient failures that often succeed on retry, invalid input you must correct, and business exceptions that require a decision.

Core types you must distinguish

1) Transient failures (often safe to retry)

These include network timeouts, throttling and temporary service faults. A controlled retry with exponential backoff and a maximum attempt limit helps workflows recover without overloading systems, and you should stop or branch if retries exhaust. This pattern is supported in mainstream automation platforms with configurable retry policies and backoff settings (Employ robust error handling, Microsoft Learn). Examples of transient categories you may encounter in run histories include timeouts and throttling quotas (Cloud flow error code reference, Microsoft Learn).

2) Invalid input (do not auto-retry)

Bad or malformed data should not be retried automatically. Typical signals are 400 BadRequest or data-conversion errors, which indicate you must fix the payload or transform it before trying again (Cloud flow error code reference, Microsoft Learn).

3) Business exceptions (need a decision)

These occur when data violates a business rule (for example, two owners claim the same lead, or a contract is missing a required approval). The correct action is to route the item to a review or dead-letter queue with clear context, not to retry blindly.

A practical exception-handling process

1) Detect and classify

Group risky steps into a Try scope and direct failures into a Catch scope that extracts the error, labels it, and chooses a path (Employ robust error handling, Microsoft Learn). Many designers also use run-after rules so specific actions fire only on failure or timeout (Microsoft Learn).

2) Choose a safe action

• Transient failure: apply a capped, exponential retry policy. Increase the interval, stop after the max, and branch to remediation or termination if still failing (Employ robust error handling, Microsoft Learn).
• Invalid input: do not retry. Log the details, notify stakeholders, and terminate the run with a clear status so nothing else executes (Terminate, log and notify, Microsoft Learn) (400 and conversion errors, Microsoft Learn).
• Business exception: send the item to a review queue with a reason code and required fields for a human decision. Track ownership and due date.

3) Make retries safe with idempotency

If you retry, ensure the operation is idempotent: repeating it will not create duplicates or change state incorrectly. Use a stable operation key and the destination system’s supported idempotency mechanism. A timeout does not prove that the first request failed: check the saved operation status before repeating a write. An upsert alone does not make a separate email, payment or task creation safe to repeat.

4) Record and route for recovery

Capture a concise audit record: what failed, classification, correlation/run identifiers, who now owns it, and the next action. Some platforms let you construct a direct link to the failed run to speed diagnosis and handoff (Get flow run URL, Microsoft Learn). Send a focused notification instead of flooding inboxes (Log errors and notifications, Microsoft Learn).

Illustrative audit log entry (valid JSON)

{
  "eventId": "e-9384c8f2",
  "timestamp": "2026-10-28T14:05:17Z",
  "workflowName": "lead-handoff",
  "runUrl": "https://example.com/runs/12345",
  "classification": "transient-timeout",
  "operation": "assignOwner",
  "key": { "leadId": "L-10293", "targetOwnerId": "AE-447" },
  "retryCount": 2,
  "status": "exhausted-retries",
  "routedTo": { "queue": "revops-review", "owner": "revops@example.com" },
  "notes": "HTTP 504 after 3 attempts with exponential backoff"
}

Example: handling exceptions in a lead handoff flow

Scenario: When marketing qualifies a lead, the automation assigns it to the correct account executive in the CRM and creates a follow-up task.

Design for the three categories

• Transient failure (safe to retry): CRM API times out or returns 429 throttling. Configure exponential backoff with a max attempt count; if still failing, branch to review. This mirrors recommended retry patterns and timeout handling in platform guidance (Employ robust error handling, Microsoft Learn) (Timeout and throttling categories, Microsoft Learn).
• Invalid input (stop and correct): The AE email is missing or a field exceeds length limits. Detect before calling the CRM, add a clear error message, notify the RevOps owner, and terminate remaining steps (BadRequest and data conversion guidance, Microsoft Learn).
• Business exception (review): The lead collides with an existing account or violates routing rules. Send to a "RevOps review" queue with the reason code and a link to the run details for quick triage (Get run URL and notify owners, Microsoft Learn). If the process needs an explicit approval, consider using or integrating with an approval step (How to create an approval workflow?).

Safe retries and idempotency for handoff

• Use a stable handoff-event ID, with the lead and intended owner recorded as context. Check the current record version before changing ownership, so replaying an older handoff cannot overwrite a newer decision. Apply the destination’s supported deduplication or idempotency mechanism separately to task creation.
• After max retries, dead-letter to the RevOps review queue and create a single ticket with the same correlation ID.
• Record the run URL and failure details to your error log store and include that link in the ticket (Construct run URL and log, Microsoft Learn).

If lead quality or routing rules are unclear, align this flow with your qualification criteria (What does lead qualification mean?).

Controls that prevent runaway or silent failures

• No unbounded retries: set a maximum retry count and increasing intervals; after exhaustion, branch to remediation or termination (Retry policy and termination, Microsoft Learn).
• No silent discard: never swallow errors. Use run-after branches, send a focused notification, and record an audit trail (Run-after, logging, notifications, Microsoft Learn).
• Explicit stop conditions: add a Terminate action with a Failed status for unrecoverable cases so later actions do not run (Terminate action, Microsoft Learn).

Ownership and recovery

Every exception path should name an owner (team or role), a place to find the item (review/dead-letter queue), and a recovery play (fix data and requeue; manual completion; or rollback). Include service-level targets for acknowledgment and resolution in your runbooks.

FAQ