Release Approvals

Human approval gates on release execution and other sensitive operations: per-environment approvals, segregation of duties, approval channels, and the approval lifecycle.

Releasing a release candidate to an environment is gated by a human approval. The gate is part of the release workflow itself and runs on every release execution unless explicitly skipped.

Approvals are per environment

When a release is requested for multiple environments, the server fans the request out into one release execution per environment, and each environment's execution runs its own approval gate. A release candidate going to staging and prod produces two independent approval requests, each with its own approver decision and its own audit record.

There is no implicit propagation: approving the staging deployment does not approve prod.

Automation contexts that require unattended execution can pass skipApproval on the release request. The skip applies to the whole request and is recorded in the workflow output.

Who can approve

• Approval and rejection require the owner role on the project.
• By default, all owners are notified as eligible approvers; an approval request can also carry an explicit approver list.
• When the request originates from a CI/CD provider, the responder's provider identity (for example a GitHub username) is resolved to their account email before authorization is checked.

Segregation of duties

For SOX Section 404, the person who requests a change must not be the person who approves it. Enable this per project:

{
  "configuration": {
    "approvalSettings": {
      "requireSegregationOfDuties": true
    }
  }
}

With the setting enabled:

• A human requester cannot resolve their own approval request — self-approval is rejected by email match, case-insensitively.
• Non-human requesters (application tokens, api, system) are exempt, since there is no human identity to compare against. CI-triggered releases are not blocked.
• If the project configuration cannot be read at decision time, the approval is denied rather than allowed — the check fails closed.

Every decision, including the SoD outcome, lands in the approval audit trail (see Audit Trails).

How approvers respond

Approval requests surface in several places; any of them can be used to respond.

Web UI. Pending approvals appear on the home dashboard, in the sidebar approver popover, and on the dedicated Pending Approvals page under Workflows (/workflows/pending-approvals). Each request opens a review dialog showing the release candidate, target environment, and requester, with approve/reject actions.

Issue comments (GitHub / Azure DevOps). When a release is driven from an issue or work item, the gate posts a comment describing what is awaiting approval. Approvers respond in-thread:

/sfp approve
/sfp reject --reason "Change freeze until Monday"

Slack. When a Slack callback is configured, the request is posted to the configured channel or thread and can be approved or rejected from there.

API. POST /flows/approvals/{taskId}/approve and POST /flows/approvals/{taskId}/reject for programmatic integration with an external approval system.

Approval lifecycle

An approval request moves through the following states; every transition is recorded in the audit trail:

State	Meaning
pending	Waiting for an approver. The release workflow is durably parked — no compute is held while waiting.
approved	An owner approved; the workflow resumes and the deployment executes.
rejected	An owner rejected (with an optional reason); the workflow finalizes without deploying.
expired	No decision within the approval window (24 hours by default, configurable per request). The workflow does not deploy.
cancelled	The underlying request went away — for example, the driving issue was closed.
stale	The workflow reached a terminal state while the approval was still open; a background reconciliation job marks the orphaned request so it does not linger as actionable.

Expiry and stale detection run continuously server-side; an unanswered request cannot be approved and deployed after its window has passed.

Other operations behind approval gates

The same gate protects operations beyond release execution:

• Release rollback — rolling back a release to an environment.
• Sandbox lifecycle — creating, refreshing, and deleting sandboxes (operations that consume licenses or destroy environments).
• Privilege elevation — temporary, time-boxed access elevation in an org. The workflow waits for approval, elevates the user, sleeps for the requested duration, and then restores the original access level automatically. De-elevation does not require a manual revocation step.

Each of these produces the same audit evidence as a release approval.