Most Salesforce implementations that fail do so for avoidable, business reasons: no one owns decisions, the first release tries to do too much, old processes and dirty data are copied straight across, and launch is treated as the finish line. Each of these mistakes shows an early warning sign weeks before it becomes expensive. This guide lists the 15 we see most often, grouped by project phase, with the warning sign for each and what to do instead.
The 15 mistakes at a glance
| Mistake | Early warning sign | What to do instead |
|---|---|---|
| 1. No single decision owner | The same question comes back to every meeting | Name one business owner per area with authority to decide |
| 2. Vague success measures | Nobody can say what “done” looks like | Agree two or three measurable outcomes before discovery |
| 3. Buying licenses before scoping | Licenses sit unused or the edition lacks a needed feature | Scope first, then buy the editions and add-ons the design needs |
| 4. Rebuilding the old system | Requirements describe today’s screens field by field | Design the future process, then map only what still matters |
| 5. Designing for every exception | Rare edge cases drive the data model | Design for the common path; handle rare cases manually at first |
| 6. Leaving security and sharing until late | Access questions surface during testing | Design roles, sharing and permission sets in the design phase |
| 7. Underestimating integrations | The ERP or other system owner has not been in a meeting | Inventory every integration early and confirm each owner’s calendar |
| 8. Customizing before configuring | Custom code is proposed for routine requirements | Use standard objects and Flow first; justify every custom component |
| 9. Automation sprawl | Several flows or triggers fire on the same object and event | Agree an automation pattern and keep one place per object |
| 10. No release process | Changes are made directly in production | Build in sandboxes and promote through a defined release path |
| 11. Migrating dirty data unchanged | Duplicate and incomplete records appear in testing | Clean, de-duplicate and validate in the source before migrating |
| 12. Moving all history | The migration plan includes records nobody has opened in years | Set a cutoff and archive the rest outside Salesforce |
| 13. Skipping real user testing | Testing is done only by the project team | Give real users real scenarios and time to test before sign-off |
| 14. Training on clicks, not work | Training is a feature tour for everyone at once | Train by role, on the tasks each person does every day |
| 15. No owner after go-live | The partner leaves and nobody can make changes | Plan the admin, managed services or roadmap before launch |
Mistakes before the project starts
1. Nobody on your side owns the decisions
Salesforce projects run on decisions: which stages an opportunity moves through, who owns a case, what counts as a qualified lead. When several stakeholders each hold a veto and nobody holds the final say, decisions stall or get reversed, and the partner builds, then rebuilds. The warning sign is a question that comes back to every meeting. Prevent it by naming one business owner for each area, with the authority and the time to decide, and a standing slot each week where open decisions get settled.
2. Success is never defined
If the goal is “get onto Salesforce”, the project ends at go-live whether or not anything improved. Agree two or three measurable outcomes before discovery, such as the share of pipeline forecast in Salesforce, time to first response on cases, or hours of manual reporting removed. They guide scope decisions during the project and tell you afterward whether it worked.
3. Buying licenses before scoping the work
It is common to buy licenses during the sales cycle, before anyone knows exactly what the design needs. The result is either paying for users and add-ons nobody uses, or discovering mid-project that the edition lacks a feature the design depends on. Scope first, at least at a high level, then buy the editions, user counts and add-ons the design calls for. If the licenses are already bought, make sure the design works within them.
Mistakes in discovery and design
4. Rebuilding the old system in Salesforce
Requirements that read like a description of the current tool, screen by screen and field by field, produce an expensive copy of the old system with the same problems. Start from the process and the decisions it supports, design how it should work, and then map across only the data and steps that still matter. This is where much of the value of a new platform comes from.
5. Designing for every exception
Every business has rare cases: the unusual contract, the one customer with special pricing. Designing the data model and automation around them makes the system complicated for everyone, every day. Design for the common path first. Handle rare cases manually or with a simple flag until you know how often they happen, and automate them later if the volume justifies it.
6. Leaving security and sharing until the end
Who can see and edit which records is one of the hardest things to change after data is loaded and people are working. When sharing is left until testing, teams discover that managers cannot see their reports’ deals, or that sensitive records are visible to everyone. Design roles, sharing rules and permission sets during the design phase, test them with real user profiles, and document the reasoning so the next admin can maintain it.
7. Underestimating integrations
Integrations are where timelines most often break, because they depend on another system, another team and sometimes another vendor. The warning sign is an integration in the plan whose owner has never been in a project meeting. Inventory every connection early: what data moves, in which direction, how often, and who owns each end. Confirm that the other team has time and a test environment when you need them.
Mistakes during the build
8. Customizing before configuring
Custom Apex and Lightning Web Components are powerful, and sometimes they are the right answer. But each custom component has to be designed, tested, maintained and understood by whoever looks after the org next. When custom code is proposed for routine requirements, ask whether standard objects, Flow or page layouts could do it. A useful test is whether the next admin could maintain it.
9. Letting automation sprawl
It is easy to end up with several flows, old workflow rules and triggers all acting on the same object and event, sometimes in conflict. The symptoms are records that change unexpectedly, errors that are hard to trace and saves that slow down. Agree an automation pattern at the start, keep one place per object where automation is orchestrated, and retire legacy workflow rules and Process Builder as you go.
10. Building without a release process
Making changes directly in production feels fast until a change breaks something people depend on. Build and test in sandboxes, promote changes through a defined release path, and keep a simple record of what changed and why. This matters even more after launch, when every change affects people at work.
Mistakes with data
11. Migrating dirty data unchanged
Duplicates, missing owners, inconsistent picklist values and stale records all arrive in Salesforce if they are migrated as they are, and they undermine trust from day one. People who see duplicate accounts or wrong numbers on day one go back to spreadsheets. Clean and de-duplicate in the source system before migrating, validate a sample after each rehearsal, and set duplicate and validation rules so the problems do not come back.
12. Moving all of your history
Moving every record ever created makes migration slower, testing harder and storage costlier, and much of it is never opened. Decide a cutoff with the business: for example open records plus a set number of years of closed history. Archive the rest outside Salesforce where it can still be found if needed.
Mistakes at launch and after
13. Skipping real user acceptance testing
When only the project team tests, the system works for the people who designed it. Real users bring the exceptions, shortcuts and questions nobody wrote down. Give people from each team real scenarios, real data in a sandbox and protected time to test, and do not sign off until they have. Squeezing this phase does not save time; it moves the defects into production.
14. Training on features instead of daily work
A single feature tour for everyone at once is forgotten within a week. Train by role, on the tasks each person does every day, in the order they do them. Provide short guides for the most common tasks, name a go-to person in each team, and plan refresher sessions for a few weeks after launch, when people know what they actually need to ask.
15. No owner once the project ends
Treating go-live as the finish line is the most expensive mistake on this list. Requests pile up, small problems go unfixed and the system drifts away from how the business works. Before launch, decide who owns Salesforce afterward: an in-house admin, managed services from a partner, or a mix, and keep a prioritized backlog for the next release.
What does a failed implementation look like in practice?
One industrial-services firm came to us after a previous partner delivered a Field Service system, for over $100,000, that the company could not use. Scheduling errored on any project longer than 15 days, flows fired 30 emails at once, and the only way to track roughly 100 field workers was to pay for a Salesforce license for each of them. Two of those map directly to this list: automation that fired 30 emails at once (mistake 9) and a design that needed a paid license for every worker (mistake 3). The system was not rebuilt from scratch: within a 20-hour engagement the multi-day scheduling was fixed, the task flows were restructured, and a custom object let the company track 75 to 100 contract laborers without per-worker licenses.
The opposite pattern shows up in projects that go smoothly. A compliance-software company moved from HubSpot to Salesforce in four to six weeks with clear marketing-to-sales handoffs, and a manufacturer reached full adoption by 99 reps within 30 days. In both cases the scope of the first release was contained, data was prepared before it moved, and adoption was planned as part of the project.
How do you know if your project is already going wrong?
- The go-live date has moved more than once without a firm new date.
- Design decisions keep reopening after sign-off.
- Data problems are being discovered in testing rather than before it.
- An integration is behind and its owner is not in project meetings.
- Testing has been shortened to protect the date.
- After launch, people are keeping their own spreadsheets alongside Salesforce.
If several of these are true, a short independent assessment is usually cheaper than pressing on. Our guide to rescuing a failed Salesforce implementation explains how to decide what to keep, fix or rebuild, and a Salesforce health check gives you an objective view of the current state.
A prevention checklist for each role
Most of these mistakes are prevented by a few people doing their part. Share this with the people who hold each role.
For the executive sponsor
- Name one decision owner per area and back their decisions.
- Agree two or three measurable outcomes and review them at each milestone.
- Protect the time of the people who must attend workshops and testing.
- Decide early whether the date or the scope matters more, and say so.
For your project lead
- Keep a decision log and a visible list of open questions with owners and dates.
- Track your side’s commitments: data, testers, approvals and integration owners.
- Route every new request through the change process, however small.
- Plan training by role and confirm who owns Salesforce after launch.
For the implementation partner
- Challenge requirements that copy the old system or chase rare exceptions.
- Design security, sharing and automation patterns before building.
- Surface data and integration risks in discovery, not in testing.
- Build in sandboxes, release through a defined path and document as you go.
Frequently asked questions about Salesforce implementation mistakes
What is the most common reason Salesforce implementations fail?
Unclear ownership of decisions and requirements. When nobody on the client side can settle process questions, scope drifts, design reopens and the build stalls. Technology problems are far less common causes than people and process ones.
Can a failed Salesforce implementation be fixed without starting over?
Usually, yes. Most failed implementations have a working core that can be kept. An assessment separates what works from what does not, and a keep, fix or rebuild decision is made area by area rather than for the whole org.
How do you prevent scope creep on a Salesforce project?
Agree a written scope with an explicit out-of-scope list, keep a backlog for good ideas that are not in the first release, and route every new request through a change process that shows its effect on the timeline. Scope creep is rarely one big change; it is many small ones nobody wrote down.
Should we use a phased rollout or launch everything at once?
For anything beyond a single team and cloud, a phased rollout is usually safer. It proves the design with real users, surfaces data problems early and builds support before the wider launch.
