# Change Validation

<figure><img src="https://1175714801-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fh59zbGOCxlW2afrUhmcZ%2Fuploads%2Fgit-blob-89cd7ec8f0ae8a181e5c1ecc19781fd4f78a6d0b%2Finspect-change-validation-runs.png?alt=media" alt="Change Validation page"><figcaption><p>Change Validation showing PR validation results with domain, mode, deployment counts, test results, and status</p></figcaption></figure>

Change Validation goes beyond static analysis — it actually deploys your changed packages to a real Salesforce org and runs Apex tests against them. This tells you whether the deployment will succeed before you merge.

Unlike tools that use "check-only" deployments, codev performs a real deployment to a review environment. This catches issues that check-only deployments miss, like data-dependent failures and post-deployment script errors.

## What happens when a PR is validated

When a PR is opened or updated, codev's validation workflow:

1. **Detects impacted domains** — analyzes the PR diff to determine which release configs (domains) have changed packages. Only affected domains are validated.
2. **Allocates a review environment** — for each impacted domain, codev matches the PR to a pool using [review environment rules](https://docs.flxbl.io/flxbl/codev/inspect/review-environments) and acquires exclusive access to an org from that pool.
3. **Deploys the changed packages** — clones the repository at the merge ref, builds the impacted packages, and deploys them to the review org. Dependencies are installed if needed.
4. **Runs Apex tests** — triggers tests for the deployed packages and validates code coverage against the configured threshold (default: 75%).
5. **Reports results** — publishes deployment and test results to the server, updates the PR check run in GitHub, and applies labels (`validation-succeeded`, `validation-failed`, etc.).

The review environment is released after validation completes, making it available for the next PR.

## Validation modes

codev supports two validation modes, configured per branch pattern:

### Thorough mode

The default for PRs targeting `main`. Deploys all packages in the domain (not just the changed ones) and runs comprehensive tests. This catches integration issues between packages.

### Individual mode

Used for PRs targeting release branches. Validates only the changed packages individually, which is faster and appropriate when you need to verify a specific fix without rebuilding the full domain.

## Viewing validation results

<figure><img src="https://1175714801-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fh59zbGOCxlW2afrUhmcZ%2Fuploads%2Fgit-blob-115999a6c4962baa13742ae40a75501603e87222%2Finspect-change-validation-results.png?alt=media" alt="Validation Results detail"><figcaption><p>Validation detail showing deployment context, target org details, packages validated, and deployment errors</p></figcaption></figure>

Click any PR row to see the full validation detail. The left sidebar shows:

* **PR Info** — branch, target, commit, when validated
* **Validation Details** — mode (thorough/individual), domain, target org, pool used, duration
* **Results Summary** — deployed/failed/scheduled counts, test pass rate

The main content area shows the validation report with:

* **Validation Context** — the release and target org used
* **Org Information** — org ID, username, and a secure login link
* **Packages Validated** — which packages were deployed and whether they succeeded
* **Deployment Errors** — if anything failed, the specific errors with component details

## Configuring validation

Click **Workflow Settings** on the Change Validation page to enable or disable the PR validation workflow.

Validation behavior can be customized per branch pattern through project settings:

* **Validation mode** — `thorough` or `individual`
* **Skip testing** — skip Apex test execution (use with caution)
* **Coverage percent** — minimum code coverage threshold (default: 75%)
* **Diff check** — only build and validate changed packages
* **Install dependencies** — install package dependencies before validation

For example, you might run thorough validation with testing on PRs to `main`, but individual validation without testing on feature branches for faster feedback.

### Per-package controls

Individual packages can override validation behavior through `sfdx-project.json` attributes:

* **`skipTesting`** — skip Apex tests for this package
* **`skipCoverageValidation`** — skip coverage checks for this package
* **`testSynchronous`** — run tests serially instead of in parallel (useful for tests with DML conflicts)
* **`alwaysSync`** — always include this package when any other package in the same domain is validated
* **`checkOnlyAgainst`** — validate this package using check-only deployment against specific named orgs instead of pool environments

For detailed reference on these attributes, see [sfp: Controlling validation attributes](https://docs.flxbl.io/flxbl/sfp/validating-a-change/controlling-validation-attributes-of-a-package).

## Prerequisites

For change validation to work, you need:

1. **A review environment configured** — this can be a dedicated Salesforce org (simplest to get started), a sandbox pool, or a scratch org pool. See [Review Environments](https://docs.flxbl.io/flxbl/codev/inspect/review-environments).
2. **Review environment rules** mapping your branches and domains to the target — see [Review Environments](https://docs.flxbl.io/flxbl/codev/inspect/review-environments)
3. **The PR validation workflow enabled** — toggle in Workflow Settings

## Further reading

* [sfp: Validation overview](https://docs.flxbl.io/flxbl/sfp/validating-a-change/overview)
* [sfp: Validation modes](https://docs.flxbl.io/flxbl/sfp/validating-a-change/different-types-of-validation)
* [sfp: Validation scripts](https://docs.flxbl.io/flxbl/sfp/validating-a-change/validation-scripts)