> 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/ci-cd/managing-release-candidates.md).

# Managing Release Candidates

Once you have release candidates on the [Release Candidates](/flxbl/codev/ci-cd/overview-1.md) 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="/files/rQ4O6Hh0PYyjqZ9nDvOV" 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](/flxbl/codev/ci-cd/overview-2.md) 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="/files/lWQj51eDwBKCPku35dWW" 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="/files/3EGJActRLIqLTefgsygL" 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.

## Unbundle

Use **Unbundle** to remove specific commits from a release candidate — codev rebuilds the candidate without them, keeping everything else. Because it replays your other changes and resolves any conflicts automatically, it has important limitations and is best used on a recent candidate.

See the dedicated [Unbundle](/flxbl/codev/ci-cd/managing-release-candidates/unbundle.md) page for how it works, conflict resolution, and when a revert PR is the better choice.

## 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](/flxbl/codev/ci-cd/overview-1.md)
* [Builds: How packages are built](/flxbl/codev/ci-cd/overview.md)
* [Releases: What is deployed where](/flxbl/codev/ci-cd/overview-2.md)


---

# 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/ci-cd/managing-release-candidates.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.
