Click Deploy Validation: How to Run a Check-Only Deployment and Quick Deploy

TL;DR: A click deploy validation is a check-only deployment: Salesforce runs your package and its Apex tests against the target org without saving anything. If it passes with tests run, you get a job ID you can Quick Deploy within 10 days, which skips the test run during your release window. Validate early, then release without waiting on tests twice.

What is a click deploy validation?

Validating a deployment means running it in check-only mode. Salesforce's Trailhead release module describes it as running tests to validate the deployment without saving the components in the target org. Nothing changes in the org. You learn whether the package would deploy and whether the tests pass. In a point-and-click tool it is usually a Validate button next to Deploy.

Trailhead also defines what success means: all Apex tests passed, and the tests cover at least 75% of the code being deployed.

Why validate before you click deploy?

• Failures surface early. Missing dependencies, compile errors and test failures show up as a result to fix, not as a broken release.
• The slow part leaves the release window. Quick Deploy reuses the validation's test results, so the production step does not re-run Apex tests.
• Approvers get evidence. A passing validation is something a reviewer can check before sign-off, which is the first gate in our click deploy checklist.

How do you run a validation and Quick Deploy?

1. Build the package from a source you trust. An org comparison works, but a branch is easier to review. See click deploy from Git for that route.
2. Choose a test level that actually runs tests. The next section covers which ones qualify.
3. Run Validate. From the CLI that is sf project deploy validate. Gearset and Salto both offer validation inside their deployment flows, and Salto asks which tests to run as part of it.
4. Read the result and re-validate after every fix. A validation only vouches for the exact package it checked.
5. Keep the job ID. Trailhead notes that the validation returns a job ID you reference in the quick deploy.
6. Quick Deploy inside the window. Use the Quick Deploy button on the Deployment Status page in Setup (it only appears for qualifying validations), sf project deploy quick with the job ID, or the Metadata API call deployRecentValidation().
7. Have a way back. A clean validation lowers the risk but does not remove it, so plan your click deploy rollback before you release.

Which test level should you validate with?

• RunLocalTests: runs the org's local tests. Trailhead's release example uses it for both the staging and production validations.
• RunSpecifiedTests: runs only the classes you name. Faster, but those tests must carry the coverage for what you deploy, which Apex Anvil notes means 75% for each deployed class and trigger.
• RunAllTestsInOrg: runs every test in the org, including managed package tests. The slowest option.
• NoTestRun: not compatible with Quick Deploy, because there are no test results to reuse.
• RunRelevantTests: introduced as a beta in Spring '26. Salesforce selects tests linked to the Apex in the payload, but Bob Buzzard found it only follows direct dependencies, so pilot it outside production first.

What invalidates a validation?

• Age. The job ID is valid for 10 days. After that, validate again.
• Another deployment. Trailhead's 10-day window holds only if nobody deploys to that org or makes major changes to it in between.
• Drift you did not see. Gearset's documentation warns that org changes made after a package was built are not accounted for and could be overwritten on deploy.
• No tests. A validation run with NoTestRun cannot be quick deployed.

The practical rule: validate as close to the release as your test run time allows, and freeze other deployments to that org until you ship.

Who is Tekunda, and how does Serpent handle validation?

Tekunda is a Salesforce consulting and product firm and the company behind Serpent, the Salesforce DevOps platform it launched in 2024. In Serpent, validation is a fixed step rather than an optional button: the deploy flow runs configure, select files, validate and deploy. The validate step is a dry run against the target org. A clean result continues automatically and a failure stops there. Serpent also deploys only the components a work item changed, which keeps validations small. If you are comparing it with how ClickDeploy works and what it costs, the Scale plan is $699 per company per month with unlimited users; see the pricing page. More step-by-step guides live in SF Guides.

FAQ

Does a validation change anything in the target org?

No. It is a check-only deployment, so no components are saved.

How long can I wait before using Quick Deploy?

Up to 10 days, provided no other deployment or major change hits that org in between.

Can I Quick Deploy a validation that ran no tests?

No. Quick Deploy reuses test results, so the validation must run tests and pass with the required coverage.

Does Quick Deploy run Apex tests again?

No. It relies on the tests from the validation, which is why it finishes faster than a standard deploy.