ChatGPT
Claude
PerplexityThe Ultimate Salesforce Implementation Checklist
A Salesforce implementation checklist works only if each item has a completion test. “Define business objectives” is a topic, not a check. “Objectives written as measurable outcomes with a named owner per metric” is something a person can tick or refuse to tick, which is the entire purpose of the format.
Fourteen checks cover a Salesforce implementation end to end. Six of them block progress and eight are advisory, and knowing which is which is what stops a checklist becoming a formality.
A Salesforce implementation checklist verifies what a plan sequences
These are different artifacts and teams routinely try to make one do both jobs.
A plan answers when things happen and in what order. A checklist answers whether a thing is actually finished. You need both, and the checklist is the cheaper of the two to enforce because anyone can run it without understanding the dependencies. The sequencing behind these items is in the full plan behind the checklist.
Checks 1 to 4 close scope before configuration begins
# | Check | Complete when | Blocking |
|---|---|---|---|
1 | Business objectives | Each objective states a measurable outcome and names the person accountable for it | Yes |
2 | Team and decision rights | Every workstream has a named decision owner and an agreed response window in business days | Yes |
3 | Needs assessment | Current process documented, requirements captured and ranked, out of scope written down | Yes |
4 | Org assessment | Existing configuration reviewed, allocation pressure measured per object, technical debt logged | No |
Check 2 is the one most often skipped and the most expensive to skip. A project with unnamed decision owners does not fail at the decision, it fails at the queue, and the delay is invisible in a status report because every task shows as in progress.
Check 3 fails on the ranking rather than the capture. Requirements collected but never ranked give a design team nothing to trade, so design meetings end without decisions and the same conversation repeats.
Checks 5 to 8 prepare data and environments
# | Check | Complete when | Blocking |
|---|---|---|---|
5 | Data profiling | Source records counted, quality measured on the fields in scope, remediation volume estimated | Yes |
6 | Data migration plan | Mapping signed off, at least one trial load reconciled against source counts | Yes |
7 | Environment plan | Sandbox types chosen, refresh dates fixed, preview instances identified | No |
8 | Integration contracts | Endpoints named, direction agreed, error handling and replay defined | No |
Check 5 belongs here rather than later, and moving it earlier is the highest-return change most teams can make to this list. Profiling data while the object model is still cheap to change converts a mid-project surprise into a scoping decision.
Check 7 carries a detail that catches people. New and refreshed sandboxes have their own configuration behaviour, and Salesforce documents the setup considerations that apply after every refresh. Read them once and write the fixes into a runbook, because you will reapply them every cycle.
Checks 9 to 11 validate build and agents separately
# | Check | Complete when | Blocking |
|---|---|---|---|
9 | Configuration built to design | Every story meets its acceptance criteria and deploys as configuration rather than manual steps | Yes |
10 | User acceptance testing | Business users have signed off against acceptance criteria, with failures fixed and retested | Yes |
11 | Agent validation | Agents scored against agreed thresholds per quality dimension, in a sandbox | No |
Check 11 is new to this list and it is not the same exercise as check 10. Agent behaviour is scored across dimensions such as factuality and instruction adherence rather than passed or failed, so sign-off needs an agreed number rather than a signature. Running it inside check 10 produces a UAT cycle where testers are asked to judge something they have no criteria for.
Checks 12 to 14 convert go-live into operations
# | Check | Complete when | Blocking |
|---|---|---|---|
12 | Cutover readiness | Runbook rehearsed, rollback tested, support routes live | No |
13 | Adoption measurement | Baseline captured before go-live, review date set | No |
14 | Ownership after handover | Named owner for the backlog, for consumption, and for the next release | No |
None of these three blocks go-live, which is precisely why they get dropped. Check 14 is the one that decides whether the implementation holds its value, because an org with no named owner accumulates debt from the week the project team leaves. The cutover-specific detail sits in the go-live specific checks.
Six checks block progress; eight do not
Checks 1, 2, 3, 5, 6, 9 and 10 are gates. Fail one and the next phase produces rework rather than progress, because each is a precondition rather than a task.
The other seven are conditions. You can proceed with a known gap provided the gap is written down and owned. That distinction is what keeps a checklist usable, because a list where everything is mandatory gets abandoned the first time a project needs to move.
Apply one rule when something fails: record who accepted the gap and when it will close. An unrecorded exception becomes a disputed memory during hypercare.
Four checks 2026 added to every Salesforce implementation
Addition | What it verifies | Why it appeared |
|---|---|---|
Agent scope defined | Which agents go live, with how many subagents and actions each | Agent work is now part of most implementations rather than a later phase |
Consumption ownership agreed | That metered agent and data usage is a client cost, with an estimate | Consumption continues after the project ends and belongs in the contract |
Release calendar overlaid | Validation and cutover clear of your instance’s upgrade weekend | Salesforce upgrades on its own schedule three times a year |
Agent user permissions audited | The full object and field list the agent can read | Agent data access equals the executing user’s access |
The last one is the most serious and the least familiar. An agent inherits its user’s permissions, so the agent user’s profile is the boundary of what a customer can be told. Auditing it is a twenty-minute task that prevents a category of incident nothing else on this list catches.
Salesforce implementation checklists fail in six ways
Failure | What it looks like | Correction |
|---|---|---|
Items written as topics | Everything is ticked, nothing is verified | Give every item a completion test |
No distinction between gates and conditions | Either nothing moves, or everything does | Mark the six blocking checks |
Data profiled after the object model is set | Migration surprises appear late and cost most | Move profiling into check 5, before design closes |
Agent validation folded into UAT | Testers judge behaviour with no criteria | Score agents separately against thresholds |
Post-go-live ownership unassigned | Debt accumulates from week one | Name owners in check 14 before the team stands down |
Exceptions accepted verbally | Nobody agrees later what was waived | Record who accepted each gap and when it closes |
The Salesforce implementation checklist, condensed
Item | Detail |
|---|---|
Total checks | Fourteen, spanning scope through post-go-live ownership |
Blocking checks | 1, 2, 3, 5, 6, 9 and 10 |
Highest-return sequencing change | Profile data before the object model is fixed |
Newest additions | Agent scope, consumption ownership, release calendar, agent permission audit |
Separate validation tracks | Conventional UAT, and agent scoring against thresholds |
Completion test rule | If two people could disagree about whether it is done, rewrite it |
Exception rule | Record who accepted the gap and its closing date |
Agents run implementation checks without stopping delivery
Most of these items are verification rather than construction, which makes them the first thing dropped when a project runs late and the reason it then runs later. GetGenerative.ai runs them inside Forward Deployed Engineer pods, where the Metadata Agent handles the org assessment in check 4, the Testing Agent covers checks 10 and 11, and a senior engineer owns the gate decisions rather than a status report. If you would rather the verification happened without competing with the build, the AI-native delivery team covers how the pods are structured.
Questions teams ask about the Salesforce implementation checklist
What should a Salesforce implementation checklist include?
Fourteen checks covering objectives, decision rights, requirements, org assessment, data profiling, migration, environments, integrations, build, UAT, agent validation, cutover, adoption measurement and post-handover ownership. Each needs a completion test rather than a topic heading.
Which checks actually block a Salesforce project?
Seven: objectives, decision rights, ranked requirements, data profiling, reconciled migration, build against agreed design, and UAT sign-off. Each is a precondition, so proceeding without one produces rework rather than progress. The remaining checks can carry a documented gap.
How long does a Salesforce implementation take?
For a single cloud and straightforward configuration, five to sixteen weeks depending on user count and integrations. Multi-cloud and industry cloud programmes run considerably longer. Decision speed inside your organisation moves the number more than platform complexity does.
What is the difference between an implementation checklist and a plan?
A plan sequences work and states when each phase starts and ends. A checklist verifies that a thing is actually finished. The plan needs someone who understands dependencies; the checklist can be run by anyone, which is what makes it enforceable.
Do we need to check anything about AI agents?
If agents are in scope, yes, and three items are specific to them: agent scope definition, consumption ownership, and an audit of the agent user’s object and field permissions. Agent validation is also a separate exercise from user acceptance testing.
What happens if we fail a check?
Record who accepted the gap and the date it will close, then proceed only if the check is advisory rather than blocking. Failing a blocking check and continuing produces work that will be redone, which costs more than the delay would have.
