# Review Environments

<figure><img src="https://1175714801-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fh59zbGOCxlW2afrUhmcZ%2Fuploads%2Fgit-blob-c59e6c4b8ee3e9c88cb5ab9c0267ca74d4ed21f7%2Finspect-review-envs-.png?alt=media" alt="Review Environments page"><figcaption><p>Review Environments showing assignment rules that map branch patterns and domains to targets</p></figcaption></figure>

Review environments define where [Change Validation](https://docs.flxbl.io/flxbl/codev/inspect/change-validation) deploys your PR changes. They connect your pull requests to Salesforce environments — automatically assigning the right org for each PR based on rules you configure.

Without review environment rules, change validation would not know where to deploy. With them, every PR automatically gets an environment matched to its branch and domain.

## Choosing a setup

<figure><img src="https://1175714801-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fh59zbGOCxlW2afrUhmcZ%2Fuploads%2Fgit-blob-3ba96a2d6662677cb1f774006144abe7d288733f%2Finspect-onboarding.png?alt=media" alt="Review Environment setup options"><figcaption><p>Three ways to set up review environments — dedicated environment, sandbox pool, or scratch org pool</p></figcaption></figure>

codev offers three approaches, depending on your team size and needs:

### Dedicated environment

**Easiest to get started.** Use a single Salesforce org that is shared across PRs. Each PR deploys its changes on top of the previous ones. This is the quickest way to get validation running — all you need is an existing org.

The tradeoff is that PRs share the same org, so changes from one PR may affect validation of another. For small teams or projects with limited cross-package dependencies, this works well.

### Sandbox pool

**Recommended for teams.** Each PR gets its own isolated sandbox from a pre-provisioned [pool](https://docs.flxbl.io/flxbl/codev/pools/overview). There is no cross-contamination between PRs — each validation runs in a clean environment that is automatically returned to the pool when done.

### Scratch org pool

**Best for scale.** Each PR gets a lightweight, disposable scratch org from a [pool](https://docs.flxbl.io/flxbl/codev/pools/overview). Fresh orgs are provisioned with all packages and dependencies pre-installed, providing maximum isolation and consistent feedback for every PR.

## How assignment rules work

An assignment rule maps a combination of branch pattern and domain pattern to a target — either a pool or a dedicated Salesforce org.

For example, a rule might say: "For PRs targeting `main`, across all domains, use the pool `dev-pool-so`." Another rule might say: "For PRs targeting `release/*`, for the `service` domain, use the dedicated org `staging`."

When change validation runs, codev evaluates the PR's target branch and impacted domains against these rules and allocates the matching environment.

## Creating assignment rules

<figure><img src="https://1175714801-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fh59zbGOCxlW2afrUhmcZ%2Fuploads%2Fgit-blob-ee67e5168623aa479f98be556115d41ffd8b357c%2Finspect-setup-review-envs.png?alt=media" alt="Set Up Review Environment dialog"><figcaption><p>Setting up a review environment rule — choose target type, pool, branch pattern, domain patterns, and priority</p></figcaption></figure>

Click **Add Configuration** on the Review Environments page. The setup dialog asks for:

* **Target Type** — choose **Pool** (sandbox or scratch org pool) or **Dedicated Environment** (a specific Salesforce org)
* **Pool** — if using a pool, select which one. The pool must already be created in [Pools Management](https://docs.flxbl.io/flxbl/codev/pools/overview)
* **Branch Pattern** — which base branches this rule applies to (e.g., `main`, `release/*`, `feature/*`). Use `*` for single-level wildcard, `**` for multi-level
* **Domain Patterns** — which domains this rule applies to. Leave empty to match all domains. Use comma-separated values for multiple (e.g., `core, sales-*`)
* **Priority** — when multiple rules match, the highest priority wins
* **Description** — optional notes about what this rule is for

## Viewing active assignments

Switch to the **Active Assignments** tab to see which environments are currently assigned to PRs. This shows the pool, branch, domain, and how long the assignment has been active.

## How review environments connect to validation

The full flow:

1. A PR is opened or updated
2. Change Validation detects impacted domains
3. For each domain, codev evaluates the review environment rules against the PR's target branch and domain name
4. The matching rule determines whether to use a pool or dedicated environment
5. codev acquires exclusive access (pool: fetch + acquire lock; dedicated: lock with access token)
6. Validation deploys and tests against the environment
7. codev releases access when validation completes

This happens automatically — developers do not need to think about which environment to use.

## Getting started

1. **Choose your approach** — dedicated environment (quickest), sandbox pool, or scratch org pool
2. If using a pool, **create it first** in [Pools Management](https://docs.flxbl.io/flxbl/codev/pools/overview) with available instances
3. **Create an assignment rule** on this page mapping your main branch to the target
4. **Enable the PR validation workflow** in Change Validation > Workflow Settings
5. Open a PR — validation will automatically allocate an environment and run