Ninety days in and the project already feels harder than it should.
Not broken — nothing has catastrophically failed. But the velocity that felt possible during the sales cycle and the kickoff meeting has quietly disappeared. Stakeholders are asking questions that were supposed to be answered in discovery. The data migration is taking three times longer than estimated. The sales team that was supposed to be the primary user group has gone quiet in a way that doesn't feel like satisfaction. And somehow, despite weeks of configuration work, the thing that the VP of Sales actually wanted isn't quite done yet.
This is not a rare story. It's the default story for Salesforce implementations that didn't get the foundational decisions right early. The first ninety days of a Salesforce project contain a set of decisions — some obvious, some invisible — that determine whether the next twelve months are productive or painful. Most projects make at least two or three of the same mistakes. Some make all of them.
Whether you're running an implementation internally or working with a certified Salesforce development company to deliver it, understanding what goes wrong early is how you avoid it.
Discovery That Stops at the Surface
The biggest mistake people make when setting up Salesforce happens before they even start using it.
The goal of the discovery process is to figure out what the business really needs. This means looking at the processes that are in place the way data is related and the workflows that people use every day. A lot of these workflows are done in spreadsheets and email. They have never been written down because they have just always been done that way.
To do discovery properly it takes time. Involves the people who will actually be using the system. This process often turns up things that surprise everyone, including the people who thought they knew how things worked.
What usually happens is that there are a meetings with the senior people and then a document is written that says what they think the system should do. A plan is made based on this document. It is not complete.
The difference between what the leaders think the sales process is and what the salespeople actually do is usually bigger than the leaders think. The difference between what the rules say people should do and what they actually do is even bigger. If the discovery process does not talk to the people who do the day-to-day work it will miss these differences.
When the system is being set up and a salesperson sees it for the time they might say that the way the system handles sales does not match how they actually do their job. This is an example of a discovery failure. It causes problems that have to be fixed. The cost of fixing these problems is always higher than it would have been to do the discovery process in the first place.
The Salesforce implementation is where this mistake happens and it is related to the discovery process. The discovery process is important, for the Salesforce implementation. It should be done carefully to avoid mistakes. The Salesforce implementation will be better if the discovery process is thorough and it will save time and money in the run.
Configuring Before the Data Model Is Settled
Salesforce configuration is not linear. Objects relate to each other. Automation references fields. Page layouts depend on object structure. Reports depend on field names and relationships. Everything connects to everything else in ways that aren't always obvious until you're deep in it.
Teams that start configuring workflows and automation before the underlying data model is stable spend significant time reworking things that referenced fields or relationships that subsequently changed. A validation rule built on a field that gets renamed. An automation that references a picklist value that gets consolidated. A report built on a relationship that gets restructured. Each of these is individually a small fix. Collectively, across a complex implementation, they add up to weeks.
The discipline that prevents this is straightforward — get the object model, the key fields, and the primary relationships reviewed and signed off before building anything that references them. Not just reviewed by the project team. Signed off by the stakeholders who will later say "actually we need to track it differently."
This requires stakeholders to make decisions earlier than they're often comfortable making them. A good implementation partner pushes for those decisions rather than deferring them. Deferred decisions in Salesforce implementations don't stay deferred — they resurface as rework.
Treating Data Migration as a Phase Four Problem
Here's a specific belief that derails a surprising number of Salesforce projects: that data migration can be properly scoped and executed after the configuration is done.
The logic seems reasonable. You configure the system, then you move the data into it. Sequential, clean.
The problem is that data migration informs configuration decisions that are made in weeks one through eight. What fields need to exist depends on what data is being migrated. What that data looks like — its quality, its structure, its completeness — affects how the data model needs to be built to accommodate it. Legacy data that doesn't fit cleanly into the new data model requires transformation logic, and that transformation logic has implications for the configuration.
Teams that start their data audit late discover these implications late — after configuration decisions have already been made that don't accommodate the actual data. The result is either retrofitting the configuration to handle data realities that weren't accounted for, or accepting data migration compromises that leave the new system populated with records that don't fully work.
Start the data audit in week one. Not the migration — the audit. Understand what you have, what condition it's in, what transformations will be required, and what fields need to exist in Salesforce to hold it. Let that understanding inform the configuration from the beginning.
Too Much Customization Too Soon
Salesforce is a platform that rewards setup. Using point-and-click tools, automation with Flow and standard features that cover a lot of needs without writing code. It also supports making things custom with Apex, Visualforce and Lightning Web Components for needs that can't be met with setup.
The temptation when first starting is to jump to custom code fast. A need comes up that seems to need custom code. Of fully checking what's possible with easy setup the project moves to Apex. Then another need gets the treatment. Then another.
Custom code in Salesforce isn't free. It needs to be kept up tested and updated when Salesforce changes things. It makes the system more complicated for every developer to understand before making changes. It creates risk when Salesforces releases change things that the custom code relies on.
Simply: Salesforces easy setup tools have gotten really powerful. Flow can handle automation that used to require custom code. Many needs that seem to need custom code don't when someone with Salesforce knowledge checks them.
The discipline thats worth enforcing on: every need that someone suggests solving with custom code gets a real evaluation of whether it can be met with easy setup. Not a quick no. An evaluation by someone who knows what Flow and the standard platform can do. Custom code that gets written because nobody thought hard about the easy setup alternative is some of the most expensive problems, in a Salesforce system.
User Adoption Gets Planned Last
This one is almost universal and almost always costly.
The system gets built. It goes through UAT. It launches. And then it becomes apparent that the people who are supposed to use it — the salespeople, the service agents, the operations team — aren't using it the way it was designed, aren't entering data consistently, and in some cases are actively working around it with the same spreadsheets and email threads the implementation was supposed to replace.
User adoption is not a training problem that gets solved in a two-hour session the week before go-live. It's a change management process that starts during discovery and runs through and after launch. The users who will live in the system every day need to be involved in the design decisions, not presented with a finished system and asked to adapt.
Specifically: the salespeople who will be entering opportunity data should have weighed in on the opportunity stages. The service agents who will be working cases should have influenced the case statuses and the page layout. Not final authority — that creates its own problems — but genuine input that gets incorporated into the design.
When users feel like the system was built with their actual workflow in mind, adoption is a conversation. When they feel like they're being asked to change how they work to accommodate a system that was designed without them, adoption is a battle.
Governance Nobody Thought to Establish
Six months after go-live, someone needs to add a field. Two different people make the change in two different sandboxes. Both changes get deployed and one overwrites the other. A report that was working stops working and nobody knows why. A validation rule gets changed by someone who didn't realize three other automations depended on its behavior.
Salesforce orgs without governance decay. Not slowly — quickly. Every person with System Administrator access making independent changes to a shared configuration is a recipe for an org that becomes progressively harder to reason about and maintain.
Governance in a Salesforce org means: who can make what kinds of changes, what process do changes go through before they're deployed to production, how is the org documented, and how are changes communicated to the people whose work depends on the configurations being stable.
None of this is complicated. All of it needs to be established early, because establishing it after the org has been running ungoverned for six months means untangling the consequences of six months of independent changes before you can implement the governance going forward.
The Partner Question
Most of these mistakes are more common in implementations run entirely by internal teams without Salesforce-specific expertise. Not because internal teams are less capable — but because the mistakes are the kind you make the first time, and experienced implementation partners have made them, seen them made, and built processes specifically to prevent them.
That said, an implementation partner doesn't automatically prevent any of this. A partner that runs lightweight discovery to keep the engagement scoped, defers difficult data migration questions, and builds whatever the client asks for without pushing back on customization decisions is participating in the same failure modes.
The value a good partner brings is judgment and pushback — knowing when to slow down the configuration work to get the data model right, knowing when a stakeholder's stated requirement doesn't reflect what they actually need, knowing when a requirement that seems to need custom code can be met declaratively, and being willing to have those conversations even when the client wants to move faster.
Working with a certified Salesforce development company like Hyperlink InfoSystem means the first ninety days are structured around the decisions that determine the next twelve months — not around moving fast on the wrong things.
The first ninety days of a Salesforce implementation aren't where the value gets delivered. They're where the conditions for value get established — or don't. The projects that look effortless in months six through twelve almost always made the hard decisions correctly in months one through three.
The ones still reworking configuration a year in usually didn't.
Top comments (0)