Data quality is a leadership problem (not a Salesforce problem)
When someone discovers a data quality problem in Salesforce, what is usually the first response? Add another validation rule. Make more fields required. Install a duplicate-management tool. Or ask the Salesforce administrator to clean everything up.
That may improve the data for a while. But a few months later, the same problems often return.
Why? Because bad data is rarely caused by a missing validation rule. It is usually caused by unclear ownership, conflicting priorities and business processes that reward speed over accuracy.
Salesforce is often where you can see the problem. That does not mean Salesforce caused it(!)
Data is a strategic asset
Most organisations will tell you their data is important. Some will even call it a strategic asset. But do they treat it like one?
Data is often seen as a technical byproduct: something administrators, developers, consultants or IT should manage. They create the fields, build the automation and fix the data when it goes wrong. Meanwhile, the business decides which information employees must capture, how quickly work needs to be completed, and which targets people are measured against.
Those decisions influence data quality far more than most Salesforce configurations.
Imagine a sales representative who is rewarded for creating as many opportunities as possible. The opportunities will be created, and the required fields will contain something. Whether that something is accurate or useful is a different question.
A validation rule will not change the incentive.
“If you have maintained 100% data quality for more than two days, please let me know.”
Bad data starts in your processes
Bad data does not appear by itself. It is created through everyday processes.
Perhaps users must enter the same information in several systems. Perhaps a field became required five years ago, but nobody remembers why. Or perhaps everybody knows that a process does not make sense, but nobody knows who is allowed to change it.
Users then find their own solutions. They enter placeholder values, copy information from an old record or maintain a separate spreadsheet. From their perspective, that might be the only practical way to get their work done.
That's why returning data problems should not immediately lead to a technical discussion. Ask yourself this:
Why do we collect this data?
Who uses it? (in which reports and meetings?)
Which fields actually matter?
Who owns the process?
Who has the authority to change it?
As a consultant, a large part of my job is asking questions. Not because questions magically clean your database, unfortunately. They help uncover why the problem keeps returning.
Governance should create clarity
The word governance can make people nervous. It sounds like committees, policy documents and more administration. That is not what good governance should achieve. Governance should create clear standards, clear ownership and clear decisions. It should explain what the organisation will do, what it will not do and who is responsible for following up.
It is also not a blame game. Pointing at Sales, Marketing, Finance or IT does not solve anything. The person cleaning the data is not automatically the person who should own it. Ownership belongs with people who understand the business context and have enough authority to change the process.
Your administrator is not a data janitor
Photo by Raymond Okoro on Unsplash
Salesforce administrators have an important role. They can identify patterns, highlight risks, configure controls and show where processes produce unreliable information. But they cannot make every business decision.
An administrator may see that a field is filled out incorrectly. Can they decide which value the business needs? Can they change the sales process or the targets influencing user behaviour? Usually not.
Despite this, administrators are regularly made responsible for data without being given the authority required to manage it. They remove duplicates, correct fields and respond to complaints about unreliable reports. Once everything looks better, the clean-up project is called a success. Then the same processes create the same problems again.
The administrator should be part of the conversation, but should not carry the entire responsibility. Their role is to translate business decisions into Salesforce configuration, not invent those decisions themselves.
Aim for trusted data, not perfect data
Does every field need to be complete? Does every record need to be correct at all times? Probably not.
If you have maintained 100% data quality for more than two days, please let me know. I would be interested to see it.
A more realistic goal is trusted data: data that is good enough for the purpose for which it is used. The accuracy required for invoicing may differ from the accuracy required for a marketing list. Leadership must decide which information is critical, what "good enough" means and how much time and money the organisation is prepared to invest.
Without those decisions, the request becomes: "Make all our data clean." That is not a strategy. It is an unlimited project.
Start with responsibility, not configuration
Validation rules, duplicate rules, automation, reports and specialist tools can all help. But tooling works best after the organisation has made the necessary decisions.
Before creating the next validation rule or starting another clean-up project, ask yourself:
Which data matters most?
Who owns its definition and quality?
Who can change the process that creates it?
Are our KPIs supporting the behaviour we expect?
How will we follow up when quality starts to decline?
Bad data may be visible in Salesforce, but its causes are usually found in ownership, processes, incentives and decisions.
Those are leadership responsibilities.
So, the next time someone says, "We need the admin to fix the data," perhaps the first response should be another question:
What needs to change in the business to prevent us from fixing the same data again next year?
