Salesforce Post-Deployment Testing
Salesforce post-deployment testing is the set of checks that run in the target org immediately after metadata lands, confirming that critical business journeys still work, that manual post-deployment steps were completed, and that nothing adjacent broke. It happens inside the deployment window, often in production, so the tests must be fast, safe to run against live data, and decisive enough to support a go, fix-forward or rollback decision.
SyntraFlow is designed to run production-safe smoke and targeted regression packs after deployment; this is available for demonstration and proof-of-concept validation.
Why a successful deployment still needs checking
When the Metadata API reports a deployment as succeeded, it confirms that every component was accepted and that required Apex tests passed during the deploy. It does not confirm that the org behaves as it did in staging. Production differs from even a full copy sandbox in ways that matter: data volumes are larger, integration endpoints and Named Credentials point to live systems, users hold permission set assignments that were never copied, and settings changed directly in production since the last refresh may not exist anywhere else.
Some parts of a release are not metadata at all. Permission set assignments, custom setting values, queue memberships, scheduled Apex jobs, and data records such as price book entries are frequently handled as post-deployment steps, either scripted or manual. If one is missed, the deployment report stays green while users hit errors on Monday morning. Post-deployment testing is the moment where those gaps become visible while the release team is still assembled.
This page focuses on what happens after the deploy. Checks that decide whether a package should be deployed at all are covered on deployment validation, and emergency mid-week fixes have their own playbook in production hotfix validation.
Smoke versus regression after deployment
Post-deployment checks usually run in two tiers. The first decides whether the release is alive; the second confirms nothing nearby was damaged.
| Attribute | Post-deployment smoke pack | Post-deployment targeted regression |
|---|---|---|
| Goal | Prove critical journeys work at all | Prove journeys touched by the change still behave correctly |
| Timing | Minutes after the deploy completes, inside the window | Right after smoke passes, or early the next business morning |
| Scope | Login, key record creation, core Flows, one integration round trip | Processes mapped from the deployed components |
| Data | Dedicated, clearly tagged test records only | Tagged test records plus read-only checks on real configuration |
| Typical duration | Short enough to finish before the window closes | Longer, sized to the change |
| Failure response | Immediate go or rollback decision | Triage, fix forward or scheduled rollback |
| Who watches | Release manager and on-call admin | QA lead and process owners |
What a post-deployment smoke pack should cover
A good smoke pack is small and chosen for blast radius, not completeness.
Authentication and landing
Representative personas log in through SSO, reach their Lightning app and see the expected home page and navigation items.
Core record creation
Create and save a tagged Lead, Opportunity or Case so validation rules, required fields and before-save Flows fire in the real org.
Changed automation
Exercise each Flow, trigger or approval process included in the deployment at least once on a safe record and confirm the expected field updates.
Access for key roles
Confirm that a permission set change gives the intended users access and did not expose records to others, drawing on security regression testing.
One integration round trip
Send a tagged record through an outbound integration or platform event and confirm the acknowledgement, without creating real orders or invoices.
Post-deployment steps done
Verify that assignments, custom setting values, scheduled jobs and activated Flow versions from the runbook are actually in place.
Designing tests that are safe to run in production
The hardest part of post-deployment testing is doing it against live data without side effects. Every record a test creates should be identifiable, for example by a naming convention, a dedicated test Account hierarchy, or a checkbox field that downstream automation and integrations are configured to ignore. Tests should avoid actions that send email to customers, post to external billing, or trigger approval notifications to real managers, and email deliverability or recipient filters should be considered before the pack is ever run.
Use dedicated test users with the same profiles and permission sets as real personas rather than running as a system administrator, which hides access problems. Clean up created records at the end of the run or keep them in a known test hierarchy excluded from reports and forecasts. Read-only assertions, such as confirming that a picklist value exists, a Flow version is active, or a page layout is assigned to a profile, give a lot of confidence at almost no risk. For environments where synthetic data is preferred, synthetic test data keeps real customer data out of test evidence entirely.
A post-deployment testing runbook
The sequence below fits a scheduled production release inside an agreed deployment window.
Freeze and baseline
Before deploying, record the current state of critical configuration and confirm the smoke pack passes against production, so later failures can be attributed to the release.
Deploy and complete manual steps
Run the deployment through the team's DevOps tool, then work through the post-deployment runbook for non-metadata changes.
Run the smoke pack
Execute production-safe smoke tests as representative personas and publish results to the release channel.
Decide go, fix forward or roll back
Use agreed criteria: a critical journey failure with no quick fix means rollback, a minor defect with a known workaround may be fixed forward.
Run targeted regression
Execute the regression packs mapped to the deployed components, using deployment impact analysis to select them.
Clean up and close the release
Remove or archive test records, attach evidence to the change record, and confirm monitoring is in place for the first business day.
Post-deployment failures teams actually see
These are typical issues that only appear once metadata reaches the target org.
- A new permission set deployed correctly but was never assigned, so the feature is invisible to every intended user.
- A Flow deployed as inactive because the org setting to deploy Flows as active was not in use, leaving the old version running.
- A Named Credential or remote site setting points to a sandbox endpoint, so the integration fails only in production.
- A validation rule that passed in a sandbox with clean data blocks updates on legacy production records that violate it.
- A scheduled Apex job was aborted to allow deployment of its class and never rescheduled.
- Large data volumes make a trigger or Flow hit governor limits on production records that staging never had.
- A report or dashboard referencing a renamed field returns errors for leadership on the first morning after release.
Supporting the rollback decision
Salesforce has no single undo button for a deployment. Rolling back usually means redeploying the previous version of changed components from source control, adding a destructive changes manifest to remove new components, reactivating a prior Flow version, and reversing any data or assignment changes made during post-deployment steps. Some changes, such as a field type conversion or deleted data, cannot be fully reversed. That makes the decision expensive, and it has to be made quickly while the window is still open.
Post-deployment test results are what make that decision defensible. A clear view of which journeys failed, which components they involve, and whether the failure reproduces lets the release manager choose between rollback and fix forward on evidence rather than instinct. After a rollback, the same smoke pack should run again to prove the org actually returned to a working state, since a partial rollback can leave it worse than either version. Comparing the org afterwards with a metadata diff confirms what really changed.
How SyntraFlow supports post-deployment testing
SyntraFlow is a validation layer, not a deployment tool. It is designed to plug into the post-deployment stage of an existing release process.
Triggered after deploy
A pipeline step or release checklist action can start a SyntraFlow smoke run against the target org as soon as the deployment completes.
Production-safe packs
Packs can be configured to use tagged test records, dedicated personas and read-only assertions suited to live orgs.
Cross-system confirmation
Runs can be configured to follow a process into connected systems such as Oracle or SAP to confirm the downstream result.
Evidence for sign-off
Results, timestamps and scope are captured as a record for change management, with proof-of-concept validation available on request.
Related pages
Salesforce DevOps Testing
The hub for pipeline validation, quality gates and release evidence.
Deployment Validation
Checks that decide whether a package is safe to deploy before it lands.
Production Hotfix Validation
Fast, focused validation for urgent fixes shipped outside the normal release cycle.
Quality Gates
Define which post-deployment failures trigger rollback and who can override.
Security Regression Testing
Confirm permission and sharing changes did not widen or remove access after release.
Sandbox Production Comparison
Find the differences between staging and production that cause post-deployment surprises.
Post-Deployment Testing testing FAQs
What is Salesforce post-deployment testing?
It is validation that runs in the target org right after a deployment completes, usually a fast smoke pack followed by targeted regression. It confirms that critical journeys work, that non-metadata post-deployment steps were done, and that adjacent processes were not broken. Results feed the go, fix-forward or rollback decision.
Is it safe to run automated tests in Salesforce production?
It can be, if tests are designed for it. Use dedicated test users with real profiles, clearly tagged test records that integrations and reports ignore, read-only assertions where possible, and cleanup at the end. Avoid actions that email customers or post to live financial systems.
How long should a post-deployment smoke pack take?
Short enough to finish comfortably inside the deployment window with time left to roll back if needed. Teams typically keep it to a handful of critical journeys and move everything else into targeted regression that can run afterwards.
Do Apex tests run during deployment replace post-deployment testing?
No. Apex tests during a production deploy run against isolated test data and roll back their changes. They do not confirm user-facing behavior, real permission assignments, live integration endpoints or production data conditions, which is what post-deployment checks target.
What should happen when a post-deployment test fails?
Confirm the failure reproduces, identify the components involved, then apply the agreed criteria. A critical journey failure without a quick fix normally means rollback; a contained defect with a workaround may be fixed forward. Rerun the smoke pack after either action.
Does SyntraFlow perform the rollback?
No. Rollback is handled by the team's deployment tooling and source control. SyntraFlow is designed to provide the test results that inform the decision and to rerun validation afterwards to confirm the org is healthy.
Know your release works before the window closes
See how SyntraFlow is designed to run production-safe smoke and regression checks the moment a Salesforce deployment lands.