Node Execution Settings

Every node shares one set of execution settings — timeout, failure behavior, retries — separate from the node's own configuration. They live in the same place on every node, so the pattern you learn once applies everywhere.

Open the settings

  1. Select a node on the canvas to open its settings sidebar.
  2. Click the gear button (Execution & runtime) in the sidebar header.

The drawer lists the node's runtime sections flat: any injected capability sections first (Services, Storage, Runtime — which sections appear depends on the node), then the shared Error Handling, Execution, and Retry sections present on every node. The back button returns to the node's configuration.

Execution paths and warnings

A source outside the selected trigger's execution plan does not run. For a batch-data source such as a disconnected document read, connect each intended trigger to it with an ordering wire, such as task._done -> role._trigger. Keep its data wire into the consumer as well.

Streaming producers and consumers share an atomic execution unit. A streaming producer with no incoming edge can still run when the trigger reaches its consumer in the same stream cluster; it needs no extra ordering wire just to enter the plan.

After save, amber badges on the source and consumer name each trigger that cannot schedule the source and the contributor the consumer will lack. These warnings allow save and publish. Existing releases also report them on the consumer's step before it starts. With fan-in, another source may still supply values. An unscheduled source is different from a source that ran on a branch and was skipped; skipped inputs follow the usual branch rules.

Error handling

On Failure

What happens when the node fails (after its last retry attempt, if retries are enabled):

  • Stop — halt the whole run. The run fails with this node's error.
  • Continue — record the failure and keep going. Nodes that consume this node's outputs are skipped (there is no data to give them), independent branches keep running, and the run can complete with partial errors — the run header lists which nodes failed (see Debugging Runs).
  • Continue (pass error output) — record the failure and emit the structured error on the node's reserved _error output port. Wire _error to a recovery branch — a notification, a fallback call. The error branch only activates on failure; when the node succeeds, it is skipped.

Recovery expressions can read nested error details during the same run, so a captured provider session or status can be carried into the next step when the failing node supplies it.

Defaults vary by node type. Nodes that do real work, and control-flow nodes, default to Stop. Triggers and Note default to Continue, as do a few inherently optional nodes such as Run command, Claude Code, Codex, and Search the web.

Run even if upstream failed

Off by default. When an upstream node fails, downstream nodes are normally skipped. Turn this on for a node that must run regardless — cleanup or notification steps at the end of a branch.

Execution

Timeout (ms)

The wall-clock limit for one node execution, in milliseconds. Minimum 100 ms, up to 60 minutes; a node timeout cannot exceed the workflow's run timeout.

Each node type carries its own default budget — for example HTTP request defaults to 60 seconds and Shell to 30 minutes — so an unset timeout gives the node its natural budget rather than a flat global default.

Two workflow-level settings interact with it (in the workflow's settings, under runtime defaults):

  • Step timeout (ms) — applies to steps that don't set their own timeout.
  • Run timeout (minutes) — caps the whole run: default 30 minutes, maximum 180.

Workflow environment

The workflow's Environment settings are shared plain constants: a flat map of non-empty names to string, number, or boolean values. Read one from any text template as {{env.API_HOST}}, from If/Switch/Map expressions as env.threshold, and from a Code script as env.API_HOST.

The run freezes these values and their secret_env_keys classification when it starts, so every node sees the same environment even if the Draft changes later. Do not put credentials here: workflow environment values are ordinary settings, while tenant secrets stay in their separate governed secret fields and are never resolved into env.

Iteration settings

A node runs once with whatever it receives, a list included. Nodes that can also run once per item of a list show these fields:

  • For each item — Whole list (the default) runs the node once with the list. Each item runs it once per element of the first list it receives, and every output becomes a list with one value per item.
  • Max Iterations — cap how many items Each item processes. Without a cap a node stops at 100 and fails rather than drop the rest.
  • Items at once — run up to 10 items at the same time; results keep the items' order.
  • Delay between items (ms) — wait between items, up to 60 seconds.
  • On item failure — Fail batch, Skip item or Collect errors.

A list wired into an input that takes one value needs Each item: the node shows a problem until you set it, and Publish refuses the workflow. Until 2026-10-09 these nodes ran once per item by default; workflows saved before then were set to Each item where they relied on it (see the changelog).

Use as Return

Marks this node as a return point when the workflow is called from another workflow's Subflow node. The Subflow call returns the marked node's outputs; with no marked node it returns the outputs of the workflow's final nodes.

Retry

Off by default. When Retry on Failure is on:

  • Max Retry Attempts — 1 to 10, default 3.
  • Retry Delay (ms) — base delay between attempts, 100 to 60,000, default 1,000.
  • Backoff Strategy — Linear (delay grows by the base each attempt) or Exponential (delay doubles each attempt; the default). Delays get random jitter so parallel branches don't retry in lockstep.

Only transient failures are retried: timeouts, network errors, and 5xx responses. Permanent errors — validation failures and most 4xx responses — fail immediately without burning attempts. Retries happen inside the same step; On Failure applies only after the last attempt fails.

Declared inputs and outputs

Nodes that take or produce data (HTTP request, Run JavaScript, AI agent, Transform list, Run shell script, Run command and others) have an Inputs and outputs section in their settings. Each declared output becomes a typed port downstream nodes wire against; each declared input is a contract a wired value must meet before the node runs. The same editor appears in Tool setup.

Each list works the same way:

  • Add a row and give it a name and a type. The type list includes registered shapes and the shapes your workspace saved; picking a saved shape copies its schema into the entry.
  • Open a row's details for its label, description, default value, Allowed values (for text, number and true/false types), the Required toggle and its JSON Schema. An output also has Source, Path and Parse: which of the node's outputs to read, where inside it, and how to parse text first (JSON, NDJSON, CSV or XML).
  • Pin last run uses the structure the last run produced (for an input, what arrived on it) as the schema; Save as shape keeps a schema for reuse.
  • Import turns a JSON Schema's top-level properties into rows, and Export gives the list back as one JSON Schema to copy.
  • Test checks a pasted sample against every row, exactly as a run would, without running the node.
  • On mismatch sets what happens when a value does not fit: Ignore, Warn (record a warning and continue) or Fail node. It shows the policy each row actually runs at; a row without its own choice fails the node on a shaped type and warns otherwise.

A row with an error, such as a name with a space or a default that does not fit the type, shows the error and is not saved until you fix it.

Response fields

On AI nodes the Response fields list declares what the model must produce. Each field's description steers generation and its required toggle shapes the response contract. The reply is parsed against these fields and each becomes its own output port. See AI agent for details.

Inspect and test the exact source

The run controls in the node header act on the source shown in the editor: the selected release, the selected branch, or the Draft. Historical run snapshots cannot be inspected or tested from here.

The Test button in the workflow header is a different thing: it runs the whole workflow and only the Draft can do that, so it stays disabled on a release. The per-node and subgraph tests below work on a displayed release as they do on a Draft, and the workflow picker can cut a branch from that release when you want an editable copy.

  • Test selected node (the play button) prepares a preview of the node on the displayed source: the exact source and revision, the projected scope, where the inputs come from (your personal pin, custom inputs, or the last step run of that node), which accounts are still missing, and which nodes have side effects. Nothing runs until you press Start test. The dialog shows the run once it is admitted and the editor stays on the same source. Write access on the workflow is required.
  • Test reachable subgraph does the same for the node and everything reachable from it. Very large scopes are refused before anything starts.
  • Choose Inputs lets you provide custom inputs; Preview test with these inputs opens the same preview dialog with them.
  • Inspect source opens the node exactly as it is stored in the displayed source, with a comparison against the Current release and the main Draft. Long fields load in ranges on demand; the dialog states what is loaded, what is still unloaded, and whether the node is missing from that source. Secret fields, secret references, credential sidecars and workflow or service environment values are hidden; text typed into other fields is shown as stored. Read access is enough to inspect.

If the editor connection was lost around the moment you pressed Start test, this browser keeps a reminder of that attempt (for your account and this workflow only, up to 8 of them) and the dialog lists it as unresolved the next time you prepare a test. The reminder does not say whether the test ran: check the Runs history rather than starting it again. When the browser cannot store reminders, the dialog tells you. Tests never enable a paused workflow and never change the Draft, the Current release, or the history.

Environment redaction

New workflow env keys are plain settings and remain readable in outputs, Task notes and inspection. Select Secret on an Environment row (or set secret_env_keys through workflow upsert) to redact its value. The existing eight-byte minimum applies. If a release comparison marks a key secret on either side, both values are hidden.

Classification freezes with releases, runs and chat previews. Existing stored env keys were conservatively marked secret to preserve unknown credentials. Unmark verified ordinary settings in the Draft and publish; existing runs and redacted history keep their original protection. Marking controls redaction, not encryption: use the tenant-secret store for credentials.