An environment variable is a named value — including secrets — stored once on the platform and referenced by name from automations, apps, and API configurations, instead of hardcoded into each one.

Overview

Because assets reference the variable's *name*, the same asset can run in dev, UAT, and production while each environment keeps its own value for that name — you promote the variable with a change set and set the right value in each environment. Environment Variables are managed per workspace under Environment Variables, shown as a searchable table. Values are held encrypted, and you can mark any variable sensitive so its value is never sent to the browser.

Use Cases

• Store a database URL or API key once and reference it by name from every automation and app that needs it, instead of hardcoding it repeatedly.

• Run the same automation in dev, UAT, and production, each with its own secret value for the same variable name.

• Mark credentials, tokens, and secrets sensitive so their values are never decrypted for the browser.

• Rotate a credential or seed per-tenant configuration directly from within an automation, rather than editing each variable by hand.

• Flip a platform capability on or off through the Feature Flags screen's friendlier toggle view over the underlying System variable.

Managing Environment Variables

The table lists every variable with these columns: Name, Value (masked — see sensitivity below), Sensitive (a Yes/No tag), Shared with (Everyone, Only me, or a count of specific Users/Teams), Workspace, Created By, Created On, Last Updated By, and Last Updated On (with a hover audit tooltip). You can search by name, reorder columns and save views, sort (default is newest first), and click a row to open it for editing.

The list pages 30 at a time with infinite scroll. If there are none yet, the empty state reads "No Environment Variables — You haven't created any environment variables yet." with a New Environment Variable button. The Workspace column only appears in the default workspace when you have the right permission; it's hidden elsewhere and on the System tab.

Custom and System Tabs

In the default workspace, and if you have the required permission, the list splits into two tabs: Custom — variables your team created — and System — platform-defined (standard) variables that ship with the platform and drive platform behavior. Many System variables are the on/off switches behind platform capabilities; the friendlier way to change those is the Feature Flags screen. System variables are global rather than workspace-scoped, so the Workspace column is hidden on the System tab. Without the permission, or in any non-default workspace, you simply see that workspace's own variables with no tabs.

Creating an Environment Variable

New Environment Variable opens a modal with a Best Practices note — use uppercase with underscores for names, mark credentials/tokens/secrets as sensitive, provide descriptive details, consider a secret manager for highly sensitive values — followed by these fields:

Names must be unique within a workspace — a duplicate fails with "Environment variable with same name already exists.", shown under the Name field and as a toast. When you edit later, the name is read-only; only the value, workspace, and sensitivity can change.

Sensitive Values and Masking

Every variable's value is stored encrypted. Marking one sensitive additionally stops the platform from ever decrypting that value for the browser. In the list, values show as dots (••••••••••••) with an eye toggle; revealing a value requires read permission on that variable — otherwise the eye is disabled with "You do not have read permissions for this environment variable" — and a sensitive value stays masked even so.

Note: you can still use a sensitive variable anywhere — when an app or automation references it, the server substitutes the real value at execution time, so the secret is injected on the server and never reaches the browser. Use sensitive for credentials, tokens, and secrets.

Using Environment Variables in Apps and Automations

• Referencing a Variable

• In apps: reference a variable in expressions as {{ envVariables['NAME'] }} — for example inside a data source input. Sensitive values are resolved by the server, never in the browser.

• In automations: the workflow builder's data panel shows an Environment Variables group (alongside Run Variables and User Variables); pick a variable as a pill to map it into any node input.

A reference to a name that doesn't exist doesn't raise an error — it simply resolves to an empty value. So if an app or automation gets a blank where you expected a value, check for a typo in the name or a variable that only exists in another workspace.

Note: very large tenants have a practical ceiling — only the first 1,000 variables are loaded for runtime resolution.

Creating, Updating, and Deleting from an Automation

Alongside referencing them, automations can create, update, and delete environment variables through the platform's Environment Variables actions:

• Create takes a name, value, and sensitive flag, and makes a variable in the current workspace. It fails if you lack create permission, or if the name already exists. An automation can mark a variable sensitive but cannot create a System (standard) variable.

• Update changes a variable's value (and sensitivity) by name; it needs edit permission and fails if the name doesn't exist in the current workspace. It replaces the variable's stored properties with what you pass, so send the full value each time.

• Delete removes a variable by name and needs delete permission.

Use these to rotate a credential or seed per-tenant configuration as part of a workflow, rather than editing each variable by hand.

Environment Variables and Change Set Promotion

Environment variables are change-set assets. When you promote an automation, or other asset, the platform automatically detects which variables it references and includes them, so the names always travel together. Values are not applied automatically on import: the change set carries the value, but each variable is a replaceable asset, so the target environment keeps its own value unless you choose otherwise.

During an inbound change set you'll see a step — "Please verify the required Environment variables" / "Values of an environment variable aren't imported by default. Please set the required values for new environment variables." — where you:

• Enter a value for each new variable (Enter Variable Value).

• See existing target values masked, with an eye toggle to reveal or change them.

This is what lets the same automation run in dev, UAT, and production with different secrets in each.

Sharing, Deletion & History

Each row's menu offers Edit, Share, and Delete, each shown only if you hold that permission on the variable. Share opens the standard asset-sharing dialog so you can grant others access — including the read access needed to reveal a value; the list's Shared with column reflects the result (Everyone, Only me, or the number of users/teams granted access). Delete asks "Delete Environment Variable? Are you sure you want to delete the environment variable '<name>'? This action cannot be undone."

Note: the platform tracks which automations reference a variable, but deleting it does not repair those references — anything still using the name will simply resolve to empty, so update references first.

Change history for a variable is surfaced through the Feature Flags screen's history panel — a day-grouped timeline of entries (Created, Updated, Turned on, Turned off) with the actor (System or a user). There is no per-variable history panel on the Environment Variables list itself, so for ordinary Custom variables the audit trail isn't shown on this screen, though every create, update, and delete is still recorded server-side.

Notes

• Use uppercase names with underscores, and mark every credential, token, or secret as sensitive.

• Confirm the exact name and workspace before assuming a reference is broken — an unresolved name fails silently to an empty value rather than raising an error.

• Set the target value explicitly during an inbound change set's Environment variables step, since values never carry over automatically.

• Update references to a variable before deleting it — deletion doesn't repair or warn about existing references.

• Prefer the platform's Environment Variables actions in an automation over manual edits when rotating a credential across many workspaces.

• Watch the 1,000-variable runtime resolution ceiling on very large tenants when relying on a large number of variables.