A practical Salesforce implementation checklist covering process design, data, permissions, integrations, automation, reporting, testing and adoption.
A Salesforce implementation can fail even when the platform is configured correctly. The usual problem is that the CRM reflects an imagined process instead of the way sales, service and customer data actually move through the business.
Use this checklist before implementation, migration or a major Salesforce redesign.
1. Define the operating process first
Document the real stages of the customer journey:
- lead creation;
- qualification;
- ownership;
- opportunity progression;
- approvals;
- handoff to delivery or service;
- renewals or repeat business;
- reporting.
For each stage, define who owns it, what information is required and what should happen next.
2. Decide which system owns each data object
A CRM rarely works alone.
Customer, order, invoice, product, support and marketing data may live across Salesforce, SAP, ecommerce, websites, service tools and analytics platforms.
For every important object, define:
- system of record;
- create/update authority;
- sync direction;
- conflict handling;
- expected latency;
- audit requirements.
This prevents the integration layer from becoming a collection of one-off field mappings.
3. Clean the data model before migrating data
Do not reproduce years of inconsistency in a new or redesigned org.
Review:
- duplicate fields;
- unused fields;
- inconsistent picklists;
- duplicate contacts/accounts;
- missing ownership;
- historical values that no longer mean anything;
- records that do not need to migrate.
Migration is an opportunity to simplify.
4. Design permissions deliberately
Avoid giving broad access simply because it is easier during implementation.
Define:
- roles;
- profiles/permission sets;
- sensitive data access;
- admin boundaries;
- integration-user permissions;
- reporting visibility;
- separation of duties where required.
5. Keep automation understandable
Automation creates leverage, but unmanaged automation creates hidden complexity.
Before adding flows, triggers or external automation, document:
- business rule;
- trigger;
- expected outcome;
- exception path;
- owner;
- logging;
- dependency on other automation.
If nobody can explain why an automation exists, it becomes operational debt.
6. Design integrations around business events
Instead of asking only “which fields should sync?”, ask “what business event occurred?”
Examples:
- opportunity won;
- customer created;
- order paid;
- subscription changed;
- support case escalated;
- invoice overdue.
Events make integration logic easier to reason about than uncontrolled bidirectional synchronization.
For broader architecture, see enterprise technology services.
7. Define reporting before go-live
If leadership expects a dashboard, define the logic before implementation finishes.
Clarify:
- pipeline definitions;
- stage conversion;
- source attribution;
- sales-cycle calculation;
- forecast categories;
- revenue ownership;
- service metrics.
A dashboard cannot fix ambiguous process definitions.
8. Test complete workflows, not isolated fields
User acceptance testing should simulate real journeys.
A test might start with a new lead and continue through:
- assignment;
- qualification;
- opportunity creation;
- approval;
- integration to another system;
- notification;
- reporting.
This catches problems that unit-level configuration checks miss.
9. Plan adoption as part of the implementation
Users avoid a CRM when it creates extra work without helping them complete their job.
Reduce unnecessary fields, automate obvious repetitive steps, make important information visible and train around actual workflows rather than generic platform features.
10. Define post-launch ownership
Before launch, assign responsibility for:
- admin requests;
- access changes;
- data quality;
- integration failures;
- release management;
- automation changes;
- reporting changes;
- backlog prioritization.
When should Salesforce be customized?
Customize when the business requirement creates meaningful value and standard configuration cannot support it cleanly.
Do not customize simply because the platform makes customization possible.
A good design question is:
Will this customization simplify the operating process, or will it make future change harder?
When should Salesforce integrate with custom software?
Common situations include:
- customer portals;
- product applications;
- ecommerce platforms;
- internal operational systems;
- billing systems;
- ERP;
- analytics;
- AI assistants.
Our software development services and Salesforce consulting services are designed to work together where the CRM is only one part of the system.
Final implementation gate
Before go-live, verify:
- process ownership is clear;
- system-of-record decisions are documented;
- data quality is acceptable;
- permissions are tested;
- integrations have failure handling;
- automation has owners;
- reports match agreed definitions;
- users completed workflow-based UAT;
- support ownership is assigned.
Salesforce becomes useful when it reduces uncertainty in revenue and service operations. The goal is not to create the most sophisticated org. The goal is to make the business process easier to run, measure and improve.
Turn the insight into an operating decision.