Expression variables

What they are

An expression variable is a {{dot.path}} token. At run time the workflow engine replaces each token with a value from a resolution context (objects keyed by namespace, such as input, trigger_inputs, global, const, or env). Literals and multiple tags can be mixed in the same field; the result is usually a string that the runner may coerce (for example to a number) when a field has a type.

In the editor, fields that support tags offer autocomplete when you type {{. The same syntax appears in gate rules, HTTP templates, JavaScript source (resolved before the script runs), and output rows.

When they resolve

Resolution happens in two phases. The table below summarises what each phase can see.

What {{input.*}} means

For trigger steps, input is the workflow invoke payload (the same object as trigger_inputs). For every other step, input is the immediate predecessor's emitted output. You do not configure per-step input mapping; the edge into the step defines where the data comes from.

{{trigger_inputs.*}} always refers to the original invoke payload on every hop, which is useful deep in a branch.

{{prev.*}} is a legacy alias of input for older graphs; new copy should prefer input.

What {{env.*}} means

The env namespace holds account environment variables you define once in Settings → Environment variables. They are shared across every workflow you own and resolve in the base context on each hop (the same phase as {{const.*}} and {{global.*}}), not after the step finishes.

Tokens look like {{env.api_key}}. Keys are lowercase with letters, numbers, hyphens, and underscores. In the editor, autocomplete lists them as Env · your_key. Validate workflow flags unknown env keys if you typo a name or delete a variable in Settings.

env is not the same as workflow globals ({{global.tenant_id}}, built on the graph during a run) or workflow constants ({{const.api_base_url}}, per-workflow Settings). Secret values live in Settings and Vault, not on nodes. For how to create variables, storage, and exposure risks, see Environment variables.

Main namespaces (types of value)

Each row is a prefix on the resolution object. Tokens look like {{namespace.key}}.

System expression variables

These tokens are merged into every expression-capable field in the editor (alongside workflow-specific tags such as {{input.*}}, {{global.*}}, {{const.*}}, and {{env.*}} when configured). Values are resolved by the runner at the time the expression is evaluated. See GLOBAL_PROMPT_TAGS in the codebase for the canonical list (the tables below are generated from that source).

Tables below use the same Value / Description layout as the Code learn page (purple monospace tokens).

For how {{now.iso}} and relative now.ago_* / now.in_* tokens behave together, read Date and time expression tokens.

Types and coercion

Tags interpolate to text first. Where a row has a type (number, boolean, JSON, and so on), the runner coerces the resolved string. Keep formats predictable: for example ISO dates for date fields, plain digits for integers, and valid JSON inside a tag when a JSON field is expected.

Related

• Environment variables
• Date and time expression tokens
• Steps and behaviour hub
• Execution settings
• Code