A validation-only deployment runs every step of a real Salesforce deployment except the final commit. Metadata gets compiled, Apex tests run, dependencies get checked, and the org tells you exactly what would have happened if you had actually deployed. Nothing gets saved. It is the closest thing Salesforce gives you to a dry run, and most teams either overuse it out of anxiety or ignore it entirely and pay for that later.
The technical term Salesforce uses is check-only deployment, set via the checkOnly flag in the Metadata API or the checkbox in Setup's Deployment Status page. Whatever you call it, the mechanism is identical to a production deploy right up until the point where changes would be written to the database. That last step gets skipped, and the org rolls back to its exact prior state.
What a Validation-Only Deployment Actually Tests
Run a check-only deployment and Salesforce compiles every class, trigger, and Visual Force page in the package against the target org's current metadata. It executes all required Apex tests and calculates code coverage the same way a live deployment would. If your org requires 75% coverage and the incoming package would drop you below that, validation catches it before anything ships.
It also resolves metadata dependencies the same way production deployment does. A flow that references a field which does not exist in the target org will fail validation exactly as it would fail a real deploy. So will a permission set referencing a missing custom object, or a report type pointing at a field that got renamed three sprints ago. The failure message is identical either way.
What changes is persistence. Successful validations get a Request ID that Salesforce holds onto for 10 days. Deploy within that window using deployRecentValidation and Salesforce skips re-running the tests, because it already has proof they passed. That is the entire point of quick deploy, and it only exists because check-only mode ran first.
When Check-Only Mode Actually Earns Its Keep
Use validation-only deployments before any production release that includes Apex changes with meaningful test surface. If a package touches 40 classes and you are not sure every dependent trigger still compiles, validating first tells you in minutes rather than mid-deployment at 2am during a change window.
It is also the right move before a first deployment into a new sandbox or a freshly refreshed one. Refreshes wipe local customizations and configuration drift that existed only in that sandbox. Validating catches missing dependencies from that drift before you burn a deployment slot on a failure you could have seen coming.
Release managers coordinating a multi-team deployment window get real value here too. Running validation an hour before the actual window confirms the package is deployable right now, not deployable two days ago when someone last tested it. Org state changes constantly. A stale validation is close to worthless, which is why the 10-day quick deploy window exists as a ceiling, not a guarantee.
Where Validation-Only Falls Short
Validation does not touch data. It will not tell you that a new required field breaks an integration pushing records through the API, because that failure only shows up when real records hit real validation rules under real load. Metadata correctness and business process correctness are different problems, and check-only mode only solves the first one.
It also will not catch governor limit issues that depend on data volume. A trigger that runs fine against a sandbox with 200 test records can hit a SOQL limit against a production org with two million. Validation runs your test classes, but if those tests use small fabricated datasets, you learn nothing about production-scale behavior.
I have watched teams treat a clean validation as a green light to skip UAT entirely. That is a mistake. Validation confirms the package is structurally deployable. It says nothing about whether the new approval process actually approves the right records for the right reasons. Those are separate checks and both matter.
Validation-Only Deployments Inside a CI/CD Pipeline
In a pipeline, check-only mode belongs on every pull request, not just before major releases. A PR that changes metadata should trigger an automatic validation against the target sandbox or production org as a required status check. Reviewers should not merge until that validation passes, full stop.
This catches the dependency drift problem early, while the change is still small and the author still remembers what they touched. Waiting until release day to validate a batch of twelve merged PRs means untangling which of the twelve broke the build, and that is a miserable way to spend an afternoon.
| Pipeline Stage | Validation Approach | Why It Matters |
|---|---|---|
| Pull request | Auto-validate against target sandbox | Catches dependency breaks per change, not per batch |
| Pre-release | Full validation against production | Confirms deployability in current org state |
| Post-merge | Quick deploy from validation Request ID | Skips redundant test runs, saves deployment time |
DeployEzee runs this validation step automatically as part of its metadata dependency resolution, flagging missing references before you ever queue a deployment. That means the failures show up on your screen during planning, not in a deployment log at the worst possible moment.
Common Mistakes Teams Make With Check-Only Deploys
The biggest one is validating against the wrong org. Validating a package against a sandbox that has not been refreshed in eight months tells you almost nothing about whether it will deploy cleanly to production, because the two orgs have drifted apart. Match your validation target to your actual deployment target, every time.
The second mistake is ignoring the 10-day expiration on quick deploy eligibility. Teams validate a package, get pulled into other work, and come back three weeks later assuming they can skip test execution. They cannot. Salesforce forces a full re-run, tests and all, and the schedule slips.
The third is treating a passing validation as proof of zero risk. It proves zero metadata risk. Data risk, integration risk, and user-adoption risk are still fully in play and need their own verification steps outside the deployment tool entirely.
Building Validation Into Your Standard Deployment Process
The teams with the fewest failed production deployments are not the ones with the most senior admins. They are the ones who made validation a mandatory, unskippable gate rather than an optional courtesy step someone remembers to run when they are feeling cautious.
That means writing it into the actual release checklist: no deployment request gets scheduled without an attached Request ID from a validation run against the correct target org, completed within the current 10-day window. No exceptions for hotfixes, because hotfixes deployed under time pressure are exactly the ones most likely to have an unnoticed dependency gap.
DeployEzee builds this gate directly into the deployment workflow, comparing sandbox and production metadata automatically and surfacing dependency conflicts before a validation run is even triggered. The goal is not to add process for its own sake. It is to make the failure show up on a Tuesday afternoon during planning instead of during Friday's release window.
Frequently Asked Questions
Does a validation-only deployment count against Salesforce deployment limits?
No, check-only deployments do not consume your organization's deployment row limits or affect deployment history counts the way a real deployment does. They do still run against Salesforce's compilation and API infrastructure, so extremely large packages can still take a long time to validate. Think of it as a full dress rehearsal that just never opens the curtain.
How long does Salesforce keep a validation result valid for quick deploy?
A successful validation stays eligible for quick deploy for 10 days from the time it completes. After that window closes, Salesforce requires a fresh validation with full Apex test execution before it will allow the deployment to proceed. There is no way to extend this window, so plan your release timing around it.
Can validation-only deployments catch data-related failures?
No, validation only checks metadata compilation, dependency resolution, and Apex test coverage against existing data in the target org. It cannot predict integration failures, governor limit issues at production data volume, or user-facing process problems. Those require separate testing like UAT or load testing against a full-copy sandbox.
Is running a validation-only deployment the same as testing in a sandbox?
Not quite. Sandbox testing exercises the actual functionality with real user interaction and data, while a validation-only deployment simply confirms the package would deploy successfully to a specific org. Both matter, and skipping one to rely on the other leaves real gaps in your release confidence.
Should every Salesforce deployment go through a validation-only run first?
For any deployment touching Apex, flows, or objects with dependencies, yes, it is worth the few extra minutes before committing to a real deploy. Simple, low-risk metadata changes like a single new list view carry less benefit from the extra step. As a rule, if the package could break a test class or reference a missing field, validate first.