nesaku
Talk to us Initial conversation
Writing

Business automation 29 August 2026 9 min read

How Business Automations Should Handle Errors and Exceptions

Design business automation error handling with exception classes, safe retries, reconciliation, recovery ownership and clear terminal states.

By Alejandro at Nesaku

Design failure behaviour before the happy path ships: classify the failure, retry only when repetition is safe, preserve enough evidence to reconcile, and assign every unresolved run to a human owner. An automation is not controlled if a failed run can disappear, repeat a business action, or remain “in progress” indefinitely.

This chapter is part of the guide to automating a business process in Dubai. The operating procedure below is a Nesaku recommendation. Standards and platform capabilities are cited as observed facts, while examples are illustrations rather than client results.

Key Takeaways

  • Separate expected business exceptions from transient faults, permanent faults, ambiguous completion, human timeouts, and possible security or privacy events.
  • Give every run an explicit terminal state. “No error received” is not evidence of a successful business outcome.
  • Retry only after proving that another attempt cannot duplicate or corrupt the business effect.
  • Record identifiers, transitions, attempts, and decisions, but avoid copying unnecessary personal data into logs.
  • Move exhausted failures into one owned queue with a deadline, recovery action, and customer-status rule.

Separate business exceptions from technical failures

The first design task is to name what went wrong. A single failed label does not tell an operator whether to correct data, wait for a dependency, contact a customer, investigate a security event, or stop the workflow.

Expected business exception

An expected exception is a valid case that cannot follow the normal path: an approval is declined, a required field is missing, a booking slot is no longer available, or a request falls outside a published rule. The system is functioning. It should route the case to a defined alternate outcome rather than pretend that the event is a technical fault.

Transient and permanent technical failure

A transient failure may succeed later, such as a brief timeout or temporary service unavailability. A permanent failure needs a change before another attempt can work: invalid credentials, a removed field, rejected data, or an unsupported operation.

Google Cloud Workflows and AWS Step Functions both document ways to catch named errors and configure retries or fallback paths. Those are examples of product capabilities, not proof that every platform classifies failures in the same way or that its defaults are suitable for a particular business process (Google Cloud, error types; AWS, error handling, accessed 2026-08-29).

Ambiguous completion

Ambiguity is more dangerous than a clean rejection. The automation sent a request, then lost the connection before learning whether the receiving system created the invoice, booking, payment, or customer record. Retrying immediately may duplicate the action. Mark the run completion unknown, look for the original result using a stable reference, and reconcile before deciding whether to send again.

Human timeout

An approval or correction request can expire without a response. That is neither approval nor technical failure. Define the deadline, reminder, delegate, escalation, and eventual terminal state before launch. The preceding chapter explains how to place human approval in an automated workflow without creating an unowned waiting room.

Privacy or security event

A routine exception is not automatically a cybersecurity incident. Escalate separately when a run suggests unauthorised access, disclosure, malicious input, credential misuse, or another security event. NIST SP 800-61 Rev. 3 describes integrating incident response into cybersecurity risk management; use that process for suspected incidents, not as the queue for ordinary validation failures (NIST, SP 800-61 Rev. 3, published 2025-04).

Define detection and terminal states

Each run needs a correlation identifier that follows it across the trigger, automation platform, connected systems, notifications, and recovery work. Record the last confirmed step and the expected next signal. A timer should detect when that signal does not arrive.

Nesaku recommends a small terminal-state vocabulary:

Terminal stateMeaningRequired evidence
CompletedThe defined business outcome existsOutcome identifier and verification time
Business exceptionA published alternate rule ended the runException code and resulting action
CancelledAn authorised person or rule stopped itActor, reason, and cancellation point
RecoveredA failed run reached a verified outcomeRecovery action, actor, and verification
FailedRecovery ended without the intended outcomeFinal cause, owner, and customer status

Retrying, waiting for approval, and completion unknown are active states, not terminal ones. Every active state needs an expiry and an owner. Otherwise dashboards can look quiet while work remains stuck.

Retry only when the business effect is safe

Use bounded attempts and backoff

Retry only the failures identified as temporary. Limit attempts, space them out, and stop when the error changes or the business deadline passes. Google documents configurable retry predicates, maximum attempts, and backoff for its Workflows product; AWS documents comparable retry fields for Step Functions. These show that bounded retry is implementable, but they do not choose a safe policy for your workflow (Google Cloud, retry syntax; AWS, error handling, accessed 2026-08-29).

Understand idempotency and its limits

RFC 9110 defines an HTTP method as idempotent when multiple identical requests have the same intended effect as one request. It also notes that clients may retry an idempotent request after a communication failure (IETF, RFC 9110 section 9.2.2). That narrow protocol property does not make a multi-step business action safe to replay.

Use a stable business key where the receiving system supports it: for example, source-order-id + action-type. The receiver should return the existing result for the same key rather than create another effect. Still test the whole chain. A customer record update may be repeatable while its attached email, task, stock reservation, or accounting entry is not.

Reconcile before retrying ambiguity

For an unknown completion, query the destination using the correlation or business key. Compare the destination record, source state, and event history. Retry only if the intended effect is confirmed absent. If the destination cannot be queried reliably, automatic retry may be the wrong control; route the run to a person with the evidence needed to decide.

Preserve evidence without over-logging personal data

An operator normally needs timestamps, workflow and rule versions, correlation identifiers, source and destination record identifiers, state transitions, attempt counts, error codes, response categories, and recovery decisions. They rarely need full message bodies, identity documents, access tokens, or every field from a customer record.

Where the UAE federal Personal Data Protection Law applies, Article 5 includes purpose limitation, data minimisation, accuracy, security, and limits on storage. Articles 7, 8, and 20 address controller, processor, and security duties (UAE Legislation, Federal Decree-Law No. 45 of 2021). Its scope and exclusions must be checked; free-zone and sector-specific regimes may change the answer. This is an operational design prompt, not legal advice.

Set access and retention for operational evidence deliberately. Redact secrets at capture, restrict sensitive error payloads, and keep the business audit record separate from short-lived diagnostic detail where practical.

Route exhausted failures to an owned queue

A queue needs more than a list of red rows. Each item should show:

  • the business record and current state;
  • what completed and what remains uncertain;
  • the failure class and last error;
  • attempts already made;
  • customer-visible status and any promise at risk;
  • the named owner and resolution deadline;
  • permitted recovery actions and escalation route.

One team should own the queue, and one person should own each item. The business-systems ownership guide explains how to separate operational, technical, vendor, and change responsibility. If a failure affects a customer promise, define who corrects the external message as well as who repairs the integration.

Escalation thresholds should reflect consequence and age: an ambiguous financial action needs faster attention than a delayed internal summary. These thresholds are local operating decisions, not universal severity labels.

Recover with replay, compensation, or cancellation

Recovery should end in a verified business state:

  • Replay the failed step when the intended effect is known to be absent and repetition is safe.
  • Resume after a person corrects data or gives approval, using the saved state rather than restarting unrelated work.
  • Compensate when an earlier completed action must be counteracted, such as releasing a reservation after a later step fails.
  • Cancel when the business request is no longer valid, preserving the reason and completed side effects.

BPMN 2.0 defines error, timer, escalation, and compensation events as distinct process concepts (OMG, BPMN 2.0.2). A team does not need to draw formal BPMN diagrams, but those distinctions are useful: compensation is a designed business action, not simply deleting a run or reversing a database row.

After recovery, reconcile the source record, destination record, customer communication, and work queue. A technically successful replay is incomplete if the original failure task remains open or the customer received conflicting status.

Test the exception design

For every exception class, force the condition in a controlled environment and verify detection, retry limits, evidence, routing, recovery, and terminal state. Include timeouts, malformed input, expired credentials, rejected writes, unavailable dependencies, duplicate triggers, partial completion, and simultaneous events.

The next chapter provides a complete business-automation test and rollout procedure. After launch, the final chapter explains how to measure exceptions, recovery, and manual intervention without confusing platform success with business success.

Exception-register template

Use one row per designed exception, not one row per occurrence:

FieldDecision to record
Class and signalWhat happened, and how is it detected?
Business stateWhat is the last confirmed effect?
Retry safetyIs repetition safe, under which conditions, and why?
Business keyHow is an existing result found?
Attempt policyWhich errors, maximum attempts, timing, and stop condition?
Owner and deadlineWho receives an exhausted run, and by when?
User statusWhat may be communicated while resolution is pending?
RecoveryReplay, resume, compensate, cancel, or investigate?
EvidenceWhich identifiers, transitions, and decisions are retained?
Terminal stateHow is the final business outcome verified?

If recurring automations currently fail silently or produce duplicate side effects, bring one failed run and the records from each system to an exception-design review. Nesaku’s business automation service in Dubai is the commercial route for defining the controls and implementing the connected workflow; start with the failed run, not a platform shortlist.

Sources