Salesforce rescue: inherited a build nobody trusts?
A good share of Ignyto’s work starts with a Salesforce build somebody else walked away from. The route out is the same four steps every time, and the first one is free: health check, stabilise, rebuild, run. Ignyto is a Salesforce Summit partner with 115 certifications across 35+ people, and has recovered implementations for clients in regulated financial services, manufacturing, healthcare and property across the UK and Ireland. Picture a platform your team stops working around: reports they believe without checking, automation that runs, and something you can build on again.
Most of these implementations failed in the year after go-live.
Failed Salesforce implementations rarely fail at go-live. They fail in the year afterwards, when a workaround becomes the process, an integration starts creating duplicates instead of updating records, and each new request is built on top of the last one rather than instead of it.
By the time someone calls it a rescue, the technical problem is usually smaller than the trust problem. People have stopped believing the reports, so they keep their own numbers, so the reports get worse. That loop is what a rescue has to break, and it is why the first step produces a written picture rather than a change.
Ignyto will also tell you when the answer is smaller than you feared. Not every distrusted build needs rebuilding — some need three fixes and a reporting layer people can follow.
How to tell a build needs rescuing.
Your team keeps the real numbers in a spreadsheet and uses Salesforce to record what already happened.
Nobody can say who configured a given automation, or why.
A previous partner has stopped answering, or the implementation stopped mid-build.
Reports contradict each other, so leadership has quietly stopped using them.
Adoption is low and the internal explanation has become that the team resists change.
You are paying for licences, add-ons or an integration nobody can point to a user for.
Three or more of these and the problem is structural rather than a training issue. If AI is also on the agenda, run the Agentforce readiness assessment first — an agent grounded in a build like this answers confidently and wrongly.
Four steps, in this order.
What you actually own
Free, and read-only: what is configured, what is in use, what is quietly broken, and what is costing you licence money for nothing. You get it in writing, whether or not you go further with Ignyto.
Stop the bleeding first
The automations that misfire, the integration that creates records instead of updating them, the permissions nobody set deliberately. Nothing is rebuilt yet — the point is that it stops getting worse while you decide.
Only the parts that need it
Scoped as user stories with the effort against each one, so you can see what you are buying before you buy it. Some of what a previous partner built is usually worth keeping, and we will tell you which.
Keep it from drifting back
Managed services from the same people who did the rebuild, aimed at preventing the next rescue rather than selling you one.
Each step ends in a decision you make, not a commitment you inherit. The health check is free, stopping after it is a legitimate outcome, and the written picture is yours either way. Where the root cause is the records rather than the configuration, the work runs through Salesforce data quality and migration; where it is a system that never agreed with Salesforce, through Salesforce integration.
A rebuild after a previous partner.
“We had regular, structured meetings, and their client portal was particularly useful in helping us stay on top of actions, timelines, and progress throughout the project.”
Elliot Leigh · Lettings and property · Salesforce rebuild after a previous partner
Read the Elliot Leigh case study, or browse all 80 Salesforce case studies to find a business shaped like yours.
The same problem, described three different ways.
Nobody searches for a Salesforce rescue. They search for the symptom they are living with. These are the three versions we hear most, and they are usually the same underlying build.
If you run sales
The forecast in Salesforce and the forecast your team believes are different numbers. Reps keep a personal spreadsheet because the pipeline stages stopped matching how deals actually work. Reporting takes a person a day a week to assemble by hand.
If you run marketing
Lead handover is a black hole — you cannot show what marketing generated because attribution broke somewhere between the form and the opportunity. Duplicate contacts mean the same person gets the same email three times, and consent flags nobody trusts.
If you are the CIO or IT director
A platform with years of undocumented automation, permissions nobody designed deliberately, and integrations that fail quietly. You are being asked about AI on top of it, and you know what is underneath. Nobody can tell you what the licences are actually being used for.
All three are fixable, and the sequence is the same. What differs is which number you want moved first — and that is the conversation we start with rather than a demo.
Why Salesforce implementations fail.
Almost never the technology. In over 1,000 delivered projects and a good number of inherited ones, the causes repeat.
It was scoped as a system, not a process
The build reflected an org chart rather than how work actually moves. People route around it, and the data goes with them.
Nobody owned it after go-live
The partner left, the internal champion moved on, and change requests started being made by whoever could log in. Most value is lost here, not during the build.
Automation was layered, never rationalised
Workflow rules, process builders and flows doing overlapping jobs, each added by someone solving one problem. The result misfires in ways nobody can trace.
The sharing model grew by exception
Permissions granted to unblock individuals, never revisited. It works until an auditor asks who can see what, or until you put an AI agent on top of it.
Data was migrated, not cleaned
Whatever was wrong in the old system arrived intact and multiplied. Reporting became untrustworthy, and once people stop trusting reports they stop entering data.
Adoption was assumed
Training happened once, at launch, and was never measured. Fewer than 40 per cent of organisations reach 90 per cent user adoption — the licences bill either way.
What the health check looks at.
Fixed scope, and the findings are yours to keep whoever acts on them. We will tell you if the build is worth saving, including when the honest answer is a clean start — and including when the answer is that you do not need us.
Data model and objects
What you own, what is custom, what duplicates standard functionality, and where the model fights the business rather than describing it.
Automation debt
Every flow, workflow rule, process builder and trigger, what fires when, and which of them contradict each other.
Security and sharing
Profiles, permission sets, role hierarchy and sharing rules, mapped against how the business actually operates. The section regulated clients need most.
Integrations
What is connected, how, what happens when it fails, and whether anyone is told when it does.
Licence and cost waste
Licences assigned to people who left, features paid for and unused, and editions that no longer match the requirement.
Adoption by team
Who uses what, and where the gap between what you pay for and what is used actually sits.
You get a written findings document with the problems ranked by what they cost you, and a costed plan against each. If you want the AI question answered at the same time, the AI readiness assessment covers what your data could truthfully support.
Moving away from your current partner.
This is the part people put off, usually for reasons that turn out not to apply. Most of our managed-service clients came from another partner.
You do not need their cooperation
Everything we need is in your own Salesforce, and you own it. A handover from the outgoing partner is helpful, not required.
You do not need to tell them yet
A health check is a conversation with us about your own platform. Nothing changes in your org and nobody is notified.
Your data and history stay put
A rescue works inside your existing org wherever possible. Where a rebuild is genuinely needed, history is migrated deliberately rather than abandoned.
You will not be locked in again
Full documentation of what we inherited and everything we change, so your own team or another partner could pick it up. Being hard to leave is not a strategy.
Elliot Leigh came to us after a disappointing experience with another Salesforce partner — read what changed. If you want it kept running properly afterwards rather than drifting back, that is managed services.
Questions buyers ask us first.
Is our Salesforce build worth saving or should we start again?
Usually it is worth saving. A rebuild on the existing platform keeps your history, your integrations and your licence position, and most of what looks irreparable is configuration rather than architecture. The exception is a build where the data model itself was built against the business, in which case a clean start can be cheaper than unpicking it. The health check is what tells you which of the two you have, and Ignyto will say so plainly even when the answer is the smaller piece of work.
What if our previous Salesforce partner left the project unfinished?
It is one of the most common reasons clients come to Ignyto. We do not need the previous partner’s cooperation to pick it up. The health check establishes what was built, what was half-built and what was documented, and the rebuild is scoped from that rather than from their plan.
Do you need access to our Salesforce before quoting?
For the health check, yes — read-only access is enough, and it is the only honest way to scope a rescue. Anyone quoting a fixed price for remedial work without looking inside your Salesforce is pricing their own risk rather than your problem.
Will we lose our data or history?
No. A rescue is done in a sandbox first and released in controlled deployments. Where records have to be merged or restructured, that is treated as its own piece of work with its own rollback position, not folded into a larger release.
How much does a Salesforce rescue cost?
It depends entirely on what the health check finds, which is why Ignyto quotes it afterwards rather than before. Work is time and materials with effort scoped as user stories, so you approve what gets built. Ignyto does not quote fixed price on remedial work, because the honest version of that price always includes a margin for the unknown and you pay for it whether or not the unknown appears.
Start with the free health check, not the rebuild.
The health check is free. Read-only access, a written picture of what you own, and an honest answer on whether it is worth saving. No obligation to build with us.