> 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/sfp/validating-a-change/overview.md).

# Overview

**validate** command helps you to test ((deployability, apex tests, coverage) a change made to your configuration / code against a target org. This command is typically triggered as part of your Pull Request (PR) or Merge process, to ensure the correctness of configuration/code, before being merged into your **main** branch.<br>

{% hint style="warning" %}
sfp validates a change by deploying the changed packages into the target org. This is different from 'check only' deployment in other CI/CD solutions.
{% endhint %}

\
validate runs against a target org. To validate against a pooled scratch org, fetch one from the pool first (`sfp pool fetch`) and pass its username — the earlier `sfp validate pool` command, which fetched from the pool itself, has been removed.

`--releaseconfig` (also accepted as `--domain`) is **required** — validation is always scoped to one or more release configs.

```
// An example where validate is utilized against a target org 
sfp validate org -o ci \
                 -v devhub  \
                 --releaseconfig config/release-sales.yml \
                 --installdeps
```

```
// An example with branch references for intelligent synchronization
sfp validate org -o ci \
                 -v devhub \
                 --releaseconfig config/release-sales.yml \
                 --ref feature-branch \
                 --baseRef main
```

Both commands also require `--repository` and `--sfp-server-url`. Each defaults from an environment variable — `GITHUB_REPOSITORY` or `GITLAB_REPOSITORY`, and `SFP_SERVER_URL` — so they can be omitted in a pipeline that sets them.

\
\
The **validate org** command runs the following checks with the options to enable additional features such as dependency and impact analysis:

* Checks accuracy of metadata by deploying the metadata to an org
* Triggers Apex Tests
* Validates Apex Test Coverage of each package (default: 75%)
* Toggle between different modes for validation:
  * **Thorough** *(Default)* - Comprehensive validation with full deployments and all tests
  * **Individual** - Validates changed packages individually, ideal for PRs
* Automatically differentiates between:
  * Packages to synchronize (upstream changes)
  * Packages to validate (PR changes)
* Deploys only the components that changed, via [component checksum skip](/flxbl/sfp/building-artifacts/configuring-installation-behaviour-of-a-package/component-checksum-skip.md) — on by default, turned off for a run with `--no-checksum-skip`
* \[optional] - **AI-Assisted Error Analysis** - Intelligent error analysis and fix suggestions ([learn more](/flxbl/sfp/validating-a-change/ai-assisted-error-analysis.md))
* \[optional] - Validate dependencies between packages for changed components
* \[optional] - Restrict validation to changed packages with `--diffcheck` (off by default)
* \[optional] - Skip test execution entirely (`--skipTesting`), or skip only coverage validation (`--skipCoverage`)
* \[optional] - Keep validating the remaining packages after a package's tests fail (`--continueOnTestFailure`) — the run still fails at the end
* \[optional] - Write the validation report to a directory (`--markdownoutput`) or publish the run to the server (`--publish-results`)
* \[optional] - Embed apex tests inside the deploy with [`--deploywithtests`](/flxbl/sfp/validating-a-change/different-types-of-validation.md#combined-deploy-test-mode-deploywithtests) for faster validate (one round-trip; coverage read from the deploy response)
* \[optional] - Execute custom [validation scripts](/flxbl/sfp/validating-a-change/validation-scripts.md) for setup/cleanup workflows


---

# 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/sfp/validating-a-change/overview.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.