# 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 can either utilise a scratch org from a tagged pool prepared earlier using the [prepare](https://github.com/flxbl-io/docs-sfp/blob/main/validating-a-change/broken-reference/README.md)[ ](https://github.com/dxatscale/dxatscale-guide/blob/april-22/projects/sfpowerscripts/orchestrator/broken-reference/README.md)command or one could use the a target org for its purpose

```
// An example where validate is utilized against a pool 
// of earlier prepared scratch orgs with label review
 
sfp validate pool  -p review \
                   -v devhub  \
                   --diffcheck
```

```
// An example where validate is utilized against a target org 
sfp validate org -o ci \
                 -v devhub  \
                 --installdeps
```

```
// An example with branch references for intelligent synchronization
sfp validate org -o ci \
                 -v devhub \
                 --ref feature-branch \
                 --baseRef main
```

```
// An example with release config for domain-limited validation
sfp validate org -o ci \
                 -v devhub \
                 --releaseconfig config/release-sales.yml
```

\
\
**validate pool / 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)
* \[optional] - **AI-Assisted Error Analysis** - Intelligent error analysis and fix suggestions ([learn more](/flxbl/sfp/validating-a-change/ai-assisted-error-analysis.md))
* \[optional] - Limit validation scope using release configurations (`--releaseconfig`)
* \[optional] - Validate dependencies between packages for changed components
* \[optional] - Disable diff check while validating (`--diffcheck`)
* \[optional] - Disable parallel testing of apex tests (`--disableparalleltesting`)
* \[optional] - Skip test execution entirely (`--skipTesting`)
* \[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: 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:

```
GET https://docs.flxbl.io/flxbl/sfp/validating-a-change/overview.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.