Salesforce has been the dominant B2B CRM for two decades. It is also the platform where data quality problems are most likely to go undetected for years, because the system is so configurable that bad practices get buried under layers of custom objects, automated processes, and admin turnover.
The data quality issues in Salesforce are different from those in simpler CRMs. They are structural, not just cosmetic. And they compound in ways that make a 3-year-old Salesforce instance significantly harder to clean than a 3-year-old HubSpot instance.
Custom Object Sprawl
Salesforce lets you create custom objects for anything. That flexibility is the platform's greatest strength and its most common source of data quality problems.
A typical mid-market Salesforce instance that has been live for three or more years has 15 to 40 custom objects. Some were built by the original admin. Some were created by a consultant during an implementation project. Some were generated automatically by managed packages. Many overlap.
The problems this creates:
- Data fragmentation: The same information gets stored in multiple custom objects. Customer feedback might live in a custom "Surveys" object, a custom "Feedback" object, and the standard Case object. Nobody knows which one is the source of truth.
- Orphaned objects: Custom objects created for a project that ended, a process that changed, or a team that was restructured. The objects remain, accumulating stale records that nobody uses but nobody deletes because they are not sure what depends on them.
- Relationship complexity: Custom objects with lookup relationships to standard objects create a web of dependencies. A contact record might be linked to opportunities, cases, custom activities, custom projects, and custom subscriptions. Merging two duplicate contacts requires understanding all of these relationships - and the standard merge tool does not always handle custom lookups correctly.
The fix starts with an object audit: document every custom object, its purpose, its relationships, and its record count. Objects with zero records or no recent activity are candidates for retirement. Objects with overlapping purposes need consolidation.
Picklist Sprawl
Picklists in Salesforce are meant to enforce consistency. In practice, they often do the opposite.
A picklist that starts with 10 clean options accumulates additional values every time someone needs a category that does not quite fit. "Technology" becomes "Technology", "Tech", "Technology - SaaS", "Technology - Hardware", "Technology (Other)", and "IT/Technology". Each new value is added to solve an immediate problem without considering the downstream impact.
After three years, a busy Salesforce instance typically has:
- Industry picklists with 50+ values, many near-duplicates
- Lead Source picklists with entries for campaigns that ended years ago
- Stage picklists with values that no longer match the sales process
- Custom picklists where 80% of records use the same three values and the other 40 values each have fewer than 10 records
The damage is to reporting and segmentation. A report grouped by industry that has seven variations of "Technology" splits what should be one segment into seven, each too small to be meaningful. Marketing lists built on picklist values miss records that use the wrong variation.
Fix: audit every picklist with more than 15 values. Merge near-duplicate values (this requires updating all records that use the old value before removing it). Set picklist governance rules: new values require approval, and every new value must include a definition of when to use it.
Integration Drift
A Salesforce instance at a 100-person company is typically connected to 8 to 15 other systems: marketing automation (Pardot, Marketo, HubSpot Marketing), enrichment tools, calling platforms, billing systems, support desks, project management tools, and custom integrations via middleware.
Each integration has field mappings. Each field mapping is a potential point of data corruption. And integration drift - the gradual divergence between how an integration was configured and how it currently behaves - is the single largest source of silent data quality degradation in Salesforce.
Common drift patterns:
- Overwrite conflicts: Two systems both claim to be the source of truth for the same field. The enrichment tool updates a contact's phone number. Then the marketing platform syncs an older number back from its database. The CRM shows whichever system synced last, which changes unpredictably.
- Null propagation: A connected system sends a blank value for a field that Salesforce had populated. The sync overwrites the real data with nothing. This is especially common with two-way syncs where one system does not have a corresponding field for every Salesforce field.
- Type mismatches: A text field in the source system mapped to a picklist in Salesforce. Values that do not match picklist options either fail silently, get truncated, or create new picklist values automatically (depending on sync configuration).
- Zombie integrations: Connections to tools the company no longer uses, still syncing data on schedule. A former employee's Zapier account still pushing records from a decommissioned form into Salesforce production.
Fix: create an integration map documenting every connection, its sync direction, field mappings, and data ownership (which system is authoritative for each field). Review this map quarterly. Monitor sync error logs weekly. When decommissioning a tool, disconnect its Salesforce integration on the same day.
Validation Rule Gaps
Salesforce supports validation rules that prevent records from being saved unless specified conditions are met. Most instances underuse this capability.
Without validation rules:
- Reps create opportunities with no close date
- Contacts get saved without an email address
- Accounts are created with free-text industry fields instead of picklist values
- Phone numbers are stored in inconsistent formats (with or without country codes, with spaces or dashes or neither)
Validation rules are the first line of defence against bad data entering the system. Every field that appears in a report, a workflow, or an integration should have a validation rule ensuring it is populated correctly before the record can be saved.
The balance is between enforcement and usability. Too many validation rules and reps cannot save a record without filling in 20 fields, so they abandon the CRM. Too few and the data is unreliable. The right approach is to require fields that downstream processes depend on and make everything else optional but encouraged.
The Admin Turnover Problem
Salesforce is a system that requires ongoing administration. Most mid-market companies have had two or three Salesforce admins over a five-year period. Each one inherits the previous admin's decisions without full context.
Admin 1 creates a custom object for tracking partner referrals. Admin 2 does not know about it and creates a different tracking mechanism using custom fields on the Opportunity object. Admin 3 inherits both and has no idea which one is active. Both accumulate data. Neither is complete.
This pattern repeats across every area of the system: workflows, process builders, validation rules, page layouts, profiles, and permission sets. Each admin adds their layer without fully understanding or documenting the layers beneath.
The result is a Salesforce instance that works - mostly - but that nobody fully understands. When something breaks, the fix is often a workaround rather than a proper repair, because nobody is confident enough in their understanding of the full system to make structural changes.
For a comparison of how these issues manifest differently across platforms, see our HubSpot vs. Salesforce data management analysis. Many teams considering a migration between platforms discover that the data governance problems travel with them unless addressed first.
Where to Start
If your Salesforce instance is more than two years old and has had more than one admin, start with these three actions:
- Object audit: List every custom object, its record count, and its last modified date. Flag objects with zero records or no modifications in 12+ months for review.
- Integration map: Document every connected system, its sync direction, and its field mappings. Disconnect anything no longer in use.
- Picklist review: For your 10 most-used picklist fields, count the unique values. Any picklist with more than 25 values needs consolidation.
These three actions take a competent Salesforce admin roughly a full day. The output is a clear picture of where the structural problems are. From there, a CRM health check can quantify the data quality impact and prioritise the fixes.
The problems nobody talks about are the ones that cost the most. Salesforce data quality is a structural challenge, not a cosmetic one, and it deserves structural attention.
