Most teams do not discover the problem on go-live day. They discover it three quarters later, when the pipeline report stops matching the forecast, when nobody trusts the account owner field, and when the sales team quietly moves back to a spreadsheet. This guide is about what to do at that point, and how a structured Salesforce org audit tells you what is actually broken before anyone starts rebuilding.
1. What A Failed Salesforce Implementation Actually Looks Like
The word failure suggests something dramatic. In practice it almost never is. The system stays up, the licences renew, reports still run, and nobody files an incident. What happens instead is a slow drift between what the org was supposed to do and what the business actually does every day.
That drift is hard to see from the inside because each individual workaround looks reasonable. A manager builds a private report because the shared one is wrong. A rep keeps a personal tracker because the opportunity stages do not match how deals really progress. An operations analyst exports to Excel every Friday because the dashboard cannot answer the question the CFO asks. None of these is a crisis. Together they describe a failed Salesforce implementation quite precisely.
It helps to separate the different things people mean when they use the word. They are not the same problem and they do not have the same fix.
Abandoned | Licences are paid for, but the platform is no longer where work happens. Users log in to update records after the fact, if at all. The org has become a reporting archive rather than an operating system. |
Distrusted | People use it, but nobody believes the numbers. Every important figure is checked against a second source before it is shared with leadership. |
Overbuilt | The org does far more than the business needs, usually because every request during the project became a requirement. Change is now slow and risky because nothing can be touched safely. |
Half-delivered | Phase one shipped and phase two never did. Objects, fields and automations exist for processes that were never finished, and users work around the gaps. |
Mismatched | The build is technically sound but describes a business process that no longer exists, often because the company reorganised, changed segments or acquired something after go-live. |
Naming which of these you have matters more than it sounds. An abandoned org and an overbuilt org can look identical on an adoption chart, and they need opposite treatments. One needs the process rebuilt around the users. The other needs a great deal removed before anything new is added.
A rescue engagement usually begins here rather than in the configuration. Before any change is scoped, the Salesforce consulting conversation should establish which kind of failure is in front of you and what evidence supports that reading.
2. Why The Failure Statistics You Have Read Do Not Hold Up
If you search for CRM failure rates you will find confident numbers. Thirty percent. Fifty five percent. Seventy percent. They appear in slide decks, in vendor blogs and in pitch documents, and they are usually presented as settled fact.
It is worth following them back to source. In most cases the trail ends at another blog post, which cites another blog post, which cites a study that is either unnamed, undated, or two decades old and about a different generation of software. Some of the most widely quoted figures cannot be traced to any published research at all.
Salesforce itself publishes a page on why CRM projects fail. It discusses causes such as unclear objectives and poor data, but it does not put a failure percentage on the problem. That absence is informative. A vendor with more implementation telemetry than anyone else in the market is not quoting a number, while a great many articles about that vendor are.
Treat these claims with care when you see them in a proposal ! A failure percentage quoted without a named study, a sample size and a year behind it. ! A statistic about CRM in general presented as though it measures one platform. ! Research from the early 2000s applied to cloud deployments, mobile usage and modern automation. ! A partner using a scary number to justify scope rather than to describe your org. ! Any figure that arrives already rounded to a memorable number and never carries a margin of error. |
None of this means projects do not go wrong. They plainly do. It means the useful evidence is inside your own org, not in a percentage someone put on a slide. Your login data, your field usage, your report inventory and your automation history describe your situation exactly. A borrowed statistic describes nobody.
This is also why a rescue should not start with a redesign. It should start with measurement. A Salesforce implementation partner who proposes a full rebuild before looking at the org is selling a template, and that is a common way a second Salesforce implementation repeats the mistakes of the first.
3. Symptoms Worth Checking Before You Blame The Platform
Symptoms are more useful than opinions because they can be verified. Every item below is observable in the org or in a short conversation with the people who use it. If several of them are true at once, you are looking at a failed Salesforce implementation rather than a training gap.
✓ Shadow spreadsheets are the real source of truth. Ask three people for the current pipeline and see how many open a file rather than a dashboard. Where the number comes from tells you where the work is happening.
✓ Login frequency is fine but record creation is not. Users signing in daily while creating almost nothing usually means the platform is being read rather than worked in.
✓ Required fields are filled with placeholder values. A wave of records containing a single full stop, the letter x or the word test means a validation rule is being satisfied rather than a business need.
✓ Reports are personal rather than shared. A large private report folder count against a small public one is a reliable sign that the standard reporting does not answer real questions.
✓ Small changes take weeks. If adding a picklist value requires a regression test across four automations, the build has become fragile rather than flexible.
✓ The same data lives in three places. Duplicate account hierarchies, parallel contact records and competing customer identifiers point to an integration that was never finished.
✓ Managers forecast outside the system. Where the commit number is assembled in a meeting rather than pulled from a report, leadership has already stopped trusting the platform.
✓ Errors are normal. Users who describe a recurring automation failure as just something the system does have stopped reporting problems, which means your issue log understates reality.
✓ Integrations are re-run manually. A scheduled sync that someone kicks off by hand each morning is a workaround wearing a schedule.
✓ Nobody wants to open the automation list. Reluctance to look at the flow inventory is often the clearest signal of accumulated Salesforce technical debt in the org.
None of these on its own proves anything. Four or more together, across different teams, is a pattern rather than a coincidence.
Several of these symptoms are operational rather than structural, and they respond well to ongoing Salesforce managed services once the underlying build has been corrected. Fixing the support model before fixing the build simply makes the workarounds more efficient.
4. The Root Causes That Show Up In Almost Every Rescue
Rescue projects have more in common than you would expect. The industries differ, the org sizes differ, and the same handful of causes keeps appearing. Recognising yours early shortens the audit considerably.
The project was scoped as a technology delivery, not a process change
Requirements were gathered as a list of screens and fields rather than as a description of how work moves through the business. The build then reproduces the org chart instead of the workflow, and users find it faster to work around than to work with.
Every request became a requirement
Without someone empowered to say no, a discovery workshop turns into a wish list. The result is an org with hundreds of fields, dozens of record types and automations that nobody can safely modify. This is the single most common origin of Salesforce technical debt in a first implementation.
Data migration was treated as the last task
When migration is scheduled after configuration and before training, there is no time left to clean anything. Whatever was wrong in the legacy system arrives intact, and the platform inherits a credibility problem it did not cause.
Adoption was planned as a training event
One session before go-live, a slide deck, and a recording nobody watches. Salesforce user adoption is a sustained management activity, not a launch task, and treating it as the latter almost guarantees a drift back to old habits.
Nobody owned the org after go-live
The partner left, the internal admin took on three other responsibilities, and change requests queued up. Six months of unmanaged drift will undo a good build.
Integrations were assumed rather than designed
The finance system, the marketing platform and the support desk were expected to line up on a shared customer identifier that was never agreed. Records then diverge quietly until the mismatch becomes visible in a board report.
The uncomfortable pattern In most rescue engagements the original build was competent. The configuration works, the code runs, the automations fire. What was missing was a decision-making structure around the build: someone to prioritise, someone to refuse, and someone to own the org after the project team disbanded. That is why re-implementing with the same governance usually produces the same outcome eighteen months later. |
Where the diagnosis is overbuilding rather than under-delivery, remediation is mostly subtraction, and careful Salesforce customization work matters more than new development. Removing a redundant record type is often worth more to users than adding a feature.
5. What A Salesforce Org Audit Covers, Domain By Domain
A Salesforce org audit is a structured inventory of what exists, what is used, what conflicts and what carries risk. It is deliberately boring. The value comes from completeness rather than insight, because the findings that matter are usually the ones nobody thought to look for.
A reasonable audit covers nine domains. Skipping any of them tends to produce a remediation plan that fixes the visible problem and leaves the cause in place.
Domain | What is examined | Typical finding |
|---|---|---|
Data model | Objects, record types, page layouts, field usage rates, relationships | Fields populated on under five percent of records; record types that differ by one picklist value |
Automation | Flows, process builders, workflow rules, triggers, order of execution | Two automations writing to the same field in an order nobody documented |
Code and packages | Apex classes, test coverage, managed packages, unused components | Installed packages with no active users and no removal owner |
Salesforce data quality | Duplicates, completeness, decay, validation rules, matching rules | Duplicate accounts across regions because matching ran on name alone |
Security and access | Profiles, permission sets, sharing model, health check score | Legacy profiles cloned repeatedly, each granting slightly more than intended |
Reporting | Report and dashboard inventory, private folders, subscription usage | Hundreds of reports, a handful actually opened in the last quarter |
Integration | Connected apps, API usage, sync failures, identifier strategy | A nightly job failing silently for months with no alert configured |
Adoption | Login patterns, record creation, feature usage by team and by role | Strong login numbers with almost no records created by one entire region |
Governance | Release process, sandbox strategy, change control, documentation | Changes made directly in production because the sandbox is out of date |
Some of this can be gathered with native tooling before anyone bills an hour. Salesforce Optimizer reports on unused fields, layout complexity and other implementation issues, and it costs nothing to run. It will not interpret findings for you, but it narrows where a human needs to look.
The output of the audit should be a register, not a narrative. Every finding needs a domain, an evidence reference, a severity, an estimated effort and a named owner. A report that reads well but cannot be turned into a backlog has not finished its job.
6. The Technical Layer: Metadata Sprawl, Automation Conflict And Platform Limits
The technical audit is where most of the accumulated cost sits. It is also where estimates go wrong, because complexity is not visible from the user interface.
Metadata sprawl
Salesforce sets explicit ceilings on how much you can add. Enterprise Edition allows 500 custom fields per object, Unlimited and Performance allow 800, and most objects carry a hard limit of 800 regardless of edition, with Account, Lead, Opportunity, Contact and Case permitted 900. Orgs rarely hit these ceilings, but they get close enough that adding a field becomes a negotiation. When a business request has to compete with a field created three years ago for a campaign nobody remembers, the platform has started charging you interest.
The audit should produce a field usage report for every major object: population rate, last modified date, referenced reports, referenced automations and referenced code. Anything with a low population rate and no references is a deprecation candidate. Anything with a low population rate and many references is a design problem, because the business is being asked to maintain something it does not use.
Automation conflict
Multiple automation tools accumulating over years is normal. Workflow rules from the original build, process builders from a later phase, flows from the most recent one, and triggers written for something none of them could do. Each was reasonable when it was created. Together they produce behaviour that nobody can predict from reading any single one of them.
The specific risk is order of execution. When two automations write to the same field, the result depends on sequence, and sequence is not always obvious. Symptoms include values that revert after saving, records that update twice, and validation errors that appear only for certain profiles.
Deep automation chains also run into Apex governor limits, which cap what a single transaction may do. Hitting them in production usually surfaces as an intermittent error during bulk operations rather than a clean failure, which is why it often goes unreported for a long time. Consolidating this layer is the core of most Salesforce workflow automation remediation work.
The cost of carrying it
This accumulation has a name outside the Salesforce world. McKinsey surveyed 50 CIOs at large financial services and technology firms in July 2020 and found that tech debt amounted to 20 to 40 percent of the value of their entire technology estate before depreciation, with 10 to 20 percent of the budget for new products diverted to resolving debt-related issues, and 60 percent saying their debt had risen perceptibly over the previous three years. Salesforce technical debt behaves the same way. It is not a line item, so it is paid quietly out of every future project.
Technical finding | How to size it | Usual remediation path |
|---|---|---|
Unused custom fields | Population rate plus reference count | Deprecate in stages, starting with zero-reference fields |
Duplicate record types | Compare picklist values and layouts | Merge, then retire the redundant type after a migration window |
Overlapping automations | Map every write to shared fields | Consolidate into flow, retire legacy rules one object at a time |
Apex with low coverage | Coverage percentage and last execution date | Add tests before refactoring, remove classes with no execution history |
Direct production changes | Compare production metadata against the sandbox | Re-establish a release process before further build work |
Where the technical findings cluster around system boundaries rather than inside the org, the remediation is usually an integration problem rather than a configuration one, and it needs to be scoped that way from the start.
7. The Data Layer: Duplicates, Decay And Fields Nobody Fills
Salesforce data quality is the fastest route to lost trust and the slowest to rebuild it. Users forgive a slow page. They do not forgive a customer record that shows the wrong owner in front of the customer. Gartner has put the cost plainly, noting that poor data quality costs organizations at least $12.9 million a year on average according to its 2020 research. The figure is an average across organisations of very different sizes, so read it as an order of magnitude rather than a prediction for your business.
The data audit follows a sequence. Running it out of order wastes effort, because deduplicating before you have agreed a survivorship rule simply creates a different mess.
1 | Agree what a record means Before counting anything, write down what one account represents. A legal entity, a billing relationship, a site, or a buying group. Most duplicate problems begin as definition problems, and no tool can resolve an ambiguity the business has not settled. |
2 | Profile completeness by field Measure population rate for every field on the major objects, split by record age. Fields that were filled in the first year and abandoned afterwards indicate a process that stopped, not a field that was never needed. |
3 | Measure decay, not just gaps A populated field can still be wrong. Sample contact records against a recent verified source and estimate what share has gone stale. Contact data ages continuously as people change roles and companies, so a decay rate matters more than a completeness percentage. |
4 | Test the matching logic Review the matching rules in place and run them against a known sample. Rules that compare company name alone will merge two genuine subsidiaries and miss two spellings of the same firm. |
5 | Define survivorship before merging Decide, per field, which record wins: most recent, most complete, or from the system of record. Write it down and get it signed off, because merges are difficult to reverse at volume. |
6 | Fix the inflow Deduplicating without correcting the sources that created the duplicates buys a few clean months. Web forms, imports and integrations each need their own control before the cleanup is worth doing. |
7 | Set an ongoing measure Publish a small set of data quality indicators on a schedule so the state of the data is visible without a project being commissioned to find out. |
Native controls do a reasonable share of this. Salesforce ships standard duplicate rules and standard matching rules for accounts, contacts and leads, and configuring them properly prevents far more duplicates than any periodic cleanup removes. Where customer data spans several systems and no single object can act as the master, the answer usually sits at the Data Cloud layer rather than inside the CRM.
One caution on cleanup projects. Deleting records feels productive and reads well in a status report, but it is the step most likely to be regretted. Archive before you delete, keep the audit trail, and stage merges so that a bad survivorship rule can be caught on a hundred records rather than a hundred thousand.
8. The Security And Access Layer
Security findings rarely cause the failure, but they are usually the ones that create the most urgency once they are written down. They also tend to be the easiest part of the audit to evidence, because the platform measures much of it for you.
Salesforce provides a Health Check that scores your settings against a baseline. The score calculation weights high-risk settings most heavily, with 90 percent and above graded Excellent, 80 to 89 Very Good, 70 to 79 Good, 55 to 69 Poor and 54 percent or below Very Poor. Running it takes minutes and gives you a defensible starting number. Trailhead also publishes a short module on using Health Check if the admin team has not worked with it before.
Cloned profile drift Each new role gets a copy of an existing profile plus one extra permission. After several years the permission set is generous by accident rather than by design, and nobody can say what any single profile is supposed to allow. Sharing rules nobody can explain Public read-write applied broadly to solve one team’s visibility problem, then never narrowed. This shows up as an access model that cannot support any future segmentation. Dormant users still active Leavers whose accounts were never deactivated, contractors past the end of an engagement, and integration users with far more access than their job requires. | Modify All Data granted widely Usually issued during a data migration and never withdrawn. It is worth listing every holder and asking each one to justify it. Unmonitored connected apps Integrations authorised years ago, still holding tokens, with no owner and no review date recorded anywhere. |
Why this belongs in a rescue conversation Access problems and adoption problems are related more often than people expect. When permissions are unclear, teams work around them by sharing exports, and once critical data is moving through spreadsheets the platform stops being the system of record. Tightening access without fixing the underlying visibility need simply moves the workaround somewhere less visible. |
Handle these findings carefully in sequencing. Withdrawing broad permissions before the reporting and sharing model has been corrected will interrupt work that people depend on, and a rescue project that breaks someone’s Monday morning loses the goodwill it needs.
9. Measuring Salesforce User Adoption Without Fooling Yourself
Adoption is the metric most often reported and least often measured well. Login counts are easy to produce and tell you almost nothing, because logging in is not the same as working in the system.
There is a useful reference point on how sales time is actually spent. Salesforce research covering 7,775 sales professionals, with data collected between August and September 2022, found that reps spend just 28 percent of their week actually selling, with much of the remainder going to deal management and data entry. That is the environment your org competes in. Any process that adds administrative minutes without returning something to the user will lose, regardless of how well it was designed.
The distinction that matters is between activity that proves the platform is being used and activity that only proves it is being visited.
Measures that describe real use | Measures that only look like adoption |
|---|---|
What is counted | |
Records created and updated by the people who own the process, per week, per team | Total logins, or a single organisation-wide percentage |
Data completeness | |
Population rate on the fields the business actually reports on | Completeness across all fields, including ones nobody needs |
Process fidelity | |
Share of opportunities that move through stages in the intended order | Number of opportunities created |
Reporting behaviour | |
Use of shared reports and dashboards relative to private ones | Number of reports that exist in the org |
Segmentation | |
Broken out by team, role and tenure so weak spots are visible | One number for the whole company, which hides every weak spot |
Segmentation is the part most often skipped, and it is where the useful information lives. An organisation-wide adoption figure of seventy percent may conceal one region at ninety five and another at twenty. The average tells you to run more training. The breakdown tells you which team to talk to and what to ask them.
Measure against a baseline taken before remediation begins. Rescue projects generate a lot of activity, and without a baseline you cannot say whether behaviour changed or attention simply moved.
Sustained Salesforce user adoption depends on a support model users can actually reach. Where questions go unanswered for days, people stop asking and resume working around the system, which is why ongoing Salesforce support services are part of the remediation rather than an optional extra afterwards.
10. Turning Audit Findings Into A Remediation Roadmap
An audit that produces two hundred findings and no sequence is not much more useful than no audit at all. The purpose of the register is to be triaged, and the triage should be visible to the business rather than made privately by the technical team.
Sort every finding into four groups, using two questions: does this hurt users today, and does it block other work.
- Stop the bleeding. Anything causing daily user pain or active data corruption. Silent integration failures, automations that overwrite good data, and validation rules that force placeholder entries belong here. These are usually small fixes with disproportionate credibility value.
- Clear the blockers. Findings that prevent other remediation from proceeding. An out-of-date sandbox, an absent release process and an undocumented order of execution all fall into this group, and none of them are visible to users, which makes them easy to defer and expensive to defer.
- Rebuild the core process. The one or two processes the business genuinely runs on, redesigned around how the work actually happens rather than how it was described in a workshop. This is the largest block of effort and the one that determines whether the rescue is judged a success.
- Reduce and retire. Field deprecation, record type consolidation, package removal and report cleanup. Low urgency, high long-term value, and the group most likely to be dropped when the schedule tightens. Protect a share of capacity for it or the debt simply resumes accumulating.
Consolidation at scale is achievable, though it takes time and sponsorship. Salesforce’s own customer story on LY Corporation describes an organisation that had built up hundreds of systems supporting more than a hundred services, and the work of unifying that estate around a single platform. The relevant lesson for a smaller rescue is not the scale but the sequencing: the fragmentation was addressed as a programme with an owner, not as a series of individual fixes.
Two practical rules keep a roadmap honest, and a Salesforce implementation partner worth retaining will insist on both. First, every item needs a named business owner as well as a technical one, because a finding without a sponsor will not survive its first scheduling conflict. Second, publish what you are deliberately not doing. A visible deferred list prevents the same finding being rediscovered and re-argued in six months.
☐ Every finding has a severity, an owner and an estimate.
☐ Quick wins are sequenced first and communicated to users when they land.
☐ A baseline of adoption and Salesforce data quality metrics is captured before work starts.
☐ Sandbox and release process are fixed before any large build begins.
☐ Deprecation work has protected capacity rather than leftover capacity.
☐ The deferred list is published alongside the active plan.
Where remediation involves moving data between orgs, consolidating instances or retiring a legacy system that was left running alongside, treat it as a Salesforce migration workstream with its own plan. Folding it into general remediation is a reliable way to lose control of both.
11. Remediate, Rebuild Or Re-Implement, And How To Choose A Partner
Three paths exist out of a failed Salesforce implementation, and the choice is usually made emotionally when it should be made on evidence from the audit.
Remediation keeps the org and fixes it in place. Rebuild keeps the org but redesigns one or more core processes inside it. Re-implementation starts a new org and migrates what is worth keeping. Cost rises steeply from left to right, and so does disruption, so the burden of proof should sit with the more expensive option.
Choose remediation when | The data model broadly fits the business, findings are concentrated in automation, data quality and access, and users understand the process even if they resent parts of it. |
Choose rebuild when | The data model works for most of the business but one or two core processes were designed around a structure that no longer exists, and patching them keeps producing new exceptions. |
Choose re-implementation when | The object model cannot represent how the business now operates, managed packages or customisations block the necessary changes, or the org carries so much unattributable configuration that testing any change costs more than rebuilding it. |
Be sceptical of re-implementation when | The main evidence offered is that the org feels messy. Mess is a symptom of governance, and a new org inherits the same governance on day one unless that has been changed first. |
The choice of partner matters more on a rescue than on a first build, because a rescue requires someone willing to tell you that part of the previous investment should be removed. Some questions separate a serious Salesforce implementation partner from a firm that will simply rebuild whatever you ask for.
✓ Ask what they would look at before proposing anything. A partner who can describe an audit method, name the domains and tell you what evidence they need is working from a process. One who arrives with a solution has arrived with a template.
✓ Ask them to show you a finding they expect to be unpopular. Rescue work involves removal. A partner who has never had to argue for deprecation has probably never done a rescue.
✓ Ask how they will measure the outcome. The answer should include baseline metrics captured before the work, not a list of deliverables shipped.
✓ Ask who owns the org after the engagement. If the answer is your internal admin, ask what handover, documentation and capacity that assumes. Most repeat failures start here.
✓ Ask what they will not do. A partner willing to name scope they consider unnecessary is giving you real information. One who agrees to everything is giving you a second version of the original problem.
✓ Ask about governance, not just delivery. Prioritisation forum, change control, release cadence and documentation standard. If these are not part of the proposal, the debt will start accumulating again on the day they leave.
Signals worth pausing on during partner selection ! A fixed price quoted before any access to the org has been granted. ! A failure statistic used as the main justification for a full rebuild. ! A team composition that changes between the pitch and the start date. ! No named approach to data migration or survivorship rules. ! No answer on how the org will be supported after the last sprint. |
Capacity is a separate question from capability. Some organisations need a delivery team, some need experienced people embedded alongside their own through Salesforce staff augmentation, and some need targeted Salesforce development help on a defined component. Where a rescue concludes with a fresh, deliberately small build, a structured quickstart approach can help keep the second attempt from repeating the scope problems of the first.
The honest summary is that a failed Salesforce implementation is a solvable problem, and usually a cheaper one to solve than to abandon. What determines the outcome is not the platform and rarely the original build. It is whether the organisation is willing to measure the org properly, accept what the measurement says, and put a decision-making structure in place before the next round of building starts.
Frequently Asked Questions
1. How do I know whether we have a failed Salesforce implementation or just a training problem?
Look at where the work happens. If users can complete their job in the platform but choose not to, training and process design may be enough. If they cannot complete their job without exporting data, keeping a side spreadsheet or asking someone to run a query, the build is the problem and no amount of training will close the gap. The symptoms in section three are a practical test, and four or more appearing across different teams points to a structural issue.
2. What does a Salesforce org audit typically involve?
A structured review across nine domains: data model, automation, code and packages, Salesforce data quality, security and access, reporting, integration, adoption and governance. The output should be a register of findings, each with evidence, severity, estimated effort and an owner, rather than a written narrative.
3. How long does an audit take?
It depends on org size and how much documentation exists. A small org with a single cloud and few integrations can be assessed in days. A large multi-cloud org with heavy customisation and years of undocumented change takes considerably longer, mostly because tracing why something exists is slower than finding that it exists.
4. Should we start a new org instead of fixing the existing one?
Only when the audit shows the object model cannot represent how the business now works, or when packages and customisations block the changes required. Starting again is the most expensive and most disruptive option, and it carries a specific risk: a new org built under the same governance tends to reproduce the same problems. Fix the decision-making structure first, then decide.
5. What is Salesforce technical debt and how do we measure it?
It is the accumulated cost of configuration and code that made sense when it was created and now makes change slower or riskier. Measure it with observable indicators rather than a score: unused field counts, overlapping automations writing to shared fields, Apex classes with low coverage or no recent execution, idle managed packages, and the average time and testing effort required to make a small change.
6. How do we improve Salesforce data quality without a long cleanup project?
Control the inflow before cleaning the backlog. Configure duplicate and matching rules properly, tighten web form and import validation, and agree what a record represents so the rules have something to enforce. Then clean in stages, starting with the objects your reporting depends on. Cleaning first and controlling later produces a few clean months and the same problem again.
7. What is a realistic measure of Salesforce user adoption?
Records created and updated by the people who own the process, broken down by team and role, alongside process fidelity and the population rate of the fields the business reports on. Logins and single organisation-wide percentages hide the variation that tells you where to act. Capture a baseline before remediation begins so change can be attributed.
8. Can we run the audit ourselves?
Partly, and it is worth doing. Optimizer, Health Check, field usage reports and report inventories are all available to an internal admin, and gathering them first reduces external cost. The part that benefits from outside help is interpretation, particularly deciding which findings are causes and which are consequences, and being willing to recommend removal of work a colleague built.
9. How do we stop the same problems returning after remediation?
Put three things in place before the last item ships: a named owner for the org with actual capacity, a prioritisation forum that is allowed to refuse requests, and a release process with a maintained sandbox. Most repeat failures trace back to the absence of one of these rather than to anything technical.
10. What should we expect from a Salesforce implementation partner on a rescue engagement?
A defined audit method before any solution is proposed, findings supported by evidence from your org rather than industry statistics, a willingness to recommend removing configuration as well as adding it, baseline metrics captured before work starts, and a clear answer on who supports the org afterwards. A fixed price quoted before anyone has seen the org is worth questioning.
Sources Referenced In This Article
Source | What it supports on this page |
|---|---|
Average annual cost of poor data quality, from Gartner research dated 2020 | |
Share of technology estate value attributed to tech debt, July 2020 survey of 50 CIOs | |
Share of the working week reps spend selling, 7,775 respondents, data collected 2022 | |
Score bands and weighting used in the security section | |
Practical walkthrough for admins running Health Check | |
Native reporting on unused fields and implementation issues | |
Per-edition field limits quoted in the technical section | |
Native duplicate prevention referenced in the data section | |
Default matching behaviour for accounts, contacts and leads | |
Transaction limits referenced in the automation discussion | |
Vendor discussion of causes, cited for the absence of a failure percentage | |
Consolidation of a fragmented multi-system estate |
