Salesforce Deployment Checklist 2026: What to Verify Before Every Production Release

Q: What should a Salesforce deployment checklist include?

A complete Salesforce deployment checklist covers three phases. Pre-deployment: confirm all approvals are in place (UAT sign-off, release manager approval, CAB if required), verify the deployment package against the release scope, confirm rollback plan is documented and accessible, notify affected stakeholders and confirm the change window timing. During deployment: execute a pre-deployment validation run, monitor test execution and test coverage, verify no unexpected components are included, check for any known conflicts with recent Salesforce platform updates. Post-deployment: execute the smoke test checklist covering all changed functionality, verify integration points are still operational, confirm critical business workflows are unaffected, notify stakeholders of successful deployment, and document the release record.

Q: How do you run a pre-deployment validation in Salesforce?

A pre-deployment validation (also called a 'check only' deployment) runs all the same steps as a live deployment — compiling Apex, running all local tests — without actually committing any changes to the target org. It provides confirmation that the deployment package will succeed before you run the actual deployment. To run a pre-deployment validation: use Salesforce CLI with the --check-only flag, or use your deployment tool's validation mode. The validation must pass with 75% or greater Apex code coverage (this is Salesforce's minimum requirement) and zero test failures. Many teams also require that specific critical test classes pass — not just that coverage meets the 75% threshold overall.

Q: What should you do if a Salesforce production deployment fails?

If a production deployment fails, the first action is to assess the failure state: did the deployment fail before any changes were committed (the org is unchanged), during partial execution (the org may be in an inconsistent state), or after all changes were committed but with test failures? A failure before changes were committed is safe — fix the issue and redeploy. A partial failure requires careful assessment of which components were deployed before the failure and whether a manual rollback of those components is needed. A post-commit test failure means the code is deployed but tests are failing — this may indicate an environment-specific issue that was not caught in UAT. In all cases, execute your pre-documented rollback plan and notify stakeholders immediately.

Q: How long should a Salesforce production deployment take?

Salesforce deployment time depends primarily on the number of Apex test classes run. Salesforce runs all local tests during a production deployment unless you specify --test-level RunSpecifiedTests. Small deployments with a targeted test run can complete in under 10 minutes. Full org deployments running all tests can take 45 minutes to several hours on large orgs. Most teams choose RunSpecifiedTests for their release deployments — running only the test classes that cover the components being deployed, plus any integration test classes that might be affected. This requires knowing which test classes cover which components, which is part of good release governance documentation.

Q: What is the difference between a deployment validation and a deployment in Salesforce?

A deployment validation (check-only deployment) compiles the code, runs the specified tests, and checks that coverage meets the 75% threshold — but does not actually commit any changes to the org. The org is left exactly as it was before the validation. A live deployment performs all the same steps and then commits all the changes if the compilation and tests pass. Best practice is to always run a validation before the live deployment — confirm it would succeed in the target environment, fix any issues, then run the live deployment. In Salesforce, if a validation has passed within 10 days, you can quick-deploy using that validated package without re-running tests, which dramatically speeds up the change window.

A Salesforce deployment checklist is one of the simplest governance tools a release team can have — and one of the most consistently absent. Most teams rely on institutional memory: the senior developer who remembers to back up the permission sets, the release manager who always checks test coverage before the window opens. When that person is on holiday, or leaves the company, the institutional knowledge goes with them and the next deployment goes sideways in a way that was entirely preventable.

A deployment checklist does not need to be complex. It needs to be complete, consistently used, and documented in a place the whole team can access. This guide provides the structure for a production-grade checklist across three phases — pre-deployment, during deployment, and post-deployment validation — along with the reasoning behind each item so the team understands why each step matters, not just that it is required.

Why Most Salesforce Deployment Checklists Fail

The most common failure mode is that checklists are created after an incident — a deployment that failed because nobody verified test coverage, or a rollback that took three hours because nobody had documented the rollback procedure. The checklist is created, used for two or three releases, then quietly abandoned when it starts feeling like overhead during a busy sprint.

Two things prevent this. First, keep the checklist short enough that it can realistically be completed in full on every deployment. A 60-item checklist will be skipped when time is tight. Twelve to fifteen essential items that take ten minutes to verify will actually be used. Second, make the checklist part of the release record — not a separate document that can be bypassed, but the document that must be signed off by the release manager before the deployment runs.

Release governance requires evidence, not assumption. A checklist that lives in the release manager's head is not governance documentation — it is institutional risk. The checklist must exist in a written, accessible form, with the date and name of who completed each item recorded for every production deployment.

Phase 1: Pre-Deployment Checklist (48–72 Hours Before Change Window)

This phase covers everything that must be confirmed before the change window opens. Items that are discovered or resolved during the change window are items that should have been caught here.

Scope and Approval

Release scope confirmed — the deployment package contains exactly the components listed in the release plan, no more and no less
UAT sign-off received in writing — a named business stakeholder has confirmed in writing that UAT testing is complete and approved
Release manager approval completed — the release record has been reviewed and approved by the release manager
CAB approval obtained (if required) — for organisations with Change Advisory Board requirements, formal change approval has been received
Freeze calendar checked — confirmed that the planned deployment date does not fall within a declared freeze period

Technical Validation

Pre-deployment validation (check-only) passed in production — a check-only run has been executed against production within the past 10 days, with zero test failures and 75%+ coverage
Test coverage for all new/modified Apex confirmed at 75%+ — not just the org-wide average, but specifically for all classes and triggers being deployed
No known conflicts with recent Salesforce updates — any critical updates that have recently activated have been tested against the deployment package
Integration touchpoints verified — any components that interact with external systems (connected apps, named credentials, integration flows) have been tested in UAT with integrations active
Deployment package matches UAT-validated package — the exact package deployed in UAT is the package being deployed to production (no late additions or modifications)

Rollback and Communication

Rollback plan documented — the procedure for rolling back this specific release is written and accessible to the deployment team
Stakeholder notification sent — all affected business stakeholders have been notified of the upcoming deployment, change window timing, and expected impact
On-call team confirmed — the team members required for the deployment and post-deployment validation are confirmed available for the change window

Phase 2: During-Deployment Checklist (Change Window Execution)

The during-deployment checklist is executed in real time during the change window. Items should be verified in sequence — do not proceed to the next step until the current one is confirmed.

Pre-Execution (Before Deployment Runs)

Org locked for maintenance (if required) — for major releases, consider enabling maintenance mode or communicating to users that the deployment is starting
Production backup state noted — record the current metadata state of any components being changed (export relevant metadata or note the current configuration) to support rollback if needed
All deployment team members present — confirm the full on-call team is available before starting the deployment
Deployment tool and access confirmed — the deployment tool, credentials, and connected app have valid access to the production org

During Execution

Test execution progress monitored — track test execution in real time; if tests are failing unexpectedly, assess whether to abort before all tests complete
Apex test coverage verified at completion — confirm coverage is 75%+ and all specified tests pass before accepting the deployment result
Deployment success status confirmed — the deployment status shows Succeeded, not Succeeded with Errors or Failed
Deployment timestamp and operator logged — record the exact time the deployment completed and who executed it

Phase 3: Post-Deployment Validation Checklist (Within 30 Minutes of Deployment)

Post-deployment validation is the most skipped phase of the checklist — and the most critical. A deployment that succeeds technically (all tests pass, no errors) can still produce a broken production experience if configuration-level changes were not validated against live data or if an integration is not functioning as expected. Post-deployment validation catches these issues within the change window, when rollback is still straightforward.

Functional Smoke Tests

All changed functionality smoke-tested by a human — the specific changes in this release have been manually verified by a team member logging into production (not UAT)
Critical business workflows verified — the highest-traffic and highest-risk workflows in the org (lead conversion, opportunity creation, case submission, etc.) have been executed and confirmed working
Changed flows and automations triggered and confirmed — any Process Builder, Flow, or Apex trigger changes have been triggered in production to confirm the automation fires correctly
Reports and dashboards checked — any changes to reports, report types, or dashboard components have been verified in production

Integration and System Verification

Integration health checked — any external integrations touched by this release (APIs, middleware, connected apps) have been verified as operational in production
Error monitoring checked — the org's error log or monitoring tool has been checked for any unexpected errors generated since the deployment completed
Platform event or message queue health checked (if applicable) — if the release touches event-driven components, confirm the queues are processing normally

Completion and Communication

Rollback decision confirmed — explicitly confirm: are all validation items passing? If yes, proceed. If no, execute rollback within the change window.
Stakeholder completion notification sent — notify all affected stakeholders that the deployment is complete and the system is available
Release record updated — the release record is updated with the deployment completion time, who validated, and the results of the post-deployment smoke tests
Monitoring period started — confirm that someone is monitoring for errors and user-reported issues for the next 2–4 hours after deployment

The Quick-Deploy Optimisation

One of Salesforce's most useful deployment features that many teams underuse is Quick Deploy. When a check-only validation has been run successfully against production within the last 10 days, Salesforce allows you to deploy that same validated package to production without re-running all the tests. Instead of a 45-minute deployment window, the live deployment takes just a few minutes.

This has significant governance benefits: the pre-deployment validation can be run during the working day (when the full team is available to diagnose any issues), and the actual production deployment can happen quickly during the change window. The risk window for the production org is minimised.

To use Quick Deploy effectively:

Run the check-only validation against production at least 24 hours before the planned change window
Record the validation ID in the release record
Confirm the validation is still valid (within 10 days) at the start of the change window
Use Quick Deploy to apply the validated package with minimal runtime
Proceed to post-deployment validation immediately

Quick Deploy only works if the org has not changed significantly between the validation and the deployment. If other changes were made to production between the validation run and the Quick Deploy, those changes can cause the previously-validated package to behave unexpectedly. Confirm with the team that no unplanned changes were made to production in the intervening period.

Deployment Checklist for Specific Change Types

Some change types require additional checklist items beyond the standard list above. Three categories that most commonly need supplementary checks:

Data model changes (new fields, field type changes, picklist modifications)

Verify field-level security has been applied to all relevant profiles and permission sets
Check that any picklist value changes have been reflected in existing reports and list views
Confirm that data migration or cleanup scripts have been run if required (field type changes that require data transformation)
Verify that any formula fields referencing modified fields still calculate correctly

Permission set and profile changes

Verify the expected user population has access to new functionality (and no unexpected users have access)
Test a representative user from each affected profile or permission set group
Confirm no existing permissions have been inadvertently removed

Integration configuration changes (named credentials, connected apps, remote site settings)

Verify integration authentication is working in production (not just in sandbox)
Trigger a test transaction through the integration and confirm the response
Check that any certificates or tokens referenced have not expired in production

Want a deployment checklist that runs itself?

DeployEzee automates the pre-deployment validation, tracks test coverage across your releases, and maintains the release record — giving your team deployment confidence without the manual checklist overhead.

Book a Free Consultation

Building the Checklist Into Your Release Governance

A deployment checklist that is stored in a shared document and optionally completed is worth almost nothing as a governance control. For it to function as release governance, the checklist must be:

Mandatory, not optional — the release record cannot be marked complete without the checklist being fully completed and signed off
Evidenced — each item should have a timestamp and the name of the person who verified it, not just a tick
Reviewed for improvement — after each production incident that the checklist should have caught, the checklist is updated to include a new item that would have prevented the incident
Periodically simplified — a checklist that grows to 40+ items without periodic pruning becomes a compliance exercise rather than a genuine verification tool. Audit the list annually and remove items that have never caught a real issue.

The Salesforce release management process guide explains how the deployment checklist fits within the full seven-step release process. The deployment risk playbook covers how to assess which changes need supplementary checklist items and how to score release risk before the deployment runs.

Frequently Asked Questions

What should a Salesforce deployment checklist include?

A complete checklist covers three phases: pre-deployment (scope confirmation, UAT sign-off, governance approvals, technical validation via check-only run, rollback plan, stakeholder notification), during deployment (pre-execution confirmation, test monitoring, success status recording), and post-deployment (functional smoke tests on changed features, critical workflow verification, integration health check, completion notification, release record update).

How do you run a pre-deployment validation in Salesforce?

Use Salesforce CLI with the --check-only flag, or your deployment tool's validation mode. A check-only run compiles all code, runs the specified tests, and verifies coverage without committing any changes. It must pass with 75%+ coverage and zero test failures. If the validation passes within 10 days of the planned deployment, Quick Deploy can be used to apply the changes without re-running tests — dramatically reducing the change window time.

What should you do if a Salesforce production deployment fails?

Assess the failure state first: did it fail before changes were committed (org unchanged — fix and redeploy), during partial execution (assess which components deployed and whether rollback is needed), or after commit but with test failures (code is live but tests are failing — may be an environment issue not caught in UAT). Execute the pre-documented rollback plan and notify stakeholders immediately. Run a post-incident review within 48 hours to identify what the checklist should have caught.

How long should a Salesforce production deployment take?

Targeted deployments using RunSpecifiedTests can complete in under 10 minutes. Full org deployments running all tests can take 45 minutes to several hours. Most teams use RunSpecifiedTests for planned releases — running only test classes that cover the deployed components plus any impacted integration tests. Quick Deploy (using a previously-validated package) reduces the change window to a few minutes for the actual deployment, with testing having run in advance during the validation phase.

What is the difference between a deployment validation and a deployment?

A validation (check-only) compiles code, runs tests, and checks coverage but commits no changes — the org is left exactly as before. A live deployment performs the same steps then commits all changes if successful. Always run a validation before the live deployment. If that validation has passed within the last 10 days and the org has not changed since, Quick Deploy applies the changes in minutes without re-running tests.