Skip to main content

Declare inputs and move data between steps

A Flow's data model is explicit: a run starts with declared inputs, each step's output is recorded, and later steps reference both through templates.

Declare run inputs​

Select the Trigger node to open Trigger. Under Inputs this flow needs to start, add the fields a person or trigger must supply - each with a type (string, number, boolean, object, array), a required flag, and a description. Those fields appear on the run form, on the API fire surface, and to every step.

{
"order_number": "#48219",
"payment_intent_id": "pi_3RyLm4LkdIwHu7ix8n7o6p5q",
"amount": 342.5,
"reason": "Ridgeline 2P tent arrived with a cracked pole"
}

Reference data with templates​

Templated fields interpolate two namespaces:

  • {{inputs.<field>}} - the run's declared inputs, e.g. {{inputs.amount}}.
  • {{steps.<stepId>.output.<path>}} - an earlier step's recorded output, e.g. {{steps.issue_refund.output.refundId}}.

Only inputs.* and steps.* resolve; the validation panel flags anything else before you can publish. References work in tool parameters, branch conditions, approval messages, AI-task prompts, and wait-until timestamps.

The step editor's path picker offers exactly the outputs that are ancestors of the step you are editing - including parallel branches after their join.

Route failures explicitly​

Steps that call the outside world can fail. For each such step, decide:

  • Nothing - the run stops, marked failed, with the error recorded on the step. Right for failures that need a human.
  • Failure outlet - connect the red outlet to a cleanup or notification path. The error is still recorded; the run continues where you routed it.
  • Retry - for transient errors, before the failure edge fires.

An approval's rejection route is the same idea: reject with no route fails the run with the rejection recorded.

What each run records​

Every run stores its input, each step's input and output, every tool call's request and response, and the error that stopped it - inspect them on the session's Run view. Windows are disclosed, not silent: a list that shows the latest N of M says so.

Tips​

If validation says a reference is not resolvable, the step it names is not an ancestor - or the namespace is wrong ({{input.x}} instead of {{inputs.x}}). If a run starts refusing input, compare the caller's JSON against the declared types and required flags. See Troubleshooting.