> 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/environments/environments.md). # Environments An environment in codev is a Salesforce org that codev deploys to and tracks — a sandbox or a production org, registered to your project. The Environments page is where you see them all, grouped by how they are used, with each one's status, the branch it tracks, and what has been deployed to it.
The Environments page

The Environments page — environments grouped by category, each with its status, branch, and recent deploys

## Environments and orgs A Salesforce **org** is the platform itself — a sandbox, a scratch org, or your production org. codev can connect to many orgs, and you register and manage them under **Ops**. An **environment** is a registered org that you have given a role in your project's delivery. Making an org an environment is what lets codev deploy to it automatically, track which release is on it, gate access to it with a [lock](/flxbl/codev/environments/access-and-locks.md), and report its health. An org that is only registered is just somewhere codev can authenticate; an environment is an org codev actively manages as part of your pipeline. One org backs exactly one environment per project, identified by its username (for example `cicduser@acme.com.qa`). Orgs handed out from a [pool](/flxbl/codev/pools/overview.md) are different again — they are created and destroyed on demand rather than kept as standing environments. ## Categories Environments are grouped into categories that reflect their role in delivery: * **Test** — receives builds automatically when code is merged, for early validation. See [Builds](/flxbl/codev/ci-cd/overview.md). * **Snapshot** — a known-good copy of a branch, kept current as a source for sandbox pools and for hotfix validation. * **Release** — the production-like environments a release is promoted to: staging, UAT, production. Releases reach these through the [release flow](/flxbl/codev/ci-cd/managing-release-candidates.md#release) with an approval gate, not on every merge. The counters at the top — **Environments**, **Active**, **Locked** — summarise the project, and the **Branch** filter narrows the list to environments tracking a particular branch. ## What each environment tracks Each environment card shows the **branch** it is associated with, whether it is **Active**, whether it is currently **In use** (locked), the Salesforce org it points at, and its most recent deploys. The branch association is what decides where a build is deployed: when code is merged, codev deploys the result to the Test and Snapshot environments that track that branch. The branch can be an exact name or a glob pattern such as `release/*` — see [Deploying to environments by branch](/flxbl/codev/ci-cd/overview.md#deploying-to-environments-by-branch). Use **Create**, or the **+** on a category, to add an environment; **Deactivate** takes one out of rotation without deleting it. ## The environment detail page
An environment's detail page

An environment's detail page — current release, tests, artifacts, health, and its access lock

Opening an environment shows the full picture of that org: the **current release** deployed to it, the latest **tests** and coverage, the **artifacts** installed, a **health** summary, and its **locks**. The sections down the page cover **Access & Locks**, **Artifacts**, **Tests**, **Browser Sessions**, and **Settings**, and **Open in Salesforce** jumps straight into the org. Exclusive access and the lock shown here are covered in [Access and locks](/flxbl/codev/environments/access-and-locks.md). ## Component checksum skip When codev deploys a changed source or diff package, it deploys only the components whose source changed since the version already on the org, rather than the whole package. This is **on by default** for every environment. An environment's **Settings** carry a **Component Checksum Skip** switch. Turn it off to force full deploys to that environment — for example, to keep production deploying every component while sandboxes deploy only what changed. The same switch appears when you create an environment.
The Component Checksum Skip switch in an environment's settings

The Component Checksum Skip switch in an environment's settings. Turning it off forces full deploys to that environment.

A project-wide master switch in **project settings** turns the optimisation off across every environment and workflow at once — the widest of the controls. Open the project's configuration editor and set **Checksum Skip** under **Configuration**.
The Checksum Skip master switch in the project settings configuration editor

The Checksum Skip master switch in project settings. Set to false, it turns the optimisation off across every environment and workflow.

For what is skipped, the component types always deployed, and how it falls back, see [sfp: Component checksum skip](https://docs.flxbl.io/flxbl/sfp/building-artifacts/configuring-installation-behaviour-of-a-package/component-checksum-skip). ## Related The Environments area also links to a few related views: * **Pools** — pools of ephemeral sandboxes and scratch orgs. See [Pools](/flxbl/codev/pools/overview.md). * [**Deployment Matrix**](/flxbl/codev/environments/deployment-matrix.md) — a grid of which package version is on which environment. * [**Org Limits**](/flxbl/codev/observe/org-limits.md) — Salesforce governor and storage usage per org. * [**Environment Drift**](/flxbl/codev/environments/environment-drift.md) — detect when an org has drifted from what codev believes is deployed. --- # 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/environments/environments.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.