Salesforce Deployment Validation Testing
Salesforce deployment validation testing confirms, before anything is committed to the target org, that a release will deploy cleanly and behave correctly once it does. It combines the platform's check-only deployment and Apex test levels with functional checks in a production-like sandbox, so release managers approve a quick deploy knowing both the metadata and the business processes are sound.
This page covers validation before a change is committed. Checks that run after the change lands are covered on post-deployment testing.
Two questions every release must answer
Every Salesforce release has to answer two different questions before it reaches production. The first is technical: will this package deploy? That means every component resolves its dependencies, nothing references a field the target org lacks, destructive changes do not strand a Flow or report, and Apex tests pass with the coverage the platform requires. The second is functional: once deployed, will the org still do what the business needs? That means Flows fire, validation rules allow valid records, layouts show required fields to the right profiles, and integrations still accept the data Salesforce sends.
Salesforce provides strong tooling for the first question. A check-only deployment, run with sf project deploy validate or by validating a change set, performs the whole deployment and test run in the target org and then rolls it back. The second question has no built-in answer. It requires functional tests against an org that already holds the change, which is why deployment validation is really a pairing: platform validation against production, and functional validation against a production-like sandbox that received the identical package.
The difference from post-deployment testing is timing and risk. Everything on this page happens while a failure still costs nothing more than a delayed release.
Apex test levels and what each proves
The test level chosen for a validation determines how much of the org's Apex is exercised and what coverage rules apply.
| Test level | What runs | Validation implications |
|---|---|---|
| NoTestRun | No Apex tests | Allowed in production only when the deployment contains no Apex classes or triggers; proves nothing about behavior |
| RunSpecifiedTests | Only the test classes you name | Fastest option for production, but each class and trigger in the deployment needs at least 75% coverage from those tests |
| RunLocalTests | All tests except those from installed managed packages | The default for production deployments that contain Apex; org-wide coverage must reach 75% |
| RunAllTestsInOrg | All tests, including managed package tests | Slowest and can fail on package tests you do not control; rarely needed for routine releases |
| Any level, with a quick deploy | Tests run once during validation | A successful validation with tests can be quick deployed within 10 days, skipping the rerun if nothing invalidates it |
A deployment validation sequence
A practical order of operations that keeps technical and functional validation aligned to the same package.
Freeze the release package
Build the manifest or source directory from a tagged commit. Every later step must use exactly this package, including any destructiveChangesPre.xml or destructiveChangesPost.xml.
Run impact analysis
List what the package touches and what depends on it, using deployment impact analysis, so functional scope is based on real references rather than guesswork.
Deploy to a staging sandbox
Deploy the package fully to a partial or full copy sandbox that matches production configuration, confirmed with a sandbox to production comparison.
Run functional validation
Run the regression packs mapped to the impacted processes and personas. SyntraFlow is designed to be called at this point and return a pass/fail result with an evidence record.
Validate against production
Run a check-only deployment against production with the agreed test level and capture the validation job ID.
Review and approve
The release manager reviews the functional evidence and the production validation together, against the rules set in quality gates.
Quick deploy in the window
Run sf project deploy quick with the job ID. If the validation has expired or been invalidated, repeat the production validation rather than falling back to an unreviewed full deploy.
What check-only validation cannot catch
A successful validation is necessary, not sufficient. These failure types pass validation and still break production.
Data-dependent validation rules
A new rule that rejects records with a blank Region__c deploys cleanly, then blocks every integration insert and existing Flow that does not set the field.
Flow logic changes
A record-triggered Flow with a changed entry condition compiles and deploys, but no Apex test checks that the onboarding Case is still created.
Permission and layout gaps
A field added to a layout but not granted in a permission set is invisible to users, and nothing in a deployment reports that.
Sharing and visibility changes
A modified sharing rule or role hierarchy change alters who sees which records; see sharing rule testing.
Integration contracts
A picklist value renamed in Salesforce is valid metadata, but the ERP mapping that expects the old value quietly rejects orders.
Tests that assert nothing
Apex tests that execute code for coverage without assertions pass validation while the behavior they cover is broken.
Destructive changes deserve their own validation
Deleting metadata is where deployment validation most often goes wrong. A destructive manifest removes fields, classes, Flows or record types from the target org, and the order matters: destructiveChangesPre.xml runs before the package is deployed, destructiveChangesPost.xml after. Deleting a field before removing the Apex or Flow that references it fails the deployment; deleting it after can still leave reports, list views, email templates or external integrations pointing at nothing.
Check-only validation catches the hard dependency failures that the platform enforces. It does not catch references outside the platform's dependency tracking, such as a MuleSoft mapping, a middleware query, a formula in a connected system, or a Marketing Cloud data extension that expects the field. Before a destructive release, search dependency analysis output and integration mappings for the removed components, then run functional and integration regression in the staging sandbox after the destructive changes have been applied there.
Also remember that some deletions are hard to reverse. A deleted custom field sits in the recycle bin for a limited time and its data is lost once purged. Validation for destructive releases should therefore include a confirmed backup or export of affected data, not only a green check.
Deployment validation pitfalls
Recurring mistakes that turn a validated release into a production incident.
- Functional tests run against a sandbox that received a different package than the one validated against production, often because a late fix was added only to the production deployment.
- The staging sandbox has drifted from production, so it passes tests that production would fail; refresh it or compare configurations before relying on it.
- A validation expires or another deployment reaches production first, and the team runs a full deploy with a different test level instead of revalidating.
- RunSpecifiedTests is selected for speed and fails late on per-class coverage, forcing a rushed switch to RunLocalTests during the release window.
- Profiles are deployed partially, overwriting field permissions for fields not included in the package and removing access users had.
- Managed package versions differ between staging and production, so behavior validated in staging does not match what production will run; see managed package upgrade testing.
Evidence a release manager should see
What an approver needs in front of them before approving a quick deploy.
Package identity
The commit or tag, the manifest and any destructive manifests, so everyone approves the same thing that will be deployed.
Production validation result
The validation job ID, test level, pass count, failures and coverage, with the time the validation window closes.
Functional results
Which processes and personas were tested in which sandbox, what passed and what failed, with an evidence record per run.
Known exceptions
Any failures accepted as known issues, who accepted them and why, so exceptions are explicit rather than silent.
Related pages
DevOps testing hub
How deployment validation fits the wider pipeline validation layer.
Post-deployment testing
The checks that run after the validated package reaches production.
Quality gates
The rules that decide whether validation results allow a quick deploy.
Deployment impact analysis
Finding what a package touches before choosing functional tests.
Production hotfix validation
Applying fast, focused validation when an urgent fix cannot wait.
Release readiness checklist
A broader checklist for preparing any Salesforce release.
Deployment Validation testing FAQs
What is Salesforce deployment validation testing?
It is the set of checks run before a release is committed to the target org. It pairs a check-only deployment with the right Apex test level, which proves the package will deploy and tests pass, with functional regression in a production-like sandbox, which proves the business processes still work.
What is the difference between validate and quick deploy?
Validation runs the full deployment and Apex tests in the target org and then rolls everything back. If it succeeds with tests, a quick deploy can commit the same package within 10 days without rerunning the tests, which shortens the production release window considerably.
Is a successful check-only deployment enough?
No. It proves metadata dependencies resolve and Apex tests pass. It does not test Flows, validation rules against real data, permission and layout combinations, sharing, or integrations, which is why functional validation in a sandbox belongs alongside it.
Which test level should we use for production validation?
RunLocalTests is the dependable default when a package contains Apex. RunSpecifiedTests can be much faster for large orgs, but every class and trigger in the package needs 75% coverage from the named tests, so check that early rather than on release night.
How should destructive changes be validated?
Validate them in the same package against production, apply them to the staging sandbox before functional regression, and check references outside Salesforce's dependency tracking, such as middleware mappings and connected systems. Export affected data first, because deleted field data cannot be recovered once purged.
Where does SyntraFlow fit in deployment validation?
SyntraFlow is designed to run the functional part: impact-mapped regression against the staging sandbox that received the release package, returning a result and evidence record the release manager reviews alongside the production validation. It does not deploy metadata and is available for demonstration and proof-of-concept validation.
Approve quick deploys with the full picture
See how functional evidence and production validation results can be reviewed together before a Salesforce release.