Salesforce post-deployment smoke testing means running a short, targeted set of checks right after a release lands in production, before you tell the business it's done. It is not a full regression suite. It is fifteen to thirty minutes of pointed verification that catches the failures most likely to slip past validation: broken flows, misfired triggers, permission gaps, and integration timeouts that only show up under real data. Skip it, and you find out about the problem from a support ticket instead of a dashboard.
Most teams treat deployment success as a binary: the deploy either passed or it failed. But a green checkmark from the Metadata API only confirms the components compiled and the tests ran. It says nothing about whether a flow actually fires in the right order, whether a validation rule now blocks a use case nobody thought to test, or whether an outbound integration still authenticates correctly after a permission set update. Smoke testing closes that gap.
Why a Clean Deploy Log Isn't Proof of a Working Org
A deployment log tells you what got moved and whether the code compiled. It does not tell you whether the business process built on top of that metadata still works end to end. I have seen deployments pass with 100% code coverage and zero errors, then break lead assignment within the hour because a flow's decision element referenced a picklist value that changed order during the release.
The disconnect happens because unit tests validate logic in isolation. They rarely validate the full user journey: a rep creating an opportunity, a flow updating a related account, a validation rule checking a custom field, and an integration pushing that record to a billing system. Each piece can pass its own test and the sequence can still fail.
This is why smoke testing exists as a separate discipline from unit and validation testing. It is not about proving the code works. It is about proving the org still behaves the way the business expects it to, right now, with today's data and configuration.
The First 15 Minutes After Deploy
Immediately after a production deployment, run through a short, fixed sequence rather than improvising. Improvised checks miss things under time pressure, and time pressure is exactly what you have right after a release window closes.
- Log in as a standard user role, not the system admin, and confirm the primary object list views render without errors.
- Create one test record in each object touched by the release and step it through its key automation, then delete or archive it.
- Trigger the most business-critical flow manually and confirm it completes without a fault email.
- Check the integration user's last successful sync timestamp against an external system if one is part of the release.
- Scan the debug log for the affected Apex classes for any new exception types that weren't present pre-deploy.
None of this replaces a proper QA cycle in sandbox. It is a fast confirmation that production behaves the way sandbox testing predicted it would, because sandbox and production diverge more often than teams like to admit, particularly around data volume, external integrations, and org-wide sharing rules.
Building the Checklist by Metadata Type
A generic smoke test checklist misses the failure modes specific to each metadata type. Flows fail differently than permission sets, and permission sets fail differently than page layouts. The checklist below is a starting point, not a finished product; every org should extend it based on its own history of deployment incidents.
| Metadata Type | First Thing to Check | Common Silent Failure |
|---|---|---|
| Flows | Run the flow manually with a real test record | Decision element references an outdated picklist value |
| Permission Sets | Log in as a user in the target profile and check object access | Field-level security missed on a newly added field |
| Validation Rules | Attempt a save that should pass and one that should fail | Rule blocks an edge case not covered in test scripts |
| Page Layouts | Open a record in the affected layout as a standard user | New field placed but not visible due to FLS |
| Apex Triggers | Check debug logs for unhandled exceptions after a test transaction | Bulk operation exceeds governor limits under real volume |
| Integrations | Confirm the last sync timestamp and a sample payload | Named credential or auth token expired during cutover |
Notice that most of these failure modes are quiet. Nothing throws a red error banner. A user just cannot see a field, or a sync silently stops, or a flow skips a step because a value it expected no longer exists. Quiet failures are the ones that erode trust in the platform, because nobody notices until three weeks of data is wrong.
Manual Click-Through vs Automated Smoke Tests
Manual smoke testing works for small teams and infrequent releases, but it does not scale once you are deploying weekly or across multiple release trains. A human checking the same fifteen things after every deploy will eventually skip a step, especially on a Friday afternoon after a long release window.
Automated smoke tests, whether built with Salesforce's own testing tools or a third-party framework, run the same sequence every time with no variance. They can be triggered automatically the moment a deployment completes, feeding results into the same pipeline that ran the deploy. DeployEzee's post-deploy verification step does exactly this: once a deployment finishes, it runs a defined set of org health checks and metadata cross-references before marking the release complete, so the team gets a result in minutes instead of waiting for a user to report something broken.
The honest tradeoff is setup time. Writing and maintaining automated smoke tests takes real effort up front, and teams under deadline pressure often skip that investment in favor of shipping the next feature. My view is that this is a false economy. The cost of building ten automated checks once is far lower than the cumulative cost of ten manual fire drills a year, each one involving a director asking why nobody caught it sooner.
Who Owns Smoke Testing in the Pipeline
Ownership gets murky in most orgs, and murky ownership is how smoke testing quietly disappears from the release process. The admin who ran the deploy assumes QA will check it. QA assumes the admin already confirmed the basics. Nobody checks anything until a user does.
The clearest model assigns smoke testing to whoever has production access and business context, not necessarily whoever wrote the code. On a small team that is often the release manager or lead admin. On a larger team with a formal change advisory board, smoke testing should be a named, scheduled step with a signed-off checklist, not an informal glance at the object tabs.
Architects should own the checklist itself, deciding what gets tested and why, even if they are not the ones clicking through it after every release. That keeps the checklist aligned with the org's actual risk profile instead of a generic template copied from a blog post.
When a Failed Smoke Test Means Rollback
Not every failed smoke test check requires a rollback. A cosmetic page layout issue affecting a rarely-used record type can often be patched forward with a quick follow-up fix. A broken integration pushing incorrect financial data to an external system cannot wait for a patch; that needs an immediate rollback or a manual freeze on the affected process.
The decision framework worth adopting is simple: does the failure block a revenue-critical process, corrupt data, or expose data to the wrong users? If yes to any of those, roll back immediately and investigate in sandbox. If the failure is cosmetic or affects a low-traffic path, log it, communicate it, and schedule a fix in the next release window.
Having this framework defined before a deployment, not during the panic of a failed smoke test, is what separates a controlled incident from a chaotic one. Teams that argue about severity in the middle of an active production issue lose time they cannot get back, and that argument is exactly what a pre-agreed rollback threshold is meant to prevent.
Smoke testing is a small investment relative to the deployment work that precedes it, but it is the step most often cut when a release runs late. That is backwards. The deployment itself is the easy, repeatable part; confirming the org still works the way the business needs it to is the part that actually protects the release.
Frequently Asked Questions
What is post-deployment smoke testing in Salesforce?
It is a short, targeted set of checks run immediately after a production deployment to confirm core business processes still work. It focuses on the flows, automation, permissions, and integrations most affected by the release rather than testing the entire org. The goal is to catch quiet failures before users report them.
How is smoke testing different from a validation-only deployment?
A validation-only deployment checks whether metadata will compile and pass Apex tests before it goes live, and it happens before the actual deploy. Smoke testing happens after the deploy is live in production and verifies real user-facing behavior, not just compilation success. A clean validation does not guarantee a clean smoke test.
How long should a smoke test take after a Salesforce deployment?
A focused manual smoke test typically takes fifteen to thirty minutes, covering the specific metadata touched by the release. Automated smoke tests can complete in a few minutes once configured, since they run predefined checks without human click-through. Either way, it should happen immediately after the deploy, not hours later.
Should every deployment get a full smoke test?
Every production deployment should get at least a minimal smoke test covering the components it changed, even a small permission set update. The depth of the test should scale with the risk of the change: a config-only release needs less scrutiny than one touching flows, triggers, and integrations together. Skipping smoke testing entirely on the assumption a change is too small is a common source of preventable incidents.
Can smoke testing be automated as part of a Salesforce CI/CD pipeline?
Yes, and it should be for teams deploying more than a few times a month. Automated smoke tests can run immediately after a deployment completes, checking flow execution, integration sync status, and record-level access without manual intervention. Tools like DeployEzee support this as a post-deploy verification step so results are available within minutes of the release finishing.