Variables

A variable is a named value that lives in a scope — a User Space, Organization, Group, or Project — and can be referenced from the task templates in that scope. Instead of typing a hostname, a tolerance value, or an API key into every node that needs it, store it once and point at it by name.

Variables are managed under Variables in the scope’s navigation. The screen requires admin access to the scope; any scope member can reference an existing variable while editing a task template.

Anatomy

Field	Meaning
Key	The name you reference it by. Letters, digits, ., _ and - are allowed. Dots namespace by convention (never by enforcement): smtp.host, smtp.port.
Value	The value itself — see Value types below.
Description	Free text, shown next to the key wherever the variable can be picked.
Secret	Makes the value write-only and encrypts it at rest in the store — see Secrets.

Value types

The value input has two explicit modes, and nothing is ever guessed from what you type:

• String (the default) — the text is the value, verbatim. 587 is the string "587".
• Typed — a JSON editor takes over, and the value is whatever the JSON denotes: a number, a boolean, null, an object, or an array.

Switch modes with the badge next to the value field. A value may be up to 64 KiB in its JSON form, because it is copied into every task that references it.

Inheritance

Variables follow the same downward flow as the other entities described in Structure & Access: an Organization’s variables are available in its groups and their projects. On a key collision the nearest scope wins — a project’s own smtp.host shadows the organization’s.

That is what makes an environment-per-scope setup work: the same template, referencing the same key, resolves to a different value depending on where it runs.

Referencing a variable

There are exactly two places a template can name a variable.

In a service node’s configuration

Every configuration field of a service node can be a Literal, a Computed value, or a Variable — the three are mutually exclusive per field. Switch the field to Variable and pick a key from the list; secrets are marked with a lock icon.

A variable fills a whole field. It cannot be spliced into part of a string or placed on a nested property — build those with a computed field or a logic node instead.

In a script

Logic nodes and computed configuration fields read variables through context.variables:

const host = context.variables.get('smtp.host')

host = context.variables.get('smtp.host')

The call is identical in TypeScript, JavaScript, and Python — including the method name. Four things to know about it:

• The key must be a literal string. get('smtp.' + region) cannot work and is reported as a template error.
• There is no await. The call yields the value directly.
• The editor knows your variables. Keys autocomplete from the template’s scope, and the return type is the shape of the stored value ({ password: string } rather than unknown), so a typo is a red squiggle rather than a failed task. Secrets are typed exactly like plain values — the shape is recorded when the value is written, so the type never reveals the value itself.
• An unknown key is a template error, surfaced while you edit, long before a task runs.

When values are resolved

Values are resolved when a task is created, not while it runs. A variable behaves like process.env in a build tool: creating a task substitutes every reference with the value that is current at that moment, and the running task never asks the store for anything again.

Everything else follows from that:

Situation	What happens
You change a value	Tasks created afterwards use the new value. Tasks that are already running keep the value they were created with — including long-running continuous tasks.
You rerun a task	The rerun keeps every value the original was created with. To pick up a new value, start a new task from the template.
You delete a variable a running task uses	The task keeps running on the value it baked. Stop the task if that matters.
The key is missing when a task is created	Task creation fails and names the node and the field or script involved.

Renaming is safe

Renaming a variable is a first-class operation, not a delete-and-recreate: Requence rewrites every reference in dependent templates so they keep working — configuration fields structurally, script calls in place, in stored templates as well as in editors that are open at the time.

Only the documented literal call forms are rewritten. A key assembled at runtime is not (and, per above, cannot work anyway).

Blast radius and validation

Every variable in the list has a dependents button that shows which task templates reference it, before you change or delete anything.

Deleting a key — or creating one that shadows an inherited key — re-validates the templates that referenced it. A template that references an unknown variable becomes invalid, which means it refuses to start tasks (and automations built on it report as invalid) until the reference is fixed.

Secrets

Turning on Secret changes two things: the value becomes write-only — it is encrypted at rest in the store and never shown again, in the UI or through the API — and Requence records it for redaction from served task content. Everything else is unchanged: a secret is referenced from configuration fields and read from scripts exactly like a plain variable, so flipping the flag never requires a template edit.

Making a secret variable plain again requires entering a new value; what was hidden cannot be un-hidden. Leaving the value field empty when editing a secret keeps the stored value.

Caution

A secret protects the store, not the task. When a task is created, the plaintext is baked into that task’s execution snapshot like any other value, and any scope member who can author or run a template that references the secret can obtain its value. Requence redacts known secret values from task inputs, results, and error text on a best-effort basis — treat that as a guardrail against accidental exposure, not as an access boundary.

Because values are frozen at creation, rotating or deleting a leaked secret does not affect tasks that already exist: stop them, then start new tasks from the template. A rerun would carry the old value forward.

Branches

Variables are branch-aware, like schemas, task templates, and services. You can add or change one inside a branch, test with it there, and merge it into live in the same step as the templates that use it. A task started from a branch uses that branch’s values; a task started from live uses live’s.

In a branch diff, a secret’s value is shown as <secret> rather than its contents.

Import & export

The variables that exported templates reference travel with the bundle, but importing them is create-if-absent, never update: a key the target scope already resolves — its own or an inherited one — is left completely untouched. The template is the code; the variables are the environment, and re-importing a template must not overwrite the target’s configuration.

A secret travels without its value — no deployment can decrypt another’s. It is created with its type but no value, is listed in the import summary, and task creation fails until someone sets the value on the target.