Error Shield

The Error Shield wraps a single node so that errors are caught and routed to a dedicated Error branch, rather than stopping the entire run. This lets you handle failures gracefully — by retrying, notifying someone, or taking a fallback path — without writing defensive code in every step.

How it works

When the node inside the shield runs:

• Success — the run continues down the Success branch.
• Error — the run continues down the Error branch, and the people with access to the workflow are notified. The Error branch output includes an errorCode and errorMessage field you can bind to downstream to handle different failure types.

Retries and backoff happen before the shield decides which branch to take. The shield will keep retrying until the attempt limit is reached, then route to the Error branch if every attempt fails.

What you can shield

Most action nodes are supported: HTTP requests, integrations, database operations, AI prompts, and similar nodes that run, succeed, or fail in a single step.

What you cannot shield

Some nodes pause the run rather than completing it. Paused runs have a third outcome — neither success nor error — that the shield does not implement. Wrapping a pause-capable node would silently swallow the pause, causing unexpected behaviour.

The following node types cannot be placed inside an Error Shield:

Create Task vs. User Approval

Although both Create Task and User Approval involve human work, they behave differently in a workflow:

• Create Task creates a task record and then lets the workflow continue. It does not wait for the task to be completed, so it can be wrapped in an Error Shield.
• User Approval pauses the workflow until a person responds. Because Error Shield handles only Success and Error outcomes—not a paused workflow—User Approval cannot be wrapped.

Use Create Task when the workflow should hand off work and continue immediately. Use User Approval when downstream steps must wait for a person's decision.

Retry and backoff settings

Configure how many times the shield retries before routing to the Error branch:

• Attempts — number of additional tries after the first failure (0 = no retries).
• Delay — how long to wait between each retry.
• Backoff strategy — choose None (constant delay), Linear (delay × attempt), or Exponential (delay × 2ⁿ) to avoid hammering a temporarily unavailable service.

Timeout

Set a maximum time for the entire shield (including all retries). If the timeout is exceeded, the run routes to the Error branch with an errorCode of shield_timeout.

Pass inputs through on error

When enabled, the Error branch output includes the original inputs to the shielded node alongside the error details. This is useful when you want to log or surface what was attempted.