Variables
Set workflow-scoped variables
The Variables block sets values that any later block in the same workflow can read. Use it to carry state across steps without threading it through every block in between — a customer id resolved once at the start, a running total, a flag that changes how later branches behave.
Referencing a variable
Variables are read with the <variable.name> prefix, not through the block's own outputs:
<variable.customerId>Variables do not appear as block outputs. <variables1.customerId> will not resolve —
always use the <variable.> prefix.
Shared namespace
Every Variables block in a workflow writes into the same namespace. Setting a name that already exists updates it rather than creating a second one, so a later block can revise a value an earlier one established.
This is what makes accumulator patterns work — set total at the start, update it inside a loop,
read the final value afterwards.
Configuration
| Field | Description |
|---|---|
| Variable Assignments | The variables to set, each a name and a value. Optional; a block with no assignments is a no-op. |
Scope and lifetime
Variables are scoped to a single execution. They persist for the whole of that run and are discarded when it ends — nothing carries over to the next execution. For state that must survive between runs, write it to a datastore instead.
Notes
- Give variables descriptive names in
camelCaseorsnake_case; they are referenced by name throughout the workflow, so a vague name is hard to trace later. - Because the namespace is shared, reusing a name in a different Variables block overwrites the earlier value. That is usually what you want, but it is worth being deliberate about.