Connectors

Variable Connector

Set, read, and delete typed variables scoped to the current workflow execution — a mutable {{runtimeVariables.<name>}} store, separate from workflow-level {{variables.<key>}}.

On this page

What this connector is for Set Variables Configuring it Reading the response Example Get Variable Configuring it Reading the response Delete Variable Configuring it Reading the response Step Name Step Reference Execution Settings

What this connector is for

Reads, writes, and deletes runtime variables — a mutable store scoped to the current workflow execution, readable anywhere later in the same run (including nested loop conditions) via {{runtimeVariables.<name>}}. This is a separate namespace from workflow-level Variables ({{variables.<key>}}, fixed at publish time) — see Step Reference for both. No connection is needed; like the Data Table and Cache connectors, this is platform-internal state, not a third-party integration.

Set Variables

Writes one or more typed variables for the rest of the execution.

Configuring it

Variables — required, one or more rows. Each row has:
- Name — referenced later as {{runtimeVariables.<name>}}.
- Type — string, number, boolean, object, or array. Defaults to string.
- Value — required, always written as a JSON string, even for a boolean/number/object/array Type — write "true" or "42" or '{"a":1}', never a bare true or 42. If the entire Value is a single {{...}} expression, it's resolved and used as-is with its own native type preserved (not coerced to Type); otherwise it's parsed as a literal of the declared Type — an invalid literal (e.g. Type number with Value "abc") fails the step.

Reading the response

{{<stepReference>.variables}} — the name → resolved value map that was written. For example, a step named "Set Retry Count" (reference setRetryCount) — use {{setRetryCount.variables.retryCount}} to read the value it just wrote ({{runtimeVariables.retryCount}} also works, and doesn't depend on this step's reference).

Example

Variables:
  - name: retryCount, type: number, value: "0"
  - name: isEligible, type: boolean, value: "{{getOrderDetails.response.data.eligible}}"

Get Variable

Reads a single runtime variable's current value. Mostly a convenience for inspecting a value in execution logs, or when you need it as this step's own output — a step's own parameters can already reference {{runtimeVariables.<name>}} directly without this action.

Configuring it

Name — required. The variable's name.

Reading the response

{{<stepReference>.name}} — the variable's name.
{{<stepReference>.value}} — its current value (unset if it was never written, or was deleted).
{{<stepReference>.type}} — the resolved JavaScript type (typeof the value) — not the same as the string | number | boolean | object | array Type used when setting it.

For example, a step named "Read Retry Count" (reference readRetryCount) — use {{readRetryCount.value}} to get its current value.

Delete Variable

Removes a runtime variable so later {{runtimeVariables.<name>}} references resolve as unset.

Configuring it

Name — required. The variable's name.

Reading the response

{{<stepReference>.name}} — the variable's name.
{{<stepReference>.existed}} — whether it was actually set before this step ran.

Also applies here

Step Name

What it's for

Every step in a workflow gets a name — either one you set or a default based on the connector and action (e.g. "Get Order Details", "Send Welcome Email"). It's shown throughout the UI and in your execution history, and it's also the source for the step's Reference — a camelCase identifier auto-generated from the name (e.g. "Get Order Details" → getOrderDetails) — which is what you actually use in {{...}} expressions to read this step's output from later steps. See Step Reference.

Rules

Must be at least 2 characters, and 50 characters or fewer.
Must be unique within the workflow — reusing a name that's already taken will be rejected, with a suggested alternative (e.g. "Get Order Details 2").
Can't be empty.

Tips

Prefer a descriptive, human-readable name over a generic one — "Get Order Details" is easier to work with later than "HTTP Request 2", especially once a workflow has a dozen steps.
Renaming a step updates every reference to it elsewhere in the workflow automatically.

Step Reference

Syntax

Any input field can reference earlier data using {{expression}}. The expression is evaluated as JSONata — so simple dot-paths and more advanced queries (filters, functions) both work.

Referencing a step's output

Use the step's Reference — a camelCase identifier auto-generated from its Name (e.g. "Get Order Details" → getOrderDetails), shown read-only wherever the step's fields are configured — followed by the field path. Elsewhere in these docs this general pattern is written as {{<stepReference>.field.path}}:

{{getOrderDetails.response.data.id}}
{{getOrderDetails.response.status}}

The raw display name won't work here even though it's what you see in the UI — {{Get Order Details.response.data.id}} isn't valid, since a bare name containing spaces isn't a single JSONata identifier. Always use the camelCase Reference.

You can also reference steps by position instead of by reference:

{{steps[0].response.data.id}}

Referencing trigger data

{{trigger.headers.authorization}}
{{trigger.body.customerId}}
{{trigger.query.page}}
{{trigger.params.orderId}}
{{trigger.method}}
{{trigger.path}}

Referencing workflow variables

{{variables.myVariable}}

See Variables for the full list of variable types and more examples, including connection-type variables.

Referencing runtime variables

A separate, mutable namespace written by the Variable connector while a run is in progress — not the same as the workflow-level variables above:

{{runtimeVariables.myVariable}}

Notes

If an expression can't be resolved (a typo in a step name, a field that doesn't exist), it resolves to an empty string rather than failing the workflow — check your execution history if a value comes through blank.
Object values are automatically JSON-stringified when interpolated into a string field.

Execution Settings

Fire-and-forget

When enabled, the workflow doesn't wait for this step to complete before moving to the next one. Use it for steps whose result nothing downstream depends on — logging, analytics, notifications — so they don't add latency to the steps that matter.

Continue on error

When enabled, a failure in this step doesn't stop the workflow — execution continues to the next step. The failure is still recorded in the execution history; this just controls whether it's fatal.

Combine the two for steps that are genuinely optional to the outcome: fire-and-forget so they don't add latency, continue-on-error so a failure in them (e.g. an analytics endpoint being briefly down) doesn't take down an otherwise-successful workflow run.