Salesforce implementations fail in predictable ways. The platform is rarely the problem; it is flexible enough to model almost any business. The problems are the decisions made around it — scope that was never pinned down, data migrated without being cleaned, customisation layered on until nobody understands the org, and a sales team that was handed a system they had no part in shaping. We have audited enough troubled orgs to see the same handful of mistakes over and over. This is the list, with what to do instead.
Pitfall 1: Starting without defined processes
Salesforce is a tool for running a process. If the process does not exist — if "how do we qualify a lead" or "when does an opportunity move to the next stage" has a different answer from every salesperson — the implementation either encodes the confusion or invents a process nobody agreed to. Both fail at adoption.
The symptom of this pitfall is a discovery workshop where the answer to every process question is "it depends", and a configuration team that fills the gaps with defaults. The defaults are then wrong for everyone.
Before configuration begins, write down the sales, service and marketing processes as they should work: the stages, the criteria for moving between them, who does what, and what a manager needs to see. This is a business exercise, not a technical one, and it is the single highest-leverage week in the whole project. The configuration then has something to be right about.
Pitfall 2: Scope that grows in every meeting
Every stakeholder who sees a Salesforce demo has an idea. Most of the ideas are good, and adding all of them to the first release is how a three-month project becomes a year-long one that ships nothing. Scope creep on a CRM is especially damaging because the people waiting for it are the revenue team, and every month of delay is a month they run on spreadsheets.
Define a first release that covers the core process end to end — leads to opportunities to closed deals, or cases to resolution — and nothing else. Park every other idea in a backlog with a name next to it. Ship the first release, get people using it, and let real usage rank the backlog. A working CRM in three months with ten improvements queued beats a perfect one in twelve.
Pitfall 3: Migrating dirty data
Whatever is in the old system — duplicates, dead contacts, inconsistent picklist values, notes in the wrong fields, accounts with three spellings — moves into Salesforce and becomes permanent. Users open the new system, find the same mess with a new interface, and conclude the project changed nothing. Reports built on bad data give bad answers, and trust in the system erodes from the first week.
- Profile the source data before planning the migration: duplicate rates, empty fields, invalid values
- Decide what not to migrate — closed deals from five years ago and contacts nobody has emailed since are usually better archived
- Clean and deduplicate before loading, with clear rules for merging
- Map every field explicitly and validate a test load with real users before the real one
- Set up duplicate rules and validation in Salesforce so the data stays clean after go-live
Pitfall 4: Over-customising
Salesforce can be bent to almost any shape, and the temptation is to reproduce the old system exactly — every field, every screen, every quirk — through custom objects, Apex code and flows. The result is an org that is expensive to change, breaks on platform releases, and depends on the one developer who understands it. It also usually reproduces the problems the old system had.
Use standard objects and features first and customise only where the business genuinely differs. Prefer declarative tools — flows, validation rules, page layouts — over code, because they are visible to administrators and survive upgrades better. When code is necessary, document why, test it properly, and keep it small. Every custom element should earn its place with a reason someone can explain in a sentence.
Pitfall 5: Ignoring integration until the end
A CRM that does not talk to the billing system, the marketing platform, the support desk and the product database becomes another place to re-type things, and re-typing is what people stop doing first. Integration is regularly left for "phase two" and then discovered to be the hardest part of the project, because the other systems have their own data models and their own owners.
Identify every system Salesforce needs to exchange data with in the planning phase. Decide which system owns each piece of data — the customer record, the invoice, the product catalogue — so there is one source of truth and the others sync from it. Choose integration tooling that the team can maintain, and build the critical integrations into the first release rather than after it.
Pitfall 6: Weak security and access design
Profiles, permission sets, roles, sharing rules and field-level security are how Salesforce decides who sees what, and they are frequently set up in a hurry with everyone as a system administrator. That is a data breach waiting for a departing employee, and a compliance problem for any business handling personal data.
- Design roles and permission sets around actual jobs, following least privilege
- Enforce multi-factor authentication for every user — it is required, and it is the single most effective control
- Restrict sensitive fields at the field level, not just at the object level
- Review who has admin rights quarterly and remove what is not needed
- Turn on login monitoring and audit trails from day one
Pitfall 7: Treating adoption as a training problem
The implementation is finished when the sales team uses the system every day without being chased, not when the configuration is deployed. Adoption fails when the system makes people's jobs harder — more fields, more clicks, reports that only help managers — and no amount of training fixes a tool people do not want to use.
Involve the people who will use it from the start: watch how they work, design the screens around their day, and cut every field that does not serve them or a report someone actually reads. Give them something back — automated follow-ups, mobile access, less admin — so the system is visibly worth the change. Then train on real scenarios, appoint champions within each team, and measure usage weekly after go-live so problems surface early.
Pitfall 8: No plan for after go-live
Salesforce is not a project with an end date. Three platform releases a year, changing business needs, new integrations and the steady accumulation of small requests all need an owner. Orgs without one drift: reports stop matching reality, automations break silently, and within two years the business is talking about re-implementing.
Assign an administrator with time in their week for the system, keep a backlog and a release rhythm, review platform release notes, and maintain a sandbox for testing changes before they reach production. Budget for this from the start, because it is part of the cost of the system and not an optional extra.
Pitfall 9: Reports designed last
Reporting is usually the reason leadership approved the project, and it is usually the last thing configured — at which point the team discovers that the data needed for the pipeline report was never captured, or was captured in a free-text field nobody can aggregate. Start from the reports: list the five questions leadership needs answered every week, work backwards to the fields and stages that answer them, and make sure the process captures those fields as a natural part of the work rather than as extra admin. A dashboard that the sales director opens every Monday is also the strongest adoption tool you have, because it makes the system's data visibly matter.
Frequently asked questions
How long should a Salesforce implementation take?
A focused first release for a small or mid-sized sales team — core objects, a clean migration, essential integrations and training — typically takes two to four months. Larger organisations, multiple clouds or complex integrations take longer and should be delivered in phases rather than as one launch.
Should we implement Salesforce ourselves or use a partner?
Simple configurations of standard features can be done in-house with a capable administrator. Data migration, integrations, security design and anything requiring code benefit from a partner who has done it before, because the mistakes above are expensive to discover for the first time on your own system.
What is the most common reason implementations fail?
Adoption. The configuration usually works; the people do not use it because it was designed without them and makes their day harder. Involving the users early and shipping something small that helps them is the strongest predictor of success.
Inverge Tech implements Salesforce for clients, and we spend a good share of our time rescuing implementations that fell into the traps above. If you are starting one, we can help you avoid them; if you are in one, we can help you get out.