An On error connection follows a step's failure after its retries finish. Use its branch to send a notification, record a failure, clean up resources, or recover and continue the workflow. Error branches live on the same canvas as the ordinary success path.
Add an error path
Select the step whose failure you want to handle and open If this step fails. Add a recovery step or connect to an existing step. Extend that branch with ordinary connections, or reconnect it to a step already on the main path.
For example, Fetch can connect normally to Process and through On error to Use cached data. Connect Use cached data to Process as well. Process then runs once: after Fetch succeeds, or after the recovery branch succeeds when Fetch fails. The recovery branch stays skipped when Fetch succeeds.
You can connect the same source to a target with both a normal connection and an On error connection when that target should handle either outcome. Cycles remain disallowed.
Share recovery logic
Several sources can point to the same recovery step. The shared step waits for its incoming dependencies to resolve and runs once per workflow run when a failure activates its error path. If several sources fail, it receives all of those failures; it does not run separately for each one.
A skipped branch does not count as a failure and does not activate an On error connection. Recovery steps can have their own error paths, and separate error branches can merge or reconnect to the main flow.
Choose what happens after an error step
Choose one of two outcomes after the recovery step:
| Outcome | Behavior after the step succeeds |
|---|---|
| Follow connections | Continue along the step's outgoing connections. This is the default. |
| Fail workflow | Finish this step, then fail the run before its successors execute. |
The failure outcome applies when the step handles an active error. Reaching the same step through an ordinary success path does not fail the run. Choose Fail workflow for an action such as notifying or cleaning up when the run must remain failed.
If an error branch finishes successfully and no unhandled error remains, the run can complete. A recovery step that fails needs its own On error path; otherwise the workflow fails.
Read the failure context
Templates and formulas on error paths can use:
| Field | Value |
|---|---|
error.step_id |
A failed source step's ID. |
error.step_identifier |
That source's reference name. |
error.input |
The input being processed by that failed source. |
error.reason |
The failure reason. |
error.failures |
The list of failure contexts when error paths merge. |
For example, a notification can include {{error.step_identifier}} and
{{error.reason}}. Shared recovery logic can iterate over error.failures to
handle every failed source.
After an error path rejoins a normal path, error context is optional: it is present when recovery was needed and absent when the normal path succeeded. Use the upstream step outputs for ordinary data and account for missing error context in expressions at those joins.
Recovery does not undo earlier work
An On error path reacts to failure of its connected source. It does not automatically undo changes made by steps that succeeded earlier. Add explicit cleanup actions to the relevant error path when needed, and choose Fail workflow after the last cleanup step when the run must remain failed.
Next step
Retries explains when a step tries again before its error path runs.