> 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/servicenow/gating.md).

# Release gating

Once ServiceNow is connected and [change requests](/flxbl/codev/governance/servicenow/change-requests.md) are set up, you can **gate** a release on one: codev opens a change request for the release and does not deploy to a gated environment until that change request is approved in ServiceNow.

This complements the human [approval gate](/flxbl/codev/governance/approval-gates.md) — an environment can require a person to approve in codev, a ServiceNow change request to be approved, or both.

## Turn the gate on

A ServiceNow connection on its own does nothing until you gate an environment on it. In your [project configuration](/flxbl/codev/governance/approval-gates.md#which-environments-require-approval), add `servicenow` to the environment's `gates`:

<figure><img src="/files/eQOLS0FiyNxtGmKGf3ON" alt="Setting the servicenow gate in the project configuration"><figcaption><p>Gates are set per environment in the project configuration.</p></figcaption></figure>

```json
{
  "releaseApprovalGates": {
    "environments": {
      "production":  { "gates": ["servicenow"] },
      "preproduction": { "gates": ["human", "servicenow"] }
    }
  }
}
```

* `["servicenow"]` — the release to that environment waits only on the ServiceNow change request.
* `["human", "servicenow"]` — the release waits on **both** a person approving in codev and the change request being approved.

Environments you do not list keep the default human approval and are not gated on ServiceNow.

## Change requests and gates are separate

codev treats two things independently:

* A **change request** is a record of the release in ServiceNow.
* A **gate** makes the release **wait** for that change request's approval before deploying.

You can have either without the other:

| You want to…                                               | Set                                                            | Change request                            | Release waits?                   |
| ---------------------------------------------------------- | -------------------------------------------------------------- | ----------------------------------------- | -------------------------------- |
| Record releases in ServiceNow, without blocking            | `serviceNowChangeRequest.enabled: true` (no `servicenow` gate) | Opened for the release                    | No                               |
| Block a release until the change request is approved       | `gates: ["servicenow"]` on the environment                     | Opened for the release                    | Yes — that environment waits     |
| Both — record everything, block the sensitive environments | Gate the environments that must wait, and set `enabled: true`  | Opened, covering every target environment | Only the gated environments wait |

A ServiceNow **gate always opens a change request** — you do not also need `enabled` for a gated environment. `enabled` is what adds a change request for releases and environments that are **not** gated, purely for traceability. See [how change requests are created](/flxbl/codev/governance/servicenow/change-requests.md#how-change-requests-are-created) for the `serviceNowChangeRequest` settings.

One change request covers the whole release. With `enabled` on, that single change request represents **every** target environment, while only the ServiceNow-gated ones actually wait for its approval — so you can record the full release in ServiceNow and still block just production.

## What happens during a release

When you request a release that includes a ServiceNow-gated environment:

1. **codev opens one change request** for the release, before any environment is deployed. Its description lists the packages changing in this release — each package, its previous and new version, and the linked work items.
2. **The change request number and link are posted** back to the release's source thread.
3. **Each ServiceNow-gated environment waits** for the change request to be approved. codev re-checks the change request on the poll interval until it reaches a decision.
4. **On approval, the release proceeds** to that environment. An environment gated on `["human", "servicenow"]` still requires its human approval as well.
5. **On rejection, cancellation, or timeout, the release is blocked** for that environment — nothing is deployed. If codev cannot reach ServiceNow to read the state, the gate **fails closed**: the release is blocked rather than allowed through unverified.

Environments that are not gated on ServiceNow are not held by the change request.

Every open, approval, rejection, and timeout is written to the [audit trail](/flxbl/codev/settings/audit.md), attributed to the ServiceNow gate.

## Related

* [Change requests](/flxbl/codev/governance/servicenow/change-requests.md) — connect ServiceNow and control how change requests are created
* [Approvals](/flxbl/codev/governance/approvals.md) — where approvals appear and how the human gate works
* [Configuring approval gates](/flxbl/codev/governance/approval-gates.md) — the `gates` list and human approvers
* [Audit trail](/flxbl/codev/settings/audit.md) — the record of every gate decision


---

# 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/servicenow/gating.md?ask=<question>&goal=<endgoal>
```

`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.
