> 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/inspect/change-validation.md).

# Change Validation

<figure><img src="/files/iho9KqMOJe2g7nJ8tUIF" 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](/flxbl/codev/inspect/review-environments.md) 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="/files/6FaAoDjAnoZsG3jx9QPB" 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

## Tracking validation runs

<figure><img src="/files/UBNBhoo2jP2LDyvb47De" alt="Change Validation showing run statuses"><figcaption><p>Validation runs with Succeeded, Cancelled, and Skipped statuses — the skipped run shows the webhook filter that excluded it</p></figcaption></figure>

The Change Validation page tracks every PR validation from the moment it is triggered, not only runs that finished and published results. A run that is still in progress, was skipped, or failed before producing a report still appears on the page, so you can always answer "did validation run for my PR, and where is it now?"

Each run shows one of five statuses:

| Status    | Meaning                                                                                   |
| --------- | ----------------------------------------------------------------------------------------- |
| Pending   | Validation has been dispatched and is queued or running                                   |
| Succeeded | The validation workflow completed                                                         |
| Failed    | The validation workflow failed before publishing results                                  |
| Cancelled | The run was cancelled — for example, the PR was closed while validation was still running |
| Skipped   | A webhook filter excluded validation for this PR; the filter reason is shown on the row   |

Clicking a run that has not published results yet opens the workflow run, where you can follow its logs and progress. Once results are published, the row opens the full validation detail instead.

### Latest run only

By default the page shows only the most recent run for each PR. Turn off **Latest run only** in the action row to see the full run history, including earlier commits on the same PR.

## 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](/flxbl/codev/inspect/review-environments.md).
2. **Review environment rules** mapping your branches and domains to the target — see [Review Environments](/flxbl/codev/inspect/review-environments.md)
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)


---

# 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/inspect/change-validation.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.