Change Validation

Change Validation showing PR validation results with domain, mode, deployment counts, test results, and status

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 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

Validation detail showing deployment context, target org details, packages validated, and deployment errors

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.

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.

2. Review environment rules mapping your branches and domains to the target — see Review Environments

3. The PR validation workflow enabled — toggle in Workflow Settings

Further reading

• sfp: Validation overview

• sfp: Validation modes

• sfp: Validation scripts