---
name: devsecops-devsecops-approve-cr
title: Approval of Change Requests
description: A change request can be approved manually or automatically (provided all required compliance checks are passing and deployment readiness is `true`).
last-updated: 2026-05-11
---

> ## Documentation Index
> The table of contents for this documentation set is at https://cloud.ibm.com/docs/devsecops?format=markdown
> The index for all IBM Cloud docs is at: https://cloud.ibm.com/docs/llms.txt
> Use these files to discover more information as needed.

# Approval of Change Requests
{: #cd-devsecops-approve-cr}

A change request can be approved manually or automatically (provided all required compliance checks are passing and deployment readiness is `true`).
{: shortdesc}

By default, standard change requests are created and if all of the required compliance checks pass, the deployment readiness is set to `true`. When a change request is of the standard type and the deployment readiness is set to `true`, it is automatically approved. 

If one or more compliance checks fail, deployment readiness is set to `false`, the continuous deployment pipeline breaks, and the deployment stops because of the unapproved change request.

You can still proceed with deployment in case of an emergency by adding an emergency label to the promotion pull request. 

You can also provide a manually pre-approved change request that the deployment pipeline can utilise (with label `status_approved`) In Gitlab 

Take either of the following approaches:

## Option 1: Adding an emergency label to promotion PR
{: #cd-devsecops-emergency-label}

If you need to deploy emergency changes immediately, you can use emergency mode. When you promote a change, add an `emergency` label to the promotion pull request to prompt the continuous deployment pipeline to create an emergency change request. Emergency change requests allow deployment to continue even if the approval is missing. For more information on the emergency flow, see [Automating change management](https://cloud.ibm.com/docs/devsecops?topic=devsecops-cd-devsecops-automate-changemgmt&format=markdown).

Use the emergency mode sparingly and with caution.
{:  important}

You can set the value of the emergency label (`default: EMERGENCY`) that the continuous deployment  pipeline looks for on the promotion pull request when you create the toolchain.

 ![Emergency label](images/emergency-label-at-creation.png){: caption="Emergency label" caption-side="bottom"}

You can also change the value of the emergency label from the pipeline's environment variables:

 ![Emergency label variable](images/emergency-label-env.png){: caption="Emergency label variable" caption-side="bottom"}

This label indicated by the value set by the `emergency-label` environment property, needs to be added to the promotion pull request to indicate to the CD pipeline that the change is an emergency change. 

When the deployment completes, the emergency change request is set to the `Review` state, which indicates that it requires the assigned approvers to review and approve it retroactively.

There is no emergency flow on the CI pipeline side. However, setting a CI pipeline/trigger property `skip-inventory-update-on-failure` to an empty value or `0` will allow the inventory repository to be updated, even if issues are detected in the CI pipeline run. With this updated inventory, an emergency change can be activated.
{: note}

## Option 2: Providing a manually pre-approved CR
{: #cd-devsecops-manual-preapprove}

If the deployment is not an emergency, you can wait for the change request to be manually approved. Use the existing, manually pre-approved change request number that is set in the continuous deployment pipeline environment variables. The default value is `notAvailable`, which means the continuous deployment pipeline creates a new change request.

![Manually pre-approved CR](images/pre-approved-cr-label.png){: caption="Manually pre-approved CR" caption-side="bottom"}