Table of Contents
Salesforce implementation isn’t hard because the platform is complicated. It’s hard because organizations try to drag years of habits into a new system—and then blame the software when reality sets in.
After years of sorting through the aftermath, here’s what actually matters if you want Salesforce to stick.
1. Start with Business Processes, Not User Stories or Features
Almost every failed implementation begins the same way: the assumption that Salesforce is an updated version of the old system. In practice, copying “the way things have always worked” into Salesforce usually means replicating technical debt.
Pattern to avoid:
- Lifting and shifting decades of legacy steps (and the politics that go with them) into your new orr.
What works:
- We sit with the people who do the work. Map actual business flows on a whiteboard. Remove anything nobody can justify.
- We build Salesforce around what should happen—not what “always” happened before.
Forum reality:
Plenty of orgs end up with hundreds of custom fields, dozens of profiles, and an ocean of automation—most of it doing nothing except confusing everyone.
2. Custom Code as a Last Resort
Salesforce can be twisted to do almost anything, but most orgs first need to know what that anything truly means.
Pattern to avoid:
- Writing Apex to mimic old Excel workflows.
- Building custom triggers because “that’s how the legacy system worked.”
What works:
- Push hard for standardization.
- Use declarative tools unless there’s a real, high-volume business case.
- If you must code, document every choice.
Forum reality:
The orgs in trouble are almost always the ones with armies of triggers and flows, but no documentation and no one left to remember how it all works.
3. Data Migration is Never as Simple as it Looks
Data is always more complex than you think. Cleaning it up always takes longer than you expect. No one ever has as many unique IDs as they claim. Data migration is usually ignored until it’s urgent, and by then it’s late.
Pattern to avoid:
- Assuming “the partner will handle it.”
- Waiting until two weeks before go-live to look at what’s coming in.
What works:
- Prioritizing data mapping and migration from day one.
- Prototype, validate with actual users, repeat.
- Double the time you think you’ll need.
Forum reality:
Every “disaster” thread about Salesforce launches includes a surprise data meltdown.
4. Users Aren’t the Enemy—But They’re Not Psychic
Users who ignore Salesforce usually are overwhelmed, and nobody explained how the new system would actually help them.
Pattern to avoid:
- Treating end users as an afterthought.
- Relying on a single “champion” to drag everyone along.
What works:
- Involve users early and often.
- Test with them, let them break things, listen when they do.
- Build in feedback cycles, not just one-way training.
Forum reality:
Projects collapse when end users show up at go-live and realize nobody ever asked how they actually work.
5. Training is a Process, Not an Event
One-off training sessions rarely stick. PDF manuals gather dust. People forget everything in two weeks, especially when the workflows are new.
Pattern to avoid:
- “Train the trainer” models that dump everything on a single internal user.
- Relying on vendor slide decks.
What works:
- Short, frequent, context-specific refreshers.
- Office hours and feedback forms.
- Build cheat sheets based on real business cases.
Forum reality:
Most training fails not because people are incapable, but because it doesn’t reflect their actual work.
6. Documentation and Governance Matter More Than You Think
Most Salesforce issues are avoidable if documentation is owned and random requests are avoided.
Pattern to avoid:
- Granting admin rights to anyone who asks.
- Never documenting why anything was built.
What works:
- Controlled access, routine reviews, and living documentation.
- Every field, flow, or profile has an owner.
Forum reality:
Nobody wants to be the admin who inherits a mystery org with 300 profiles and no notes.
7. Integration and MDM: Start Early or Suffer Later
Every org has other systems—ERP, marketing, finance, support. Ignoring integration or pretending “we’ll figure that out in phase 2” is how you end up with conflicting data.
Pattern to avoid:
- Treating integration as a technical afterthought.
What works:
- Identify which system is the source of truth for every record type.
- Map every flow before you build anything.
Forum reality:
Trying to merge data after the fact is a nightmare—do it up front.
8. Pace Yourself: Don’t “Big Bang” or “Pilot Forever”
The most common mistake is biting off everything at once and then burning out. The opposite is launching endless pilots that never go anywhere.
Pattern to avoid:
- Implementing every feature and integration on day one.
- Never moving past phase one.
What works:
- Identify the highest impact workflows.
- Launch, learn, iterate.
Add complexity as people adapt.
9. If You Go Custom, Leave a Map
Some orgs genuinely need custom development. But code without documentation, review, or ownership is a time bomb.
Pattern to avoid:
- One-off scripts, undocumented Apex, hero admins.
What works:
- Code reviews, technical debt tracking, clear ownership.
- Handoffs that actually include the rationale and rollback plans.
Salesforce can absolutely work for complex teams. But the difference is in the discipline, process, and ownership, before, during, and after going live.
Read the forums, listen to the stories.
