Why Nobody Trusts Your Salesforce Data (and Training Isn't the Fix)

Here is an illustrative scene (a composite, not a specific account). A sales director pulls the forecast for a board update and finds the same account listed twice, with two different close dates and two different owners. Nobody in the room can say which record is correct, or how there came to be two. The usual response is a data-hygiene push: merge the duplicates, remind the team to fill in required fields, maybe add a dashboard tracking completeness by rep. Six months later the same meeting happens again, because none of that touched why the duplicate existed in the first place.

The short answer

In brief: distrust in Salesforce data is almost never a training problem, even though training is usually the first thing that gets funded. Salesforce's own State of Sales research puts the scale of it plainly - only 35% of sales professionals say they completely trust the accuracy of their CRM data - and the structural causes behind that number repeat across almost every org: nobody owns a given field across the systems that touch it, duplicate rules were never tuned past Salesforce's three defaults, an integration overwrites records with no per-field policy, and sync failures go unreconciled until someone notices by accident. A Salesforce Health & Roadmap review usually finds two or three of these active at once, not one. Fix the structure and the "bad data" mostly stops reappearing. Fix the habits and it's back within a quarter.

Why nobody trusts the data

Not because anyone is careless. A rep who sees three versions of the same account stops trusting the pipeline number attached to any of them - that's a rational response to the evidence in front of them, not a discipline failure. The same goes for a service agent who's seen a case field revert itself overnight, or a finance team reconciling a forecast against a system they've learned to double-check. Most of what gets filed under "data quality" is actually an unresolved question about which system, process, or person is authoritative for a piece of data - and that question tends to surface first wherever two systems meet, which is why it shows up so often in integration work rather than in a single admin's configuration.

The seven causes that actually show up

None of these require a forensic audit to find - they're visible in the last integration incident, the last "which number is right" meeting, or the last time someone merged two accounts and quietly wondered how there came to be two. One or two showing up occasionally is normal for any live org. Several showing up as a pattern is the thing actually worth fixing.

1. Nobody can say which system owns a field

Ask who the system of record is for "account owner," "industry," or "last contacted date" in an org where Salesforce, a marketing tool, and an ERP all write to overlapping fields, and you'll often get three different answers from three different teams - or a shrug. Without an explicit answer, every integration that writes to that field is a guess about priority, and every disagreement between systems becomes a "which one is right" argument instead of a documented rule.

2. Duplicate rules exist, but nobody tuned them past the defaults

Salesforce ships three out-of-the-box matching rules, covering Accounts, Contacts, and Leads with fairly generic field combinations. Most orgs never revisit them after setup, which means duplicates created through a slightly different name spelling, a missing email, or a lead converted through a non-standard path sail straight through. The rules aren't broken; they're running at the setting a consultant left them at three years ago, for a business that looked different then.

3. A two-way integration overwrites without a per-field policy

The common failure mode in Salesforce integrations isn't a crash - it's a quiet overwrite. An enrichment tool fills in an industry field that a rep had already corrected by hand; a marketing sync blanks a phone number because its own record happened to be empty that day. "Last updated wins" sounds like a reasonable default and usually isn't, because the last system to write isn't automatically the most accurate one - it's just the one that happened to run most recently. A written, field-by-field rule for which side wins, and which fields never get overwritten at all, is the same discipline MuleSoft or a direct API integration both still require, whichever one is moving the data - and almost nobody writes it down before the integration goes live.

4. A sync job fails silently, and nobody reconciles the count

Most sync failures don't throw a visible error inside Salesforce - they fail on the other side, or time out, or skip a batch, and the only symptom is a number that's quietly wrong somewhere. Without a routine reconciliation check - record counts in versus out, spot-checking a sample after every run - that gap sits undetected until someone notices a report looks off, which is usually weeks after the first record went missing.

5. Updating a record means leaving the work the rep is actually doing

If keeping a field current requires leaving the email, the call, or the quote to go update a separate screen, a meaningful share of reps will update it late, approximately, or not at all - not from carelessness, but because the system is asking them to interrupt the job to maintain a record of the job. That's a capture-design problem, and it predicts which fields will decay fastest better than any amount of year-end data-hygiene training does.

6. Reports get patched faster than causes get fixed

A dashboard looks wrong, someone adds a filter to exclude the bad records, and the report looks right again by Friday. The filter is cheaper than finding out why those records existed, so it wins almost every time - until the same filter has to be added to four more reports, and nobody remembers why any of them are there.

7. Data governance is everyone's job on paper and nobody's job in practice

An Alvarez & Marsal survey of Salesforce users found more than half don't trust their org's data, and traced that mainly to missing master data management practices and unresolved disputes over who owns data governance - not to a skills gap. Without someone accountable for the rules above - who owns which field, what the overwrite policy is, who checks the reconciliation - each one gets solved once, informally, by whoever hits the problem first, and un-solved the next time a different person hits it. That gap often outlives the vendor relationship entirely, including a partner who already left without naming an owner for any of it.

What you see, versus what's actually wrong

The symptom and the cause are rarely the same thing, which is why so many data-quality projects fix the symptom and leave the cause in place:

What actually fixes it

None of the seven causes above get solved by a training session, because none of them were caused by someone not knowing what to do. They get solved by assigning an explicit system-of-record owner per field or field group, writing a one-page fill-vs-overwrite policy before any integration goes live rather than after the first bad overwrite, tuning duplicate and matching rules to the business the org actually runs today, and adding a routine reconciliation check instead of waiting for someone to notice a number looks wrong. None of that is exotic. Most of it is a half-day of decisions that nobody has been given the authority to make.

Why this gets more expensive now

This was already expensive before anyone talked about AI - a sales director who doesn't trust the forecast, a service team keeping a second spreadsheet "just in case." It gets worse the moment anything starts acting on the data as if it were reliable. An Agentforce action or a forecasting model reading from the lower-trust copy of a field will act with full confidence on exactly the number nobody in the room already trusts - it just does it faster, and at a scale a person wouldn't. That's an argument for fixing field ownership and sync policy before a pilot, not an argument for buying a tool to patch the data instead.

Questions worth asking before the next data-quality project

Is this a one-time cleanup or an ongoing job?

Ongoing. A cleanup fixes the records that are wrong today; none of the seven causes above stop generating new bad records once the cleanup project ends, unless someone keeps the ownership and the policy in place after the consultants or the project team leave.

Do we need to hire a data governance role?

Not necessarily a full-time one. Most 50-500 employee orgs don't generate enough governance decisions to justify a dedicated headcount - they need one person with the authority to make the handful of ownership and policy calls above, plus an outside second opinion on the integration-level ones, which is usually a fractional or project-based need rather than a permanent seat. See Salesforce Expertise as a Service for what that looks like sized down from a full hire.

Will Data Cloud fix this automatically?

No - identity resolution and matching rulesets inside Data Cloud still have to be configured and tuned for your data, the same as core Salesforce's duplicate rules do. It's a better toolset for the matching problem specifically, not a substitute for deciding who owns a field or what an integration is allowed to overwrite.

The bottom line

"Nobody trusts the data" is a diagnosis, not a complaint to manage around. Before funding another cleanup or training round, work out which of the seven causes above is actually active - it's usually two or three, not all seven, and each one is cheap to fix once it's named. If you're not sure which apply to your org, that's exactly what a Salesforce Health & Roadmap review is built to find, and we're glad to talk through what we're seeing before you fund the wrong fix.