Variables
Named values that every automation can reference: a plain variable for ordinary text, a secret for anything sensitive. Define a value here once, reference it by name from any field that accepts one, and change it in a single place when it changes. For how references work inside a flow, see Variables and secrets.
The layout
The left rail holds two lists, stacked, each with its own create link above its entries—New Variable and New Secret:
| List | What it holds |
|---|---|
| Variables | Plain-text values, listed by name. |
| Secrets | Encrypted values, listed by name. |
Selecting an entry opens its form on the right. With nothing selected, the panel asks you to pick one or create a new one. Both lists are alphabetical by name.
The fields
A variable and a secret ask for the same two things:
| Field | What it does |
|---|---|
| Name | How the value is referenced. Case-sensitive: apiKey, APIKEY, and apikey are three different entries. Names must be unique within their list; a variable and a secret may share a name without colliding. |
| Value | For a variable, the text itself, stored as entered. For a secret, an encrypted value—shown masked once saved, and replaced rather than read back. |
A secret's value must be at least four characters. Shorter values cannot be reliably recognized and hidden in run output, so the form rejects one rather than storing a value it would leak. A secret with no value at all saves fine—useful when you are naming things ahead of having the credential, or filling in an imported automation—but the form warns you that fields referencing it will not resolve until a value is entered.
Store credentials, tokens, and anything else sensitive as secrets, never as plain variables. Only a secret's value is encrypted, and only a secret's value is redacted from execution logs and step output.
Where these values can be referenced
Everything defined here is available to every automation.
Wherever a field accepts variables, it carries a {} button that opens the picker; the picker lists your variables and secrets alongside the trigger's data and earlier steps' output. A reference resolves to the value's current contents at the moment the step runs, so editing a value here changes what every automation referencing it sees on the next run.
An automation can also define variables and secrets of its own, from its settings in the flow editor. Those are visible only to that automation, and when an automation-scoped value shares a name with one defined here, the automation's own value wins. That is how one flow overrides a shared value without affecting the others.
Where to go next
- Variables and secrets—inserting references into fields, what is in scope where, and automation-scoped values.
- Connections—the place for credentials that authenticate a whole integration, rather than a single field.