Salesforce implementation mistakes, ranked by what they cost to undo

Every list of implementation mistakes is really a list of things that looked bad at go-live. The integration that fell over in the first hour, the layout nobody could navigate, the report that disagreed with finance in front of the board. Those are the ones people remember, and most of them were fixed inside a fortnight.

The mistakes that decide how the next three years go are quieter. They pass their go-live cleanly, and they only announce themselves later, as the reason a straightforward request now costs a quarter. What separates the two groups is not how serious the mistake was. It is what it costs to reverse once the org is live and holding real data.

#The only ranking that survives contact with a live org

A mistake that can be corrected in a sprint is not in the same category as one that requires a data migration, a licence renegotiation at the next contract anniversary, or retraining an entire field team. Treating them as one list, sorted by how alarming each one feels, is how a programme ends up with a governance forum for its sprint-tier problems and no forum at all for its permanent ones.

Two things set the reversal cost.

The first is how much has been built on top. A decision made in week two has three years of automation, reports, integrations and user habits resting on it by the time anyone questions it, and the reversal has to move all of that.

The second matters more, and it is the one most risk registers miss: whether the mistake structures information badly, or destroys it. A badly shaped object can be remodelled. Records can be migrated, fields deprecated, automation rewritten. None of that is cheap, but all of it is possible. A fact that was never recorded is gone. No later project recovers the date an opportunity moved stage in a year when nobody stored it.

So the tiers below are about the reversal, not about the seriousness of the original decision. Four of them, defined by what the correction actually consumes:

Sprint. A team can fix it inside a normal iteration with no data movement and no conversation above the project manager.

Quarter. It needs a piece of work with its own plan, usually a migration of configuration rather than data, and usually a period of running the old and new arrangements side by side.

Programme. It needs money that was not in the budget, a decision from somebody who was not in the project, or a commercial conversation with a vendor. These do not get fixed by the team who found them.

Permanent. The correction is a new org, or a fact that no longer exists. In practice these are not fixed at all, they are accommodated, and the accommodation is paid for by every project that follows.

#Reversal cost at a glance

Read the right-hand column as the point after which the price rises sharply, not the point after which a fix becomes impossible.

#1. Running it as a technology project with no business owner

The budget sits with IT, the procurement was a technology procurement, and the sponsor is a CIO with a delivery record. Business leaders are busy, and delegating to a capable technology function is a defensible thing for them to do. Nothing about this is careless.

It is still the most expensive mistake available, because it cannot be retrofitted. An implementation is a continuous stream of trade-offs: this team's month gets harder so that one's forecast becomes accurate, this exception is absorbed rather than automated, this process changes rather than being encoded. Each of those needs somebody whose own objectives move if the programme fails. Without that person the trade-offs still get settled, just by whoever is in the room, optimising for the thing they are measured on, which is delivery.

Appointing an owner in month nine does not undo it. They inherit decisions they did not make and would not have made, and their first honest act is to ask for changes the programme has already spent its contingency on.

Consultancies are not innocent here. A programme with one decision maker in IT moves through a statement of work faster than one that needs three business leaders to agree, and we have all enjoyed that speed. We have accepted "the sponsor is the business owner" when the sponsor's objectives were entirely about delivering on time.

The cheaper decision: before the business case is signed, name the person who will approve a process change that makes one department's month harder. If nobody will, you do not have a business owner, and the honest response is to fix that rather than to start.

#2. The data model settled by whoever reached the whiteboard first

Person Accounts, master-detail versus lookup, external IDs, how many record types exist and the org-wide sharing model are usually settled in the first fortnight, often informally, and then hold for the life of the org.

Reversal is a data migration at best, and two of those choices are effectively permanent. The decision does not live only in the schema; it lives in every report, integration, automation and permission set built on top of it since.

This one has its own piece, because it deserves more than a paragraph: the data model decisions you cannot cheaply undo covers all seven and the question that gets each one right the first time. Read that rather than a summary here.

#3. Letting the reporting requirements arrive last

Reports feel like the last mile. Build the objects, load the data, get users working, then work out how to report on it. There is a genuine reason for that sequence too: executives often cannot specify what they want to see until they have seen something.

This is the entry that destroys information, which is why it sits in the permanent tier despite looking like a late nice-to-have. Reporting requirements are data capture requirements wearing a different hat. A question about how long deals sit in each stage is a requirement to record every stage change with a date. A question about why customers churn is a requirement to capture a reason at the moment of the decision, from somebody who knows it. Arrive at those questions a year after go-live and the structure can still be added, but the first year of history cannot. It was never recorded.

The cheaper decision: before the objects are finalised, write the ten questions leadership will ask in the first board pack after go-live. For each one, name the object, field and event that has to be captured for the question to be answerable. It takes about half an hour per question and it does two jobs: it protects the history, and it kills a surprising number of fields nobody could tie to a question.

#4. Integrating to a source whose data quality nobody examined

The source is a system of record. It has run the business for eleven years. The reasonable assumption is that if the data in it were bad, somebody would have mentioned it by now.

Nobody mentions it, because everyone who uses that system has quietly learned which fields to trust and which to ignore, and that knowledge lives in their heads rather than in the data. Salesforce inherits the fields without the knowledge.

Reversal is programme scale, because bad data does not sit still. Duplicates acquire activity, automation fires on them, reports include them, users make judgements from them, and the sales team stops believing the account view. Cleaning up is not a delete pass, it is a reconciliation against a source that was never authoritative in the first place.

We have contributed to this. Profiling a source properly takes about a day per system, and a day per system is visible in an estimate at bid stage, where it makes you look slower than the firm that assumed the data was fine. The honest framing is that the day is not optional, it is either paid now or paid later at programme rates. Integration at programme level makes the wider case that the hard part of an interface is ownership rather than transport, and this is the sharpest version of it.

The cheaper decision: profile before you connect. Null rates, duplicate rates, values outside the picklist, records untouched in five years, and one conversation with the person who actually maintains the source. Then decide, deliberately, what does not come across.

#5. Customising around a process nobody has agreed to change

The process is how the business really works. The platform's standard behaviour does not fit it. The team who raised the requirement has no mandate to change how their department operates, and the project has no appetite for that argument. Customising is the path that avoids it.

Sometimes it is the right call. A process that genuinely differentiates you deserves to be built properly. The failure is narrower: building around a process nobody has examined, defended or approved, where the answer to why it works this way is that it has always worked this way.

Reversal is a programme, and it compounds. Custom work is a standing liability. It gets regression tested at every release, it constrains the shape of the next feature, and it is the reason an org cannot later adopt a standard capability without unpicking something already paid for. Two or three of these and the platform stops behaving like a platform.

The cheaper decision: for every requirement that needs custom work, name the person who could authorise doing it differently, and put the question to them once, in writing. Some will say no, and that is a good outcome. You now have a decision on the record instead of an accident encoded in Apex.

#6. Buying the licences before the process is understood

The fiscal year ends, the discount is real, and the business case needs a number to be approved at all. Buying early locks a price and unblocks the approval. Every part of that reasoning holds up on its own.

Reversal is programme scale and, unusually, it runs on somebody else's calendar. Licences do not go back mid-term. The only correction point is renewal, which may be two years out.

The subtler cost is not the shelfware. It is that an unused product with a licence attached exerts pressure on the design. Once an organisation has paid for something, solutions start bending toward justifying it, and that pressure is strongest exactly where the team is least confident, which is early.

Partners are not neutral advisers on this, ours included. Our interests and a client's are well aligned on delivery quality and imperfectly aligned on the size of the licence order. Any product mix recommendation from an implementation partner should be read with that in mind.

The cheaper decision: buy the smallest thing that lets you run discovery properly, then buy the rest against a design you have seen. If the discount expires in the meantime, the discount was never the right reason for the shape of the solution.

#7. Treating training as the adoption plan

Training is the cheapest intervention in the room to authorise. No design work, no release, no regression testing, no argument with the director who asked for the field, and one manager can book it inside a week. It gets chosen for those reasons rather than because it fits the diagnosis.

The mechanical reversal is about a quarter: diagnose properly, change what needs changing, roll it out again. What makes it dearer than that is the audience. The second attempt is not made to a neutral team. It is made to people who have already formed a view that the system takes time and returns nothing, and who spent the first month building workarounds: the spreadsheet kept alongside, the notes typed up on Friday in a batch. Those habits harden into how the team works, and unpicking a habit costs more than forming one.

Adoption is not a training problem works through the causes properly. The short version for this list: make sure something useful is returned to the person entering the data before go-live, not after.

We have sold the training day knowing the design was the problem. It is easy to sell because it is easy to buy, and it is the wrong thing to accept an order for.

#8. Building automation before agreeing who owns the process it encodes

Automation is the visible value. It is what the demo showed, it is what the business case promised, and building it is considerably more satisfying than convening a meeting about who owns a process.

Reversal is a quarter, and the cost is not the rebuild. It is that an unowned automation cannot be changed safely, because nobody can say what it was for. Six months on, the rule that reassigns records at a certain threshold looks wrong to everyone who sees it, and nobody will switch it off, because nobody knows which commitment it was protecting. That single dynamic, repeated, is how an org reaches the state where a one-field change needs a week of impact analysis.

The cheaper decision: every automation gets a named owner and one sentence of intent, recorded where the next administrator will actually look. If no owner can be found for a piece of automation, that is a finding to escalate, not an administrative gap to paper over.

#9. Permissions granted the fastest way that works

Access gets granted per urgent request rather than per job: a small targeted permission set, then a clone of it, then a clone of the clone. Each individual grant is the fastest safe action available at the time, which is precisely why it keeps happening.

Reversal is a quarter of careful additive-then-subtractive migration. It stays unfunded for years because nothing breaks loudly, right up until an audit, a departure or an incident.

Our piece on permission set debt covers how to measure it before cutting, and how to restructure without breaking Monday morning.

#10. No sandbox discipline and no release process

Early on, production is empty and changing it directly is genuinely faster. The habit forms there and survives the arrival of real data, because nothing about that arrival forces it to change.

This one is last because the mechanism is a sprint. Refresh the sandboxes, put changes through a pipeline, agree a release calendar, and the discipline exists from that day.

The drift is not a sprint. Every undocumented change made straight in production has to be discovered before it can be brought into source control, and discovery is archaeology: comparing environments, reading audit trails, asking people what they remember doing. That is why the tier is a range and why the entry still belongs on the list.

The cheaper decision: from the first sprint, nothing reaches production except through a release, even when the release contains one field. Three things make that affordable rather than ceremonial: a sandbox that is refreshed on a known schedule so people trust it, a release calendar short enough that waiting for the next one is not a hardship, and one named person who can approve an emergency change directly, on the condition that it is written down the same day. The discipline is not the tooling. It is that the fast path exists, is rare, and leaves a record.

#Using the ranking

Two practical applications, both of which change what a programme spends its attention on.

Order the risk register by reversal cost rather than by likelihood times impact. The standard scoring reliably ranks a probable, annoying, sprint-tier problem above an improbable permanent constraint, because the permanent one has no incident to attach a probability to yet. Add a column for what reversal would take, and the register reorders itself in a way that matches where the money actually goes.

At each stage gate, ask which decisions taken this month cannot be taken again. It is one question, it takes ten minutes, and it is the only reliable way to catch a permanent-tier decision while it is still a conversation rather than a build.

None of this argues for a longer discovery phase. Long discovery produces documents, and documents are not decisions. It argues for identifying the handful of decisions in a programme that are genuinely one-way, putting them in front of somebody with the authority to settle them, and letting everything else stay changeable, which on this platform most things are.