> For the complete documentation index, see [llms.txt](https://docs.flxbl.io/flxbl/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.flxbl.io/flxbl/codev/governance/approvals.md).
# Approvals
Some actions in codev do not run the moment you request them. A release to a shared environment, a rollback, and a handful of other sensitive operations pause at an **approval gate** — codev suspends the work, records a pending approval, and waits for an authorized person to approve or reject it. Nothing is deployed until someone does.
This page covers what an approval gate is, where approvals appear, and how to resolve one. To decide which environments require approval and who may approve, see [Configuring approval gates](/flxbl/codev/governance/approval-gates.md). To gate a release on a ServiceNow change request instead of (or in addition to) a person, see [ServiceNow release gating](/flxbl/codev/governance/servicenow/gating.md).
## What is gated
An approval gate is inserted into an action before it makes any change. The following actions pause for approval:
* **Releasing a release candidate** to an environment — each target environment has its own approval.
* **Rolling back** a release to an earlier one.
* **Unbundling** a release candidate.
* **Syncing a pull request to a shared environment** — codev posts the approval request on the pull request.
* **Sandbox operations** — creating, deleting, or refreshing a sandbox.
* [**Requesting elevated access**](/flxbl/codev/governance/elevated-access.md) for a user in a production org.
A release that targets three environments produces three separate approvals. Approving the deployment to staging does not approve the one to production.
## Where approvals appear
The Pending Approvals page lists every request awaiting a decision.
A pending approval surfaces in several places, all backed by the same list:
* **Pending Approvals page** (**Workflows > Pending Approvals**) — the full list of requests, with the requester, the approvers, when it was requested, when it expires, the linked work item, and its status. This is where you review and resolve requests.
* **My Approvals** — a **ClipboardCheck** item in the sidebar with a count badge for requests you can act on. It opens a popover that lists your pending requests with inline **Approve** and **Reject** buttons.
* **Home** — a **Pending approvals** panel and widget show a count and the oldest waiting requests, and link through to the full list.
When a request is driven from a source control issue, pull request, or work item, codev also posts a notification in that thread and mentions the people who can approve it.
## Approving or rejecting
On the Pending Approvals page (or the My Approvals popover), each request you are authorized to resolve shows an **Approve** and a **Reject** action:
* **Approve** — codev resumes the action. For a release, it locks the target environment, deploys, and unlocks it; the release then appears on the [Releases](/flxbl/codev/ci-cd/overview-3.md) page.
* **Reject** — codev cancels the action. A release candidate that was rejected stays available for a future attempt.
If you are not one of the request's approvers, the actions are hidden and the row shows a dash. The actions are also disabled once a request is no longer pending.
### Approving from the source thread
When a release is driven from a source control issue or work item, approvers can respond in the thread instead of opening codev:
```
/codev approve
/codev reject --reason "Change freeze until Monday"
```
`/codev approve` without a target approves the next pending environment. To approve a specific environment, name it: `/codev approve production`.
## Who can approve
By default, the **owners** of a project are the approvers. A project can also name explicit approvers per environment — see [Configuring approval gates](/flxbl/codev/governance/approval-gates.md#who-can-approve). Only a request's approvers can resolve it, whether they act in codev or in the source thread.
{% hint style="info" %}
By default the person who requested a release can also approve it. To require that the requester and the approver are different people, enable **segregation of duties** — see [Separation of duties](/flxbl/codev/governance/approval-gates.md#separation-of-duties).
{% endhint %}
## Expiry
A request that nobody resolves **expires** and does not run. The default window is **60 hours**; a project can set its own timeout (up to 168 hours). ServiceNow gates use their own, longer window. Once a request has expired, the action is abandoned — request it again to retry.
## Audit trail
Every approval request and decision is recorded in an append-only audit trail: who requested, who approved or rejected, when, and for which release candidate and environment. Records cannot be edited or deleted after the fact, and ServiceNow change-request decisions are recorded in the same trail. You review and export it under **Settings > Audit** — see [Audit trail](/flxbl/codev/settings/audit.md).
## Related
* [Configuring approval gates](/flxbl/codev/governance/approval-gates.md) — which environments require approval, who approves, timeout, and separation of duties
* [ServiceNow release gating](/flxbl/codev/governance/servicenow/gating.md) — gate a release on a ServiceNow change request
* [Audit trail](/flxbl/codev/settings/audit.md) — the record of every approval decision
* [Workflows](/flxbl/codev/flows/overview.md) — tracking runs and the Pending Approvals page
* [Rolling back a release](/flxbl/codev/ci-cd/rollback.md) — an action that pauses at an approval gate
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.flxbl.io/flxbl/codev/governance/approvals.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.