Approvals and deployments
Promote a published flow through environments, get it approved by a second person and roll back safely.
Updated 07/10/2026
Environments
Each integration can have deployment environments with a key, a display name and a lifecycle: development, test, staging or production. An environment can bind specific connections and runtime settings, so the same flow version can point at sandbox accounts in test and real accounts in production.
| Lifecycle | Approval policy |
|---|---|
development | Revisions are approved automatically |
test, staging, production | At least one approval, from a different person than the one who created the revision |
Deploy a flow version
Publish the flow version (see Flows, mappings and schedules).
On the integration, open Environments, choose the environment and create a revision for the published version.
The revision is pending_approval. A workspace member with the deployment-approval permission opens Dashboard → Approvals and approves or rejects it. A rejection must include a comment of at least three characters.
Once approved, Activate the revision. Scheduled and MCP-triggered runs in that environment now use it.
If something goes wrong, Roll back to the previous approved revision.
You cannot approve a revision you created. Only approved revisions can be activated.
Approvals for sensitive actions
Other actions also go through Approvals:
connector actions marked as needing approval in the sandbox explorer;
MCP tools that require confirmation (see Use the Nexra MCP server);
credential actions.
An approval request records the action, the target, the environment, a hash of the payload and an expiry time (30 minutes by default, up to 24 hours). It can require up to five approvals. Re-sending the same idempotency key with a different payload is refused. The requester or a manager can cancel a pending request.