Salesforce Release Readiness Checklist

Most failed releases were not short of testing. They were short of a clear moment where someone asked "are we actually ready?" and had evidence to answer it. This checklist is that moment. Run it two to five working days before the deployment window, then again on the day, and record who confirmed each item.

It is written for Salesforce core releases (Sales Cloud, Service Cloud, Experience Cloud, Flow and Apex changes) and for marketing releases that touch Marketing Cloud Engagement, Marketing Cloud Next or Account Engagement. Skip the lines that do not apply, but write down why you skipped them.

How to use it

• Treat every line as a question with a named owner and a piece of evidence, not a tick box.
• A "no" on a blocking item means the release moves, or the scope shrinks. Decide which before the go/no-go meeting, not during it.
• Keep the completed checklist with the release notes. It is the first thing you will want if something goes wrong later.

Items teams most often forget

Packages carry metadata well and carry almost everything else badly. Check these explicitly:

• Permission set and permission set group assignments. New fields and objects are invisible until users are given access.
• Picklist values, record types and page layout assignments that differ between environments.
• Environment-specific configuration such as Named Credentials, remote site settings, custom metadata records and custom settings values. See Named Credentials and External Credentials explained.
• Scheduled Apex, batch jobs and scheduled flows that should be paused during deployment and resumed afterwards.
• Data changes: reference data loads, backfills of new fields, and the order they must run in relative to automation being switched on.
• Marketing Cloud Engagement assets that live outside the core deployment: data extension structure changes, Automation Studio schedules, new journey versions and sender settings. Pause dependent automations before changing a data extension they write to.

Rollback is a plan, not a hope

Salesforce has no single "undo" for a deployment. Reversing metadata usually means deploying the previous version from source control, and deleting components needs a destructive change. Data changes are harder still, because records created or updated after go-live may depend on the new structure.

Practical ways to keep rollback realistic:

1. Keep the previous release tagged in version control so it can be redeployed.
2. Put risky behaviour behind a switch you can turn off without a deployment, such as a custom permission or a custom metadata flag checked by Flow or Apex.
3. Export the records any data step will change, and test that the restore actually works.
4. Agree a rollback deadline: the point after which fixing forward is safer than reversing.

For deployment tooling choices, see Salesforce deployment strategies.

On the day

• Confirm the build being deployed is the one that passed UAT (same commit, same package version).
• Announce the start of the window and any freeze on configuration changes in production.
• Run the deployment, then the post-deployment steps in order, recording time and result for each.
• Smoke test the main user journeys with a real user profile, not only as a system administrator.
• Resume paused jobs and automations, then watch error logs, integration queues and Apex exception emails for the first hours.
• Send a short "release complete" note listing anything that changed from the plan.

Related reading: a practical Salesforce release testing checklist, the UAT test plan template and, for marketing changes, testing journeys before activation.