Salesforce implementations that fail rarely do it in one event. They fail through a series of decisions that each looked reasonable, most of them taken in the first weeks, before anything was built. The platform itself is seldom the cause. The damage comes from what was automated without question, from shared data nobody owns, from connections built in a hurry, and from treating low adoption as something a classroom can fix.
Discovery automates what nobody questioned
Requirements gathering is often run as transcription. Business stakeholders describe their current process, consultants turn it into user stories, and nobody with authority asks whether the process deserves to be automated at all. The configuration then mirrors a broken process with great fidelity: Flows that replicate manual workarounds, object relationships that encode the org chart, validation rules that enforce exceptions as if they were the rule.
The missing role is a design authority who can say no, someone entitled to reject a requirement and not only record it. When discovery is staffed with analysts and the people who own the design arrive after scope is locked, the gap between what was specified and what the platform can sustain is already in the plan. Nobody will see it until the build.
Nobody owns the shared objects
The standard Salesforce data model carries assumptions about how accounts, contacts and opportunities relate. When the business works differently, the reflex is to customise: custom objects, custom relationships, junction objects on top of junction objects. Customising is fine when someone models the consequences. Decided field by field, it raises the cost of every later change, from integrations and reports to each Flow that touches the records.
Governance gaps make the drift faster. Several teams deploy without coordination, sandboxes do not reflect production volumes, releases overwrite each other, and no one owns the objects every team uses. Sales customises Account for its workflow, Service customises it for its own, and the object keeps collecting fields nobody can explain.
What works is an ownership model more than a committee: a named owner for each shared object, a review whenever a change affects more than one team, and the data model treated as a design document, reviewed before configuration starts, with every deviation from standard objects written down with its reason.
The phase two that never comes
Integration is where a manageable failure becomes an expensive one. Point-to-point connections get built during the first release because they are faster than setting up a middleware layer, and the layer moves to phase two. Phase two rarely arrives. The org collects direct connections (ERP, marketing platform, data warehouse), each with its own authentication, error handling and retry logic.
When one breaks, nothing alerts anyone until a business process stops. The admin gets a ticket saying the data is wrong and has to work out which connection caused it. Each new system then means touching every connection that shares its data, and replacing the ERP turns into a project about untangling connections.
A sponsor does not need to choose the middleware. The sponsor needs to decide, before the first release, whether integrations get a monitored contract boundary, and who owns each connection, its credentials and its failure alerts. A phase two with no date and no budget is a decision not to do it, and it should be recorded as one.
When adoption is treated as a training problem
Low adoption is regularly misdiagnosed. The standard response is more training, better documentation, a message from leadership. I teach Salesforce (administration and Service Cloud courses for PLB; for Capgemini, tool training of AXA agency teams), and a classroom has a clear limit: it shows people how the system works. It cannot make a process nobody owns worth following.
Adoption failures usually trace back to design. The system does not match how people work, because requirements came from managers rather than from the people doing the work. Or it is slower than the workaround it replaced, because the data model is heavy and the page is buried in fields. Or it gives users nothing new, because it was scoped around capturing data for reporting.
Treat adoption as a design constraint. Every required field and every extra screen is friction, and during design someone should ask what business outcome justifies it. When the answer is “we need it for reporting”, the next question is whether the data can be captured without asking the user to type it.
Diagnose before prescribing
These causes rarely come alone. A data model problem sits next to a governance gap; an integration problem feeds an adoption problem, because users stop trusting data that arrives late or wrong. The first deliverable for a troubled programme is therefore a diagnosis that ranks problems by what they block, rather than a list of everything that is wrong.
The cheapest moment for that diagnosis is before the integrator is chosen. At Disneyland Paris in 2022, I audited the B2B processes and wrote a Salesforce target before the integrator was selected. Integrators were then compared against a written target instead of being asked to discover the scope during the build.
For a programme already in trouble, the same triage applies: find the problem that blocks the others, often the data model because reporting, automation and integrations all depend on it, and sequence the rest behind it. The org review checklist lists the five areas to read, and the note on project rescue covers the first 90 days of recovery.
What to check
- Discovery includes a design authority who can reject a requirement, not only record it.
- Every shared object, starting with Account and Contact, has a named owner.
- Each deviation from standard objects is written down with its reason.
- “Phase two” for integrations has a date, a budget and an owner.
- When adoption is low, someone checked the process before booking more training.