Node Dependencies & Continue on Error

Overview

A workflow is a graph of nodes connected by edges. The edges decide the order things run in: a node only starts once the nodes feeding into it are done. This page explains exactly when a node runs, what blocks it, and how the Continue on error option lets a node tolerate its own failure so the rest of the workflow keeps going instead of stopping.

By default, a workflow is strict: if a node fails or is skipped, the nodes downstream of it do not run. Continue on error is a per-node opt-out from that strictness — when a node with the option enabled fails, its failure is captured as the node's output (a small JSON document) and the workflow carries on.

How Node Dependencies Work

A node runs when all its inputs are ready

Every edge points from an upstream node to a downstream node. A downstream node becomes eligible to run only when every node feeding into it has reached a satisfying state. If a node has several incoming edges (a "merge" / fan-in), it waits for all of them — not just the first.

Which states satisfy a dependency:

Upstream node's state	Does the downstream node run?
Complete	✅ Yes
Completed-failed (a Continue-on-error node that failed)	✅ Yes — carries the error document forward as input
Skipped	❌ No — the skip propagates (see below)
Failed	❌ No — the branch stops here
Running / Pending / Held	⏳ Not yet — the downstream waits

Note — only Complete and Completed-failed let a dependent run. A Skipped or Failed upstream does not satisfy a dependency. This is what makes the default behaviour strict: one failure or skip stops everything downstream of it on that path.

Node statuses

Status	Meaning
Pending	Created, waiting for its dependencies (or its turn)
Running	Currently executing
Complete	Finished successfully (green check)
Failed	Finished with an error (red ✕) — stops its branch
Skipped	Did not run because an upstream was skipped/failed, or it is on an IF branch that wasn't taken
Held	Paused, waiting on a hold or an approval
Completed-failed	A Continue-on-error node that failed: it produced an error document instead of real output and let the workflow continue (shown as a yellow ✕)

How data flows between nodes

Each node writes its result to an output. Downstream nodes read their upstream nodes' outputs as their own inputs. So a node isn't just ordered after its upstreams — it literally consumes their output. (This matters for Continue on error: the failing node still produces an output, just an error document, which downstream nodes then receive.)

Failures stop a branch, not the whole workflow

When a node fails:

• The nodes downstream of it on that branch cannot run (a failed upstream doesn't satisfy them).
• Other parallel branches keep running — a failure on one branch does not cancel independent branches.
• If some branches finished and at least one failed, the overall workflow ends as partial-fail.

Skips and the IF node

The IF node routes execution down its true or false edge based on a condition. The branch that isn't taken is skipped, and that skip propagates: any node whose only upstreams were skipped is itself skipped, so the entire not-taken branch is skipped. A node that sits after both branches (a merge) is skipped if the branch reaching it was skipped — unless Continue on error is used (below).

Continue on Error

What it is

Continue on error is a toggle in a node's Configuration tab (the first row), available on every node type except IF. It is off by default.

When it is on and the node fails (or would be skipped because of an upstream problem), the node does not stop its branch. Instead:

1. The node is finalised with the Completed-failed status (a yellow ✕ — visibly distinct from a green Complete and a red Failed).

2. Its failure is captured as the node's output: a JSON document of the shape

   {
     "node_error": {
       "node_execution_id": "…",
       "status": "completed-failed",
       "error": "…"
     }
   }

   (error may be a plain message or a structured object, depending on what failed.)

3. That document is written exactly where the node's normal output would go and is uploaded like any other output, so you can open it in the Output tab and use the Download button.

4. Downstream nodes continue, receiving the node_error document as their input.

The one rule to remember

Continue on error tolerates a node's own failure — not its upstream's. If a node upstream of yours fails and that upstream does not have Continue on error, your node never runs (it has no input), and your own Continue-on-error setting can't help it. To keep an entire chain alive through a failure, enable Continue on error on each node in the chain.

What to expect downstream

A Continue-on-error node unblocks everything downstream of it — those nodes run, with the node_error document as their input. Two consequences:

• A node that receives an error document should be prepared for it. If a downstream node can't process the error document and isn't itself set to Continue on error, it may fail.
• This is intentional and is what makes merges work: a node that merges two branches runs only when both feeding nodes are satisfied, so enabling Continue on error on whichever branch might fail (or be skipped) lets the merge still run — receiving real output from one side and the node_error document from the other.

Loop nodes: two separate controls

Loop nodes have two distinct settings — don't confuse them:

• Continue on iteration error — the loop's per-iteration policy. If a single iteration fails, this decides whether the loop skips that iteration and continues or stops the whole loop. It is about the items inside the loop.
• Continue on error — the generic node-level toggle described above, governing the loop node as a whole. If the loop itself ends in failure, this lets the workflow continue past the loop with a node_error output.

Use Cases

• Notify-and-continue: a Slack, email, or ticketing node that should never block the pipeline — if the notification fails, the workflow carries on.
• Best-effort enrichment: an integration or lookup that may be unavailable; downstream reports or merges should still run with whatever data is available.
• Optional branches that merge: let a merge node run even when one feeding branch failed or was skipped, by enabling Continue on error on that branch's last node.
• Tolerating an empty/invalid input: a node that may legitimately produce no usable result, where you'd rather record the error and move on than halt the run.

Best Practices

• Enable it on the specific node whose failure you want to tolerate, not as a blanket setting. It only affects that node's own failure.
• For a whole chain, enable it on every node in the chain. One Continue-on-error node continues past itself; the next plain node still runs with the error input and can fail.
• Design downstream nodes to handle the node_error shape if they might receive it (for example, a script that checks for a node_error key), or set them to Continue on error too.
• Use it on merge-feeding nodes when you want a merge to run regardless of one branch's outcome.
• Leave it off for nodes where a failure genuinely should stop the run — the strict default exists for a reason.

Limitations and Known Behaviour

• Off by default. Existing workflows behave exactly as before until you enable it on a node.
• Not available on IF nodes. A failed IF produces no condition result, so neither branch is reachable — there is nothing to "continue" to.
• It tolerates the node's own failure only, never an upstream failure. A node downstream of a failed, non-Continue-on-error node still does not run.
• Downstream nodes run with the error document as input and may fail if they aren't written to handle it (or aren't themselves set to Continue on error). Be aware that enabling it on a node part-way down an otherwise-skipped path will cause the nodes after it to execute rather than stay skipped.
• A merge is only rescued if its failing/skipped side has Continue on error. A Continue-on-error node on a different branch does not rescue a merge that has a plain failed or skipped input.

Updated: 2026-06-22