Salesforce Implementation Checklist: 10 Decisions to Make Before You Build

Most Salesforce implementation problems aren't caused by configuration mistakes. They're caused by decisions that were never made, or made by default halfway through the build. A data model chosen in week two, or a security setting left open "for now," can shape an org for years.

This checklist covers ten decisions worth settling before anyone starts building. You don't need every detail finalized, but you do need an answer, an owner and a date for each.

1. What problem is this implementation solving?

"Move to Salesforce" isn't a goal. "Every deal over $50K gets approved in Salesforce instead of by email" is. Write down three to five business outcomes, and use them to decide what makes the first release and what waits.

Decide: the outcomes, and how you'll know they've been achieved.

2. What's in the first release?

Trying to launch everything at once is one of the most common causes of delay. A smaller first release that a team actually uses beats a complete one that never goes live.

Decide: which teams and processes are in phase one, and what's explicitly deferred.

3. How does the work actually move today?

Map the real process, not the documented one: who does what, in what order, where the handoffs are, and what happens when something goes wrong. Exceptions matter most. They're where most of the design effort goes.

Decide: the process maps that the build will be measured against, approved by the people who do the work.

4. What's the data model?

Which standard objects you'll use, which custom objects you need, and how they relate. A classic early decision: one object with several record types, or separate objects? The right answer depends on whether the records share fields, processes and reports.

Decide: the objects, relationships and record types, reviewed before configuration starts.

5. Who should see what?

Retrofitting security is painful. Decide early:

• Organization-wide defaults for each object (start restrictive).
• Whether roles are needed, and what they reflect.
• How access will be granted, ideally through permission sets rather than a profile per variation.

Decide: the access model, including any sensitive fields.

6. What data moves, and how clean is it?

Data migration needs its own plan: what moves, how much history, who cleans it, and who signs it off.

Decide: the migration scope and the owner on the business side. Our data migration checklist covers the details.

7. What gets automated, and how?

Not every process should be automated in the first release. Agree on which steps Flow will handle, which stay manual for now, and the standards automation will follow: naming, one record-triggered Flow strategy per object, and how errors are handled.

Decide: the automation scope and the standards every Flow must meet.

8. What does Salesforce connect to?

Email, accounting, ERP, marketing tools, document generation, eSign, forms. List every system that needs to share data with Salesforce, which direction the data flows, and which system owns each piece of data.

Decide: the integrations in scope, and the system of record for each data type.

9. What do people need to see?

Start from the end: the reports and dashboards leadership and teams will use every week. Working backwards from reporting needs often reveals fields, picklist values and relationships the data model has to support.

Decide: the core reports and dashboards for go-live.

10. Who owns Salesforce after go-live?

Every org needs an owner: someone who prioritizes requests, approves changes and keeps the design consistent. Without one, an org drifts back into the problems it was meant to solve.

Decide: the internal owner, the admin support model, how changes are requested and approved, and how changes move from a sandbox to production.

A one-page summary

Getting started

These decisions are the core of how CRM360 starts every implementation: business requirements first, then architecture, then configuration. See how we approach Salesforce strategy and architecture and implementation, or request a consultation. If you're still choosing who to work with, our guide to choosing a Salesforce consulting partner may help.