Values

A step's configuration can take values from the trigger and from steps that ran before it, with {{…}}: the convention of automation tools such as n8n, Zapier or Make. {{start.data.number}} is the number of the work order that started the run; {{create_invoice.data}} is what the Execute function step with Step ID create_invoice returned.

Syntax

{{start.data}}                   the trigger's input
{{start.data.body.email}}        a field of it
{{find_site.data[0].branch}}     a field of the first row a step read, by its Step ID
{{item}}  {{item.id}}            the current item or batch, inside a loop's body
{{error.code}}  {{error.message}}  {{error.detail}}
                                 the error being handled, after an Error output

A path is names separated by dots, each optionally followed by [n] indexes, counting from 0. It starts with a Step ID, start, item or error. Every step's result is wrapped as { "data": … }, so a step's value is always reached through .data: {{read_orders.data}}, never {{read_orders}}.

These are unrelated to the query language's $USER.* and $INTERVAL.*, which keep their own meaning inside filters.

What each step's data is

Each step's page gives its result. Run › Test shows every step's actual result, which is the quickest way to find the path you need.

Whole values and text

• A value that is exactly one {{…}} keeps its type: a list stays a list, an object an object, a number a number. "records": "{{parse.data}}" passes the whole list.
• A {{…}} inside longer text is written as text: "WO {{start.data.number}} is complete". An object or a list becomes JSON; a missing value or null becomes empty.
• {{…}} is replaced anywhere in the configuration, inside nested objects and lists, in text values only. An object you write in JSON is never read as a reference.

So "{{start.data.quantity}}" is a number, while "Qty: {{start.data.quantity}}" is text.

When a path doesn't exist

A typo must not write NULL into your data, so a path a step's result doesn't have fails the step with WORKFLOW_INVALID_DESIGN, naming what is there:

{{save_pdf.data.id}}: save_pdf.data has no id - it has asset, name, mimeType, size

So does an index past the end of a list, such as {{find_site.data[0]}} when nothing was found: check it with a Condition first. A null along the way resolves to null.

Under start and item, the data comes from outside, where a field left out is ordinary: a missing field there resolves to nothing instead of failing.

A reference to a step that hasn't run is refused too: a step after it, a step on another branch, or an unknown Step ID. Publishing checks this, and lists every such reference.

item and error

• {{item}} exists only inside a loop's body: the current element of a For each item, or the current batch, a list, of a Process in batches.
• {{error}} exists only in the step directly connected to another step's Error output: { code, message, detail }, detail when the error has one, such as Validate data's failed rules.

A step after a loop can read the steps inside the loop's body, which hold the last item's results.

Where {{…}} works

Every step's configuration, except:

All values are resolved before the step runs, so a step's input in Runs shows the values actually used, also when the step then failed.

Step IDs

Each step's Step ID is its name in {{…}}: letters, numbers and underscores, up to 20 characters, unique in the workflow. start, item and error are reserved. Renaming a step's ID doesn't update the references to it: publishing lists the ones left behind.

A path can be at most 1,024 characters.

Next steps

• Editor: setting a Step ID.
• Control: checking a value before using it.