Approving and Rejecting Releases

Review, approve, reject, or abort a release that Facets is holding at a release approval gate in an environment's release history.

When a release matches the approval criteria configured for a project, Facets stops the release before it applies any change and sets its status to Pending Approval. The release waits there until someone approves it, rejects it, or aborts it.

Overview

Approvers act on gated releases directly in the environment's release history. Facets surfaces the request natively, so no external ticketing tool is involved and no notification or reminder is sent.

A parked release holds the environment's release queue, so treat pending requests as time-sensitive.

Find releases awaiting approval

Open the project and go to the environment you want to review.
Open the environment's release history.
Use the Status filter and select Pending Approval to show only gated releases.

The Status filter also offers Rejected, which is useful for auditing releases that an approver turned down. Releases that already passed through a gate carry an Approved tag in the table.

Review before you approve

Facets captures the Terraform plan output as soon as it observes the release in Pending Approval. The plan stays available for as long as the release sits at the gate, so you can review exactly what the release will change before you act on it.

To read it, use the View Terraform Logs row action on the gated release.

📘

Reviewing the captured plan is the point of the gate. Check the resources and change types in the plan before approving a release to a sensitive environment.

Approve a release

Approving lets the release continue into its apply phase.

Open the environment's release history and locate the row with the Pending Approval status.
Open the row actions and select Approve.
Read the Approve Release confirmation. It names the release type and the user who triggered the release.
Type Confirm in the confirmation field.
Select Approve.

Facets shows "Release approved successfully" and refreshes the release history and the deployment overview.

📘

Sign Off is a separate row action with its own confirmation. It is not part of the release approval gate.

Reject a release

Rejecting terminates the gated release.

Open the environment's release history and locate the row with the Pending Approval status.
Open the row actions and select Reject.
Read the Reject Release confirmation. It names the release type and the user who triggered the release.
Type Confirm in the confirmation field.
Select Reject.

Facets shows "Release rejected successfully", and the releases queued behind it resume.

🚧

Rejected is a terminal status. You cannot reopen or re-approve a rejected release. To ship the same change, trigger a new release, which passes through the gate again.

What happens after you approve

Facets runs releases on two execution paths, and approval produces a visibly different result on each. The path depends on how the release itself runs, not on anything you choose at the gate.

Behavior	CRD-driven releases	Pod-based releases
What happens on approve	The same release advances past the gate into its apply phase and resumes.	Facets marks the gated release Approved and triggers a follow-up apply release.
New release created?	No. The release list shows one release throughout.	Yes. The release list shows a second, chained apply release.
Who it is attributed to	The original release keeps the attribution it already had.	A bot user triggers the follow-up release, and Facets records the approver's name on it.

On both paths, rejecting terminates the release rather than chaining anything after it.

Rules and limits

Only the most recent release on an environment can be approved. Facets rejects an approval of an older release even if it still shows Pending Approval.
Approve and Reject appear only on rows whose status is exactly Pending Approval.
If two approvers act at the same time and the release already moved past the gate, the second action resolves as success rather than an error.
Facets does not time out a release parked at a gate. The status reconciler keeps the release under active observation instead of force-failing it.
On the pod-based path, approval and creating the follow-up apply release are not atomic. If the apply release fails to start, Facets reverts the status to Pending Approval so you can approve it again.

Abort a release waiting at a gate

A gate clears in one of three ways: approval, rejection, or aborting the release. There is no way to bypass a gate. When a release sits at a gate and nobody is going to act on it, abort it.

Aborting voids the release, releases the environment lock, and runs cleanup. The other releases waiting on that environment then resume.

🚧

Aborting is destructive and terminal. Facets cannot abort a release that already reached a terminal status.

Permissions

Approving or rejecting a release requires the RELEASE_APPROVAL_AUTHORITY permission on that specific environment, plus general access to the environment. Facets hides the Approve and Reject row actions from users who lack it, which is the usual reason someone reports that the actions are missing.

Configuring which releases get gated is a separate, blueprint-scoped permission. See Release Approval for the full permission matrix.

From the CLI

The Facets CLI acts on a gated release without opening the console, which is what you want from a pipeline or a script.

raptor approve release RELEASE_ID -p PROJECT -e ENVIRONMENT

raptor reject release RELEASE_ID -p PROJECT -e ENVIRONMENT

Both commands require the RELEASE_APPROVAL_AUTHORITY permission on the environment, the same permission the console checks.

Troubleshooting

Message	What it means	What to do
"Cannot approve a release that is not in PENDING_APPROVAL status"	The release left Pending Approval before your action reached the control plane.	Refresh the release history and check the current status of the release.
"Cannot reject a release that is not in PENDING APPROVAL status"	The same situation, for a reject action.	Refresh the release history and check the current status of the release.
"The last release should be in PENDING_APPROVAL state"	You tried to approve a release that is not the most recent one on the environment.	Approve the latest release. Older gated releases cannot be approved.
"Deployment does not belong to cluster: `<id>`"	The release belongs to a different environment than the one you acted from.	Open the environment that owns the release and act there.
"Cannot approve/decline/void release `<name>` (current phase: `<phase>`)"	On a CRD-driven release, the release moved to a phase where the action no longer applies.	Refresh and check the release phase. If the release already advanced past the gate, no action is needed.
"Cannot abort release in terminal status: `<status>`"	The release already finished, was rejected, or was aborted.	Nothing left to abort. Trigger a new release if you still need the change.
"Failed to approve release"	The approve request did not complete.	Retry. If it persists, confirm you still have access to the environment and the approval permission.
"Failed to reject release"	The reject request did not complete.	Retry. If it persists, confirm you still have access to the environment and the approval permission.

Configuring Release Approval - Define which releases require approval
Performing Releases - How releases run on an environment
Rolling Back a Release - Recover after a release that should not have shipped

Approving and Rejecting Releases

On this page