# Managing Release Candidates

Once you have release candidates on the [Release Candidates](https://docs.flxbl.io/flxbl/codev/ci-cd/overview-1) page, you can deploy them, test them, or use them as the basis for a hotfix. This page walks through each action.

## Release

<figure><img src="https://1175714801-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fh59zbGOCxlW2afrUhmcZ%2Fuploads%2Fgit-blob-64a6fefc313e4a91f55d3cde9fa09467480132e8%2Frc-release-dialog.png?alt=media" alt="Release dialog"><figcaption><p>Requesting a release for a selected candidate</p></figcaption></figure>

Use **Release** when you want to deploy a candidate to an environment — typically staging, UAT, or production.

### How it works

1. Click **Release** on the release candidate you want to promote.
2. The dialog shows you the release definition (domain and release name) and a list of **indicative work items** that will be included.
3. Work items are color-coded:
   * **Green** — this release will fully deploy the work item
   * **Orange** — only a partial deployment (other domains still need releasing for the work item to be complete)
   * **Grey** — the work item is linked to a release candidate in a different domain
4. If the release candidate has linked RCs in other domains, you can select or deselect them.
5. Confirm the target environment and click **Request Release**.

### What happens after you click Request Release

codev kicks off the release workflow:

1. A **dry run** validates the release — confirming which packages will be deployed and checking compatibility with the target environment.
2. The request enters an **approval gate**. Designated approvers on your team receive a notification and can review, approve, or reject from **Workflows > Pending Approvals**.
3. Once approved, codev **locks the target environment**, deploys the packages, and unlocks it.
4. The release appears on the [Releases](https://docs.flxbl.io/flxbl/codev/ci-cd/overview-2) page.

If your release candidate has multiple target environments, each environment gets its own approval gate and deploys independently. The whole process is tracked in **Workflows > Runs**.

{% hint style="info" %}
The approval gate ensures that nobody deploys to production without review. If your team wants to skip approval for certain environments (like a dev sandbox), that can be configured in your workflow settings.
{% endhint %}

## Get on Sandbox

<figure><img src="https://1175714801-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fh59zbGOCxlW2afrUhmcZ%2Fuploads%2Fgit-blob-e70d1f0240cee329125f991844bc41c524bcd846%2Frc-sandbox-dialog.png?alt=media" alt="Get on Sandbox dialog"><figcaption><p>Deploying a release candidate to a sandbox for testing</p></figcaption></figure>

Use **Get on Sandbox** when you want to test a release candidate before formally releasing it. This deploys directly — no approval gate, no waiting.

### How it works

1. Click the sandbox deploy action on the release candidate row.
2. Choose one or more target sandbox environments.
3. Select an environment profile (default: **DEV**).
4. Optionally enable **Force Install** to reinstall packages even if they are already present in the target org.
5. Click **Deploy to Sandbox**.

The deployment starts immediately and you can track it in **Workflows > Runs**.

## Patch

<figure><img src="https://1175714801-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fh59zbGOCxlW2afrUhmcZ%2Fuploads%2Fgit-blob-b8654041996ba6d480841b5e9666ace3f071e586%2Frc-patch-dialog.png?alt=media" alt="Patch dialog"><figcaption><p>Creating a patch branch from a release candidate</p></figcaption></figure>

Use **Patch** when you need a hotfix. This creates a new branch from the exact state of a release candidate, so you can fix a production issue without picking up all the other changes that have been merged since.

### How it works

1. Click the patch action on the release candidate row.
2. Confirm the source branch (default: **main**).
3. Click **Create Patch Branch**.

codev creates a new branch in your repository. It appears as a separate tab on the Release Candidates page. Developers push their fix to this branch, and when the fix is merged, codev builds a new release candidate scoped to the patch — which can then be released through the normal flow.

## Release candidate lifecycle

Release candidates move through these statuses as your team works with them:

* **Active** — ready to be released or tested
* **Released** — deployed to at least one environment
* **Superseded** — a newer release candidate exists for the same domain (this one is still deployable if needed)

{% hint style="warning" %}
You can still release a superseded RC. The status is informational — it tells you a newer version is available, but it does not block you from deploying an older one if needed.
{% endhint %}

## Related

* [Release Candidates: Concepts and page overview](https://docs.flxbl.io/flxbl/codev/ci-cd/overview-1)
* [Builds: How packages are built](https://docs.flxbl.io/flxbl/codev/ci-cd/overview)
* [Releases: What is deployed where](https://docs.flxbl.io/flxbl/codev/ci-cd/overview-2)