A Salesforce Deployment Checklist Built From Real Mistakes
WHY DEPLOYMENTS FAIL
Most Salesforce deployments do not fail because the team forgot something big. They fail because of five small things nobody checked:
That is why strong teams use deployment checklists. Not because they are inexperienced, but because they know how easy it is for “routine” releases to go sideways.
- a permission mismatch;
- a missing dependency;
- a Flow that passed in sandbox but not in production;
- a data migration without a backup;
- a deploy user missing the one permission Salesforce needed but did not explain clearly.
That is why strong teams use deployment checklists. Not because they are inexperienced, but because they know how easy it is for “routine” releases to go sideways.
1. Run all relevant tests, not just the tests you touched
A deployment can fail because of metadata you never intended to affect.
Salesforce orgs are tightly connected. One update to a field, object, Flow, or trigger can break tests that appear unrelated on the surface. If you only validate your own area, you may miss org-wide side effects until release time.
A safer approach is to validate the broader system impact before production, especially in orgs with shared objects, complex automation, or legacy dependencies.
Salesforce orgs are tightly connected. One update to a field, object, Flow, or trigger can break tests that appear unrelated on the surface. If you only validate your own area, you may miss org-wide side effects until release time.
A safer approach is to validate the broader system impact before production, especially in orgs with shared objects, complex automation, or legacy dependencies.
2. Check field-level security before users do
A change that works for an admin in sandbox can still fail for real users in production.
New fields, updated layouts, and automation that reads or writes restricted fields often behave differently across profiles and permission sets. This is one of the most common sources of “it worked in sandbox” frustration.
If a new field matters to the release, verify that the right users can actually see and use it.
New fields, updated layouts, and automation that reads or writes restricted fields often behave differently across profiles and permission sets. This is one of the most common sources of “it worked in sandbox” frustration.
If a new field matters to the release, verify that the right users can actually see and use it.
3. Test the whole Flow, not just the part you edited
Flows rarely fail loudly. A single missing reference, changed condition, or inaccessible field can cause automation to stop behaving correctly without creating an obvious issue during release. Teams often validate the changed branch of logic and assume the rest remains safe.
That assumption is dangerous. Production-safe Flow testing means validating entry criteria, downstream actions, related records, permissions, and edge cases, not just the node you changed.
That assumption is dangerous. Production-safe Flow testing means validating entry criteria, downstream actions, related records, permissions, and edge cases, not just the node you changed.
4. Back up data before any risky migration
This is one of those rules teams ignore until the day they need it.
Any deployment that includes data migration, destructive changes, relationship updates, or record transformations should start with a backup plan. Not because failure is guaranteed, but because recovery without backup is often slow, manual, and painful.
If a release touches data, rollback should not depend on memory.
Any deployment that includes data migration, destructive changes, relationship updates, or record transformations should start with a backup plan. Not because failure is guaranteed, but because recovery without backup is often slow, manual, and painful.
If a release touches data, rollback should not depend on memory.
5. Verify the deployment user and service account
Salesforce can produce frustratingly vague deployment errors when the deploying user is missing required permissions. That is why it is worth validating the deploy identity before release, especially if your process uses a dedicated service account or pipeline user. Missing object access, metadata permissions, or broad system rights can waste hours for reasons that are avoidable.
6. Check dependencies before deleting or replacing metadata
Fields, Flows, Apex, validation rules, reports, formulas, and custom objects are often connected in ways teams do not fully see until deployment fails.
A field that looks “unused” may still be referenced somewhere important. A deleted object may break automation outside your current project. Destructive changes are where hidden dependencies become visible (usually at the worst moment).
This is why comparison and validation before deploy matter so much.
A field that looks “unused” may still be referenced somewhere important. A deleted object may break automation outside your current project. Destructive changes are where hidden dependencies become visible (usually at the worst moment).
This is why comparison and validation before deploy matter so much.
7. Do not rely on coverage alone
Passing tests and acceptable coverage are necessary, but they are not the same as release confidence.
Coverage tells you some code executed. It does not tell you whether your business process is safe, whether permissions work, whether reports remain intact, or whether a Flow still behaves correctly across real scenarios.
Use coverage as a baseline, not as your release strategy.
Coverage tells you some code executed. It does not tell you whether your business process is safe, whether permissions work, whether reports remain intact, or whether a Flow still behaves correctly across real scenarios.
Use coverage as a baseline, not as your release strategy.
8. Remember reports, dashboards, and downstream consumers
Metadata changes do not stop at metadata. When fields are renamed, deleted, or repurposed, downstream assets can break quietly: reports, dashboards, formulas, integrations, or user-facing analytics.
A deployment may be technically successful and still create business disruption. If a release changes the data model, test what consumes that model.
9. Document what changed and how to recover
A good release note is not bureaucracy. It is operational insurance.
Your team should be able to answer:
This becomes especially important when support, admins, QA, and developers are all involved in the same production lifecycle.
Your team should be able to answer:
- what changed;
- why it changed;
- what was validated;
- what to do if the release needs rollback.
This becomes especially important when support, admins, QA, and developers are all involved in the same production lifecycle.
10. Validate before the release window, not during it
Late discovery is what turns normal deployments into incidents.
A validate-only run before the actual release helps expose conflicts, missing metadata, failing tests, and destructive change problems early enough to fix them calmly. The later the problem is found, the more expensive it becomes.
A validate-only run before the actual release helps expose conflicts, missing metadata, failing tests, and destructive change problems early enough to fix them calmly. The later the problem is found, the more expensive it becomes.
Where mtdt fits into this process
Most deployment failures are not caused by a lack of effort. They are caused by limited visibility.
mtdt helps teams improve that visibility before production by making it easier to:
compare metadata changes between environments;
That matters because a checklist alone is not enough if the team still has to discover every risk manually. A better deployment process is really a better risk process. Salesforce deployments become safer when teams stop treating release day as the first real test.
The point of a checklist is not caution for its own sake. It is to reduce surprises, shorten recovery time, and increase confidence that production will behave the way the sandbox did. And the more complex the org becomes, the more valuable it is to combine that discipline with tools like mtdt that help surface risk before it turns into downtime.
mtdt helps teams improve that visibility before production by making it easier to:
compare metadata changes between environments;
- inspect differences before deployment;
- catch missing dependencies;
- handle destructive changes more safely;
- reduce the chance of accidental overwrites;
- support a more controlled release workflow tied to versioned changes.
That matters because a checklist alone is not enough if the team still has to discover every risk manually. A better deployment process is really a better risk process. Salesforce deployments become safer when teams stop treating release day as the first real test.
The point of a checklist is not caution for its own sake. It is to reduce surprises, shorten recovery time, and increase confidence that production will behave the way the sandbox did. And the more complex the org becomes, the more valuable it is to combine that discipline with tools like mtdt that help surface risk before it turns into downtime.
Stay tuned!
Subscribe for our newsletters and get special offers.
By clicking the button, you consent to the processing of your personal data and agree to our Privacy Policy.