Here's the thing you came for: a free Salesforce deployment checklist as an Excel workbook — the four phases of a safe release, each item with a priority and a note on what actually goes wrong, and a scorecard that tallies whether you're clear to push. Download it, run it against your next release, and the rest of this post is why each phase matters — including the one Salesforce quietly leaves out.
A deployment checklist isn't ceremony. It exists because of one uncomfortable fact: most production incidents don't happen because the deploy failed. They happen because it succeeded. The metadata went in clean, every test passed, the status said Succeeded — and an hour later a flow errors, a report comes back empty, or an integration starts rejecting records, because something nobody remembered was pointing at the field you just changed. The checklist is how you catch that before the push, not in the incident channel after.
Phase 1 — Pre-flight (the phase that actually prevents incidents)
Everything upstream of this fails at the same point: you can't safely change what you don't fully understand.
- Know exactly what's in the deployment. Not "the Q3 changes" — the specific components. A change set or metadata list you can read line by line.
- Know the blast radius of each change. For every field, object, or automation you're touching or removing: what references it? Flows, validation rules, formulas, reports, Apex, page layouts, and integrations all reach in, and the ones outside the platform won't announce themselves. This is the step that gets skipped, and it's the one that would have caught the incident.
- Diff the target. Sandbox and production drift apart — someone hotfixes prod, a sandbox goes stale. Compare what's actually in production against what you're deploying from, so you're not overwriting a change that only exists in prod.
- Validate before you deploy. Run a validation-only deployment (Salesforce calls it "check only") against production with the tests that will run. It compiles everything and runs tests without committing, so you find the failures on your schedule instead of mid-deploy. A validated deployment can then be quick-deployed without re-running everything, within the limited window Salesforce keeps the result.
- Confirm test coverage. Deploying Apex to production requires at least 75% org-wide code coverage and all tests passing. Know your number before you start, not when the deploy rejects.
Phase 2 — The deploy
- Order by dependency. A component has to exist before the thing that references it. Deploy the field before the flow that uses it; the object before the field.
- Deletions are not in a change set. Change sets add and update — they don't delete. Removing a field, object, or component is a separate, deliberate step (destructive changes via the Metadata API or a deployment tool, or manual removal), and it's the step people forget until the "cleanup" never happens.
- Deactivate before you delete. Some components — flows especially — must be deactivated before they can be removed, and may be referenced by others that have to be handled first.
- Pick the test level intentionally. Production runs tests on deploy; know whether you're running local tests or all tests, and why.
Phase 3 — Validate in production
A green deploy status means the metadata saved and tests passed. It does not mean the feature works. Before you call it done: spot-check the actual behavior with a real record, confirm the automation fires, run the report that matters, and check that any integration touching the changed fields still round-trips. Ten minutes here is cheaper than a Monday-morning escalation.
Phase 4 — The rollback plan Salesforce doesn't give you
This is the phase most checklists omit, because it's the one Salesforce doesn't hand you: there is no native one-click rollback of a successful deployment. Once a metadata deploy commits, "undo" means deploying the previous state — which you can only do if you captured it. So the rollback plan is a pre-flight task, not an emergency one:
- Before you deploy, capture the current production state of everything you're changing (retrieve the metadata, or record it) so a revert is a deploy you already have staged, not a reconstruction under pressure.
- Write down the revert steps and who makes the call. "We'll just roll it back" is not a plan if no one saved what "back" was.
- Note anything irreversible — deleted data, a field type change that dropped values — separately and loudly, because those don't roll back at all.
Most production incidents don't happen because the deploy failed. They happen because it succeeded — and something no one remembered was pointing at what you changed.
The honest catch — the checklist can't see your org for you
Every item above is sound, and the workbook makes them repeatable. But two of them — know the blast radius and diff the target — are only as good as your ability to actually see your org, and that's exactly where a spreadsheet runs out of road. You can't hand-list everything that references a field across flows, formulas, validation rules, Apex, reports, and layouts by clicking through Setup; it's too much surface, and the references you'll miss are precisely the ones that break in production. And diffing sandbox against production by eye is not realistic past a handful of changes.
That's the honest boundary: the checklist gives you the discipline and the sequence, but the two steps that carry the most risk want tooling, not memory. Knowing the full blast radius of a change before you make it is impact analysis; knowing exactly how two orgs differ is a schema diff. Both are what SchemaForce does — it maps every reference to a field or object so "what breaks if I change this" is a lookup, not a hunt, and it diffs a sandbox against production so you deploy knowing exactly what's different. The checklist stays yours; what automation removes is the impossible part — holding an entire org's dependency graph in your head at 4:45 on release day.
Start here
Download the checklist and run it against your next release, honestly. Pay attention to Phase 1 — if "know the blast radius" and "diff the target" turn into a shrug because there's no realistic way to do them by hand, that's not a discipline gap, it's the signal that those two steps have outgrown a spreadsheet. (Deploying because you're removing tech debt? Finding every reference before you delete a field is the same blast-radius problem, from the other direction.)
