Skip to main content

Common Properties

Every node in a flow document shares the same envelope:
Each node type also declares a fixed set of input and output ports (e.g. in / out). Connections wire an upstream node’s output port to a downstream node’s input port.

Start

The entry point of a flow. It takes no configuration and no inputs — it simply emits the run’s parameters and a trigger timestamp so downstream nodes have a well-defined starting payload.
Output:
Every flow must have exactly one start node as its entry point.

If

Branches the flow based on a condition evaluated against upstream data and flow parameters.
Because if is a branching node, every outgoing connection from it must set from_port to true or false:
A connection leaving a branching node without a valid from_port fails validation. Nodes only reachable through the branch that isn’t chosen at run time are marked SKIPPED instead of executed.
When the upstream input is a dict, its fields are merged into the output alongside branch and value, so downstream nodes on either branch still see the original payload.

For Each

Iterates over a list, re-running a nested body sub-flow once per item.
The body document is validated the exact same way a top-level flow is, including supporting another for_each nested inside it (up to a max depth of 5). It must contain exactly one response node — that node’s output is what gets collected into save_as for each iteration.

LLM Call

Calls a Large Language Model through a configured Model Account, or the organization’s Orion AI default account when omitted.
prompt/system_prompt use Python’s str.format() templating (not Jinja) — see Templating & Expressions for the exact rules and error behavior when a referenced field is missing.

REST Call

Calls an external HTTP/REST endpoint.
Authenticated example:
The response is always returned alongside its status_code:

Action Call

Calls a project Action — a user-defined Python function — with parameters.
Actions are audited the same way as when an agent calls them — every action_call node execution appears in the Action’s call history.

Python

Runs custom Python against upstream data and flow parameters, in an isolated subprocess.
code must define a handler(inputs, parameters) function and be valid Python — both are checked before the flow can run.

SQL

Runs a read-only SQL SELECT against the project’s own datasets, the same way SQL Explorer does, and returns the rows to the flow.
Output:
query uses the same str.format() templating as llm_call/action_call — a field referenced in query but missing from inputs/parameters fails the node with a clear error naming the missing key, rather than sending a malformed query.
Only SELECT (and UNION/INTERSECT/EXCEPT) queries are accepted — multi-statement queries and INTO OUTFILE/INTO DUMPFILE are rejected. The query runs with the permissions of whoever triggered the flow run, against the project’s own datasets — there’s no separate connection or data source to configure. Unlike SQL Explorer, no default row limit is applied to a flow’s sql node, so add your own LIMIT or a large result set can be slow to return.
Every sql node execution is recorded as an auditable query result against the flow run, and counts against the organization’s query quota — a run made while that quota is exceeded fails with Query quota exceeded for this account.

Response

A terminal node that returns the upstream result, unchanged, to the flow’s caller.
A flow may contain at most one top-level response node. Inside a for_each body, exactly one response node is required — it defines that iteration’s result.

Output

A sink node — writes the upstream result to a dataset, webhook, or file.
Setting materialized: true on a kind: dataset output currently fails validation — materialized dataset writes are not supported yet.

Next Steps