Environments: A Rehearsal Sandbox for Your Automations
Workflows now supports named environments with their own variables and credentials — including a policy that can block a workflow from ever running live.
Workflows now has first-class environments — named sets of variables and credentials you can switch a workflow between, with the option to lock one down so nothing in it can ever touch a live system.
What an environment is
An environment is a named collection of variables and credentials a workflow reads from. You can create as many as you need — a typical setup separates a rehearsal environment from a production one, each with its own values (a sandbox API key here, a live one there) without touching the workflow's logic at all. Environments are managed from their own panel in the editor, and you can create, update, and delete them independently of any single workflow.
The part that's actually enforceable
The detail worth knowing: an environment's policy can forbid live runs outright, not just as a naming convention you have to remember to respect. Set an environment to rehearsal-only, and a workflow running under it is blocked from executing for real — not just discouraged by a label in the UI.
Why we built it this way
Most automation tools on the market don't separate development from production as a built-in concept — the common workaround is a second account, or a spreadsheet-style config table keyed by an "env" field that a workflow has to check manually. We'd rather give you a real environment object with enforceable rules than leave that discipline entirely up to convention.
If you've been testing changes against production credentials because there was nowhere else to point them, this is built for exactly that gap — a place to rehearse an automation with real logic and fake (or at least non-production) consequences, before it ever touches anything that matters.