Create Approval Workflows

Require human approval before production deployments to prevent unreviewed changes from reaching critical environments.

Before you start

Scenario

Your team needs to:

• Require manager or senior engineer sign-off before production changes
• Allow staging deployments to run automatically without gates
• Block deployment if no one approves within 4 hours
• Have a full audit trail of who approved what and when
• Support escalation when the primary approver is unavailable

How approvals work in ops0

ops0 approval gates sit inside Workflows. When a workflow reaches an Approval step, execution pauses. Configured approvers receive a notification (Slack, email, or both) with the deployment context — plan output, cost estimate, policy results. They can approve or reject directly from Slack or from the ops0 UI. Only after approval does the workflow proceed to the deploy step.

Workflow execution
────────────────────────────────────────────────────────
Step 1: Run Plan          → produces plan output
Step 2: Approval Gate     → pauses, notifies approvers
         ↓ approved
Step 3: Apply             → deploys infrastructure
Step 4: Notify Slack      → posts result to #deployments

Step 1: Create the workflow

Step 2: Add workflow steps

Build the following step sequence in the workflow canvas:

Step 1 — IaC Plan

Step 2 — Approval Gate

Step 3 — IaC Apply

Step 4 — Notify

Step 3: Configure approver notifications

Slack notification

When an approval is requested, approvers receive a Slack message with full context and interactive buttons:

Email notification

Approvers also receive an email with a direct link to the approval page in ops0 if Slack is unavailable.

Step 4: Approve or reject in ops0

Approvers don't have to use Slack. They can also act from inside ops0:

Common patterns

Pattern 1: Staging auto, production gated

Two separate workflows — one for staging (no approval), one for production (with approval):

staging-deploy workflow:
  Step 1: Plan
  Step 2: Apply     ← no gate, runs automatically

production-deploy workflow:
  Step 1: Plan
  Step 2: Approval  ← required
  Step 3: Apply
  Step 4: Notify

Trigger both via GitHub PR — use a Condition step or separate workflows per environment branch.

Pattern 2: Two-person rule for critical infra

For database schema changes or IAM modifications, require 2 approvals:

Any 2 of the 4 team members can approve — the workflow proceeds once the threshold is met.

Pattern 3: Approval with escalation

Use a Condition step after the approval to check who approved and escalate if needed:

Step 1: Plan
Step 2: Approval (1 required, 2 hour timeout)
Step 3: Condition — if cost > $500/month
  → true: second Approval step (requires Finance team)
  → false: proceed to Apply
Step 4: Apply
Step 5: Notify

Pattern 4: Emergency bypass

For incidents where you need to deploy without waiting:

• Keep a separate workflow production-emergency-deploy with no approval gate
• Restrict who can trigger it to Admin role only
• The action is still logged in Audit Logs for post-incident review

Audit trail

Every approval action is captured in the audit log:

View at Settings → Audit Logs and filter by workflow name or user.

Troubleshooting

Best practices

Next Steps