Variables

What a variable is

A workflow variable is a named, typed value scoped to the workflow — created once, then referenced from any step or route via {{variables.<key>}}. Use it for anything that shouldn't be hardcoded into a step — credentials, config that changes per environment, feature toggles.

{{variables.<key>}} is a distinct namespace from {{runtimeVariables.<key>}} — the latter is a separate, mutable, execution-scoped store written by the Variable connector while a run is in progress, not the workflow-level variables documented here. See Step Reference for the full set of {{...}} namespaces.

Creating a variable

• Display name — required, shown throughout the UI.
• Variable key — required, auto-derived from the name (lowercased, spaces and non-alphanumeric characters collapsed to underscores) but editable.
• Type — one of the ten types below.
• Required — whether a value must be set before the workflow can run.
• Default value — the field shown here depends on the type (see below).
• Description — optional, documents how it's used.

Variable types

• String — plain text.
• Secure String — like String, but the value is encrypted at rest (AWS KMS envelope encryption, the same protection a Connection's credential fields get) and masked in the UI (password-style input with a show/hide toggle). It's decrypted only at the moment a {{variables.<key>}} reference to it is actually resolved during a run, never returned in an API response.
• Integer — a whole number.
• Float — a numeric value.
• Boolean — True, False, or left unset.
• JSON — any JSON value, edited in a validated JSON editor.
• Array — a list of values, built as repeatable rows and stored as a JSON array.
• Key-Value Map — a set of key/value pairs, built as repeatable rows and stored as a JSON object.
• Connection — references a Connection. Optionally restrict which connection types are allowed (leave empty to allow any), then pick a default connection from a searchable list — or create one inline via New connection without leaving the form. This is the type a connector step's Connection Variable picker looks for.
• Schedule (Cron Expression) — a cron expression, validated on save, with a live preview of its next run times.

Using a variable

Reference a variable's value from any step or route with {{variables.<key>}}. A route's own auth (API key/JWT secret) and a connector step's authentication both work by pointing at a variable rather than embedding a value directly, and a Schedule-type variable can drive a Schedule trigger's cron expression the same way — set once, referenced wherever it's needed, and changeable per environment via Launch Configuration without editing every place that uses it.

Test mode

A variable can be marked Test mode. A test-mode variable:

• is included when the workflow is run in isolation with Test Run — sourced from its default value — so a workflow that otherwise relies entirely on values passed in by a calling workflow (see below) can still be exercised on its own;
• is hidden from the Launch Configuration screen and is never written into a published workflow's live instance;
• so in production, {{variables.<key>}} for a test-mode variable resolves from the calling workflow's value (see "Sharing variables with an invoked workflow"), not from its own default.

A variable that backs a route's API-key/JWT authentication or a workflow's JWT RBAC secret can't be marked test mode — that's rejected when you save, since the auth could never be satisfied in production.

Sharing variables with an invoked workflow

When a workflow is invoked from inside another one — via Invoke Workflow, Invoke Route, or a Proxy routing rule whose type is workflow — the invoked workflow inherits the caller's variable values. For any key the invoked workflow doesn't define or configure itself, {{variables.<key>}} resolves to the caller's value; where both define the same key, the invoked workflow's own value wins. This is the same {{variables.<key>}} syntax — there's no separate namespace — and it flows through a whole nested chain, so a workflow three levels deep still sees the values set at the top.

Examples

String

Variable storeName set to "Acme Co":

Hello, {{variables.storeName}}!

resolves to Hello, Acme Co!

Integer

Variable maxRetries set to 3:

{{variables.maxRetries}}

resolves to 3.

Boolean

Variable featureEnabled set to true:

{{variables.featureEnabled}}

resolves to true.

Connection

Variable stripeConnection (type connection, bound to a Stripe connection):

{{variables.stripeConnection}}

resolves to that connection's resolved context as JSON. Add a property path to pull out one field instead of the whole object — {{variables.stripeConnection.someField}}. In practice most steps don't need this directly: a connector step's own Connection Variable picker (see Connections) already wires up authentication for you — referencing {{variables.<key>}} by hand is for pulling a piece of connection config into a step's input, not for authenticating the step itself.