- Introduction
- Getting started
- Build on any canvas
- Build with Case
- Reference
- Defining case keys (system vs. external)
- Establishing task I/O and write-back contracts
- Modeling primary and secondary stages
- Triggering a case from Data Fabric
- Implementing stage-level personas and permissions
- Setting SLAs and automated escalation rules
- Configuring a rework loop (re-entry)
- Configuring and testing the Case Manager Agent (preview)
- Build with Flow
- Build with BPMN
- Operating
- Monitoring
- Optimizing
- Reference information
Handle errors
Route failed nodes to error handlers, return error details, retry transient failures, and terminate unrecoverable errors gracefully.
What you'll build: A workflow that routes a failing node to a separate path, records the failure with useful context, retries transient failures where it makes sense, and terminates cleanly when the error is unrecoverable. After this guide, you have a pattern you can drop into any existing workflow.
What you'll need
- A UiPath Automation Cloud account with access to Flow.
- An existing Flow workflow with at least one node that can fail and exposes an error handle — for example, an HTTP Request or an Extract node.
Nodes used
- HTTP Request — the failure-prone node in this example
- Script — returns the error details
- Terminate — ends the workflow with a
Failedstatus on unrecoverable errors
Steps
1. Connect the node's error handle
By default, a failed node stops the entire process. To handle the failure instead:
-
Open your workflow on the canvas and select the failure-prone node.
-
Open the Error handling tab and turn on Enable error handling. An Error handle appears below the main output handle.
-
Select the + on the Error handle, search for Script, and select it.
This creates an error path. When the node fails, execution routes along this path instead of stopping the process. (Nodes without an Error handling tab don't support error handling — a failure there stops the process and surfaces under the Incidents tab.)
2. Return the error details
In the Script node on the error path, read the error object at $vars.<node>.error and return the details:
const error = $vars.httpRequest1.error;
return {
message: "Error raised: " + error.message,
code: error.code,
status: error.status
};
const error = $vars.httpRequest1.error;
return {
message: "Error raised: " + error.message,
code: error.code,
status: error.status
};
The Script node's output appears in the execution trace, so the error details are visible when you inspect the run. The error object is only populated on the error path. For its full field reference, see Error handling.
3. Retry transient failures (optional)
If the failure is likely transient — a network blip or a rate limit — retry before giving up. The HTTP Request node has built-in retries: configure the retry count in its properties, and it re-attempts the request that many times before triggering the error handle. Only the final failure routes to the error path.
Retry only idempotent operations. Retrying a node with side effects (writing data, sending a message) can create duplicates.
4. Terminate if unrecoverable
On the error path, after the Script node, add a Terminate node. Set:
- Status →
Failed - Message → a description that includes the error, for example
$vars.httpRequest1.error.message
This records the failure in the execution history with a useful description, visible in Observing runs.
5. Test and debug
To trigger the error path intentionally:
- Temporarily set the URL in the HTTP Request node to an invalid value (for example,
https://this-will-fail.example.com). - Run the test and verify the execution trace routes along the error path.
- Restore the correct URL.
In the trace, select the Script node and check its output for the error message.
Result
Your workflow routes failures to the error path, returns the error details, optionally retries transient failures, and terminates cleanly with a descriptive failure status. You can confirm the error path works by using an invalid URL in the HTTP Request node and inspecting the Script node's output in the execution trace.
Extend this workflow
- Send an alert on failure — On the error path, before the Terminate node, add an HTTP Request or integration node to notify a Slack channel or create an incident ticket.
- Continue instead of terminating — If the step is non-critical, have the error path set a fallback value and rejoin the main path instead of terminating.
- Apply this pattern everywhere — For more patterns (return error details and continue, fallback values, escalation), see the Error handling reference.