Custom Variables

The Custom Variables Step stores named values during a run so later Steps can read them by name.

At a glanceVerified in app · Oct 29, 2026

Use it to: Store calculated values, flags, or lookup objects under names you choose for the current run
Find it: Tools → Data → Transform → Custom Variables
Cost: 1 Step credit per execution
Limits: Scoped to the current run and to the Step that defined them (shortcut t+v)
Output: {{ N.<variable_name> }} (direct top-level field per variable, preserving its runtime type)
Instead: Workspace Variables ({{ $var.NAME }}) for values shared across multiple automations

Keyboard shortcut: t+v

When it is worth one

Any step can already read any earlier step by number, so a variable is not how you move data forward. {{ 3.email }} does that on its own.

Use one to name a calculated value or record a flag for later Steps. You can also define a starting value in one place instead of repeating it across several fields. It produces Step output, not a shared variable that later Steps overwrite.

Setting it up

Add the step

Press t+v, or open Tools → Data → Change in the dock and select Custom Variables.

Name the variable and set its value

Under Variables, type a Name at the top of the card, then enter a literal Value or pick a reference from an earlier step using the picker at the upper right of the value field.

Add more variables if needed

Select Add variable to define multiple variables in the same step.

Rule	Details
Allowed names	Letters (`A-Z`, `a-z`), digits, `_`, `$`, and `-` (e.g. `discount_rate`). Spaces, dots, brackets, empty names, and reserved keys (`__proto__`, `prototype`, `constructor`) are rejected.
Run scope	Computed fresh on each run. To persist tables, lists, or key-value records across runs (with optional TTL expiration), use Data Store or workspace variables.
Step scope	Each Custom Variables step owns its values: `{{ 3.status }}` and `{{ 7.status }}` stay independent. Reusing a name within the same step keeps only the last row’s value and logs a warning.

Types

Each variable card detects its type automatically as you type. Click the type badge on a literal value to override it (for example, to keep 42 as Text):

Value written	Detected type & behavior
`["red", "amber", "green"]`	List (can be passed directly into Run for each item or Repeater)
`{"plan": "pro"}`	Record (accepts literal closing braces in raw JSON, regexes like `\d{1,2}}`, and embedded `{{ 1.email }}` placeholders)
`42` / `true`	Number / Yes/no
`{{ 3.ret.items }}` (single reference alone)	Shows no badge while editing; preserves the source value’s exact runtime type
`Order {{ 3.id }} for {{ 3.customer }}`	Text (mixing a reference with surrounding characters produces a string)

What it passes on

Each variable becomes a field on the step, named exactly as you named it. A step 3 that sets discount_rate is read downstream as:


{{ 3.discount_rate }}

There is no wrapper in between. The variable name follows the step number directly. Insert references from the data picker rather than typing them, and check the Variable Reference Syntax if a path is not resolving.

Examples to copy

A decision made early, used late

2. CRM Lookup3. Custom Variables4 to 8. Branch & Loop9. Apply Discount

At step 3, set loyalty_tier from the CRM lookup.
At step 9, use {{ 3.loyalty_tier }} to pick the discount.

Naming the value here gives later Steps one place to read it. If the automation branches, make sure both the CRM lookup and this Custom Variables Step run on every path that needs {{ 3.loyalty_tier }}.

A flag decided mid-flow

Somewhere in the middle, a Custom Variables step (say step 7) sets requires_approval from a rule: an amount over the threshold makes it true.
At the end, branch on {{ 7.requires_approval }} to decide whether to route through Human Review.

Read the flag from the step that set it. A variable belongs to its step. A later step setting the same name does not change an earlier one. The branch has to reference the step whose value it wants.

Counting what a loop did

You do not need a variable for this. A step running per item passes on {{ N.stats }}, with total, succeeded, failed and skipped already counted. See Loops & Iteration. Reach for a variable only when you are counting something the loop does not track for you.

Verify it works

Run: Add a variable named discount_rate with value 0.15 (Number) and click Run step in Test & Debug
You should see: The Output tab shows { discount_rate: 0.15 } at the top level, ready to reference as {{ N.discount_rate }}.

What’s Next?

Persist tables, lists, or key-value records across runs with optional expiration in Data Store.
Reference stored values correctly using the Variable Reference Syntax.
Store workspace-wide configuration and credentials in Secrets and Variables.