Salesforce implementation checklist
The ForceFolks Salesforce implementation checklist links project tasks to owners, acceptance criteria and evidence. It covers scope, architecture, data, integration, testing, training and support. Use the editable evidence sheet to record approvals and unresolved risks before each phase closes. A completed task list does not replace business sign-off or prove that go-live is safe.
Use the ForceFolks Salesforce implementation failure rate source audit to connect project controls to the evidence behind common risk claims.
1. Planning & discovery
- Define business outcomes and success metrics.
- Identify the Clouds and licenses you actually need.
- Map current processes and pain points.
- Audit any existing Salesforce org.
- Name an internal owner and decision-makers.
- Agree scope, timeline, and budget approach.
If acquisition efficiency is a goal, use the CAC reporting requirements guide to agree cost inputs, customer counts and reporting periods.
2. Architecture & design
- Design the data model and object relationships.
- Define the security and sharing model.
- Plan automation deliberately: what to automate, and how.
- Decide configuration vs custom development per requirement.
- Design integrations and system-of-record rules.
- Document the target architecture before building.
3. Data migration & integration
- Profile source data quality and volume.
- Define field mapping and de-duplication rules.
- Rehearse migration loads in a sandbox.
- Plan reconciliation of counts and values.
- Build and secure integrations with error handling.
- Test integrations with production-like data.
4. Build, test, train & go-live
- Build in source control with release management.
- Test against real scenarios and edge cases.
- Run user acceptance testing with real users and a documented Salesforce UAT testing template.
- Train owners and end users before launch.
- Launch in a controlled release, not a big bang.
- Provide hypercare support after go-live.
Check the Salesforce release dates and planning calendar against your instance schedule before agreeing preview tests and go-live.
5. Post-go-live & ownership
- Decide ownership: internal team, managed services, or both.
- Establish a backlog and enhancement cadence.
- Monitor adoption and data quality.
- Prepare for Salesforce seasonal releases.
- Keep documentation current.
- Plan the next roadmap phase.
Salesforce implementation checklist: phase exit criteria
A checked task does not prove that a phase is ready to close. ForceFolks uses exit criteria. Discovery closes when scope, owners, outcomes, and constraints are approved. Architecture closes when the data, security, integration, and release designs are documented and reviewed.
Build closes when acceptance criteria pass in a controlled environment. Migration closes when counts, relationships, and critical values reconcile. User acceptance testing closes when business owners sign the evidence and open defects are within the agreed tolerance. Go-live closes only when support ownership, rollback steps, monitoring, and communications are ready.
Add an owner, due date, evidence link, and status to every checklist item. This turns a Salesforce implementation checklist into a release control.
The roles below are starting points, not assigned project owners. Name the accountable person and agree the criteria before work begins. A phase may stay open when evidence is missing, even if every build task is complete.
On a small screen, scroll the table horizontally. Keyboard users can focus the table region and use the arrow keys.
| Phase | Accountable role to assign | Completion criterion | Evidence to attach |
|---|---|---|---|
| 1. Planning and discovery | Business sponsor | Scope, outcomes, constraints and decision owners are approved. | Approved scope and success measures, including the baseline and decision record. |
| 2. Architecture and design | Technical owner | Data, security, integration and release designs are reviewed against the agreed requirements. | Design review, access model and recorded decisions on unresolved risks. |
| 3. Data migration and integration | Data owner | Rehearsed loads reconcile within agreed tolerances; integration failure and recovery tests pass. | Mapping, reconciliation report and integration test results reviewed with the integration owner. |
| 4. Build, test, train and go-live | Release owner | Agreed tests pass or exceptions are accepted; business and technical owners approve launch readiness. | UAT sign-off, defect decisions, training record, cutover and rollback plan, monitoring and support handover. |
| 5. Post-go-live and ownership | Service owner | Live support is accepted; adoption and data-quality reviews have owners and scheduled dates. | Support acceptance, metric review and prioritized enhancement backlog. |
Download the implementation evidence sheet
The editable CSV contains the five phase-control rows above and one row marked Illustrative example only for a migration task. It is not a customer result. Remove that example and split the phase rows into your own tasks.
Each row records the task, accountable owner, completion criterion, evidence link, due date, approval status and accepted exception. Blank owner, evidence and date fields are intentional. A blank exception field means it has not been reviewed, not that an exception is approved.
Use statuses such as Not started, In progress, Ready for review, Approved, Approved with exception or Blocked. For an accepted exception, record the risk, approver, decision date, corrective action and review date. Link the approval record from the evidence field; do not mark a row approved merely because a date has arrived.
Keep detailed test cases in the existing Salesforce UAT testing template and link its signed results here. This sheet records phase decisions; it does not replace UAT execution or authorize a release.
Guidance: Salesforce Trailhead on user acceptance connects requirements, test results and stakeholder sign-off with the go/no-go decision. The phase table and CSV are ForceFolks planning aids, not Salesforce certification or proof that a project has passed.
Frequently asked questions
What is easy to overlook before a Salesforce launch?
Check data quality, user acceptance and support ownership before launch. A completed configuration does not show that users can finish their work correctly. Reconcile migrated records, test real tasks and agree who handles incidents. Record any accepted defects with an owner and a planned resolution.
Should we migrate all our data?
No. Migrate the records needed for agreed business processes and retention requirements. Assess source quality before loading them, and define what will be corrected or archived. Rehearse the migration and reconcile counts, relationships and key values. The Salesforce data migration service explains the delivery scope.
Do we need a partner for every checklist stage?
No. Your team can own some stages and commission help for specific gaps. Agree who approves architecture, tests the changes and owns the live system. ForceFolks can provide implementation delivery or team extension; the responsibility model should match the people and skills already available.
When should we start the implementation checklist?
Start before selecting a build scope or committing to a launch date. Use the checklist to identify missing decisions, data access and system dependencies during discovery. Add evidence as the project progresses. A checklist created only at go-live may expose risks too late to resolve them safely.
Who should approve a Salesforce go-live?
Named business and technical owners should approve the release against agreed criteria. They need test results, migration checks, support arrangements and a rollback plan. The delivery team supplies the evidence, while authorized owners accept the remaining risks. Record those decisions before giving production access or releasing changes.
Make Salesforce work across the business.
Tell us what Salesforce must do. ForceFolks will assess your Clouds, integrations, data, automation, team capacity, and delivery risks. You will receive a recommended path to a working implementation.