Bot resilience is the architectural property of an automation that enables it to operate reliably in the unpredictable conditions of a production environment — handling application errors, network timeouts, unexpected UI states, data quality exceptions, and target system unavailability without crashing, without silently skipping work, and without requiring a human to restart it after every exception. A resilient bot encounters a failure, responds to it according to a defined exception handling strategy, logs the failure with sufficient context for investigation, and continues processing the remaining work. A non-resilient bot encounters the same failure and stops — leaving a partially processed queue, no diagnostic information, and a notification to the operations team that the bot has “crashed.”
How It Works
Bot resilience is implemented through a layered exception handling design:
- Activity-level exception handling: Try-catch blocks around individual activities where specific, known failures can occur — a UI element not found, a file not accessible, an API call returning a non-success status. At this level, the bot can take a targeted recovery action: retry the activity, use an alternative path, or mark the item as a specific exception type.
- Transaction-level exception handling: When a complete transaction (a work item, a queue record, an invoice) fails after activity-level recovery is exhausted, the transaction is marked as failed with the failure reason, removed from the processing queue, and the bot proceeds to the next transaction. No transaction failure stops the entire process run.
- Process-level exception handling: System-level failures that affect the entire execution — the target application is unavailable, the orchestrator connection is lost, the bot machine runs out of memory — trigger a process-level handler that sends an alert to the operations team, performs any necessary cleanup, and exits cleanly rather than hanging in an unknown state.
UiPath’s REFramework implements this three-tier model as a built-in architecture template. Equivalent patterns exist in Automation Anywhere and can be implemented in Power Automate through scope actions and error handling configurations.
Design Considerations
The boundary between a retry (a transient failure that may succeed on the next attempt) and a genuine exception (a business data problem or application error that will not resolve with a retry) must be explicitly defined in the exception handling design. Retrying a genuine exception — a vendor code that does not exist in the ERP, an invoice amount that exceeds a credit limit — wastes processing time and delays the notification that would allow a human to resolve the underlying issue. Classifying exceptions at design time — which error codes and conditions are retryable, which are business exceptions requiring human resolution, and which are system exceptions requiring IT investigation — is the design activity that makes retry logic valuable rather than harmful.
What Breaks in Production
The specific resilience failure that produces the most operationally disruptive production incidents is unhandled exception types — error conditions that were not anticipated in the exception handling design and that reach the top-level handler with no specific handling logic. A bot processing supplier invoices encounters a PDF that is password-protected and cannot be opened by the OCR engine. The OCR activity throws an exception type that is not in the exception handling map. The top-level handler catches it as an unclassified system exception, sends a generic error notification to the IT team, and marks the entire batch as failed — not just the problematic PDF. The operations team receives an “automation failed” notification with no information about whether any invoices were processed before the failure, how many remain unprocessed, or what caused the failure. Comprehensive exception type cataloguing, conducted during the design phase against the actual document population and target system error codes, prevents unknown exception types from reaching production.
How Loop Wise Solutions Designs for This
In automation development engagements, we produce an exception catalogue as a design deliverable — listing every exception type anticipated for the process, its classification (business exception, application exception, or system exception), the handling action for each, and the notification content and recipient for each exception category. The exception catalogue is reviewed in design walkthrough before development begins, and extended during testing as new exception types are discovered. An exception that reaches production without being in the catalogue represents a gap in the design — not an unexpected production event.
