Salesforce data governance is the set of roles, rules and controls that keep your CRM data correct, safe and compliant. A Salesforce data governance strategy is the plan for putting those controls in place, as part of your wider Salesforce data strategy.
Five practices do most of the work: clear data ownership, quality controls, least-privilege access, automated compliance monitoring and ongoing training. All five build on standard Salesforce features.
We wrote this for Salesforce admins, data stewards and DevOps leads who need a governance framework that still works once the org gets big.
It walks through the key components of good data governance, the features behind each one, and the places teams tend to get stuck.
What is Salesforce data governance?
Data governance in Salesforce, often called CRM data governance, comes down to three questions: who owns each kind of data, what good data looks like and who can see or change it.
A data governance framework writes those answers down as governance policies, roles and platform settings. That way the rules don't fall apart when the Salesforce org doubles in size or a new team joins.
Data governance and data management sound alike, but they're different jobs. Data management is the day-to-day operations you use to manage data, like storing it, moving it between orgs and cleaning it.
Data governance decides the rules that work has to follow, so your data management stays consistent from team to team.
A governance program protects data in four ways. Records should stay accurate from the day they're created until they're archived, so reports run on reliable data.
Every change should leave a trail you can follow, which is what keeps data integrity intact.
Access controls should keep sensitive data in front of the right people only. And each dataset should map to the rules that cover it, whether that's GDPR, HIPAA or SOX.
Why does Salesforce data governance matter?
Gartner research from 2020 found that poor data quality costs organizations at least $12.9 million a year on average.
Then there are fines. For the most serious GDPR breaches, regulators can charge up to EUR 20 million or 4% of worldwide annual turnover, whichever is higher.
Regulatory penalties are the dramatic part, but unreliable data hurts in quieter ways too. Teams spend hours chasing errors instead of serving customers, and that's wasted resources nobody budgets for.
California's CCPA gives consumers rights over their personal data as well. Regulatory compliance is much easier to prove when the rules already live in your Salesforce environment.
Weak governance shows up week to week. Sensitive records end up copied into sandboxes and exports, so a data breach reaches further than it should.
Every compliance audit turns into a scramble for missing history.
Sales and finance argue about whose report is right, and people lose the reliable insights they were supposed to get from Salesforce. Data errors pile up too, from duplicate records to stale customer records that nobody owns.
How do you build a Salesforce data governance strategy?
Build your governance strategy the way you'd run any other business project, with a goal, named owners and a pilot. These five steps turn it into effective data governance that people actually follow.
Set a goal and metrics
Tie your governance strategy to business objectives the company already cares about, such as passing audits without a fire drill. Then pick a handful of numbers you can track.
Form a governance committee
Bring in IT, legal, finance, security and the business units. Agree who decides what, and how a disagreement gets escalated.
Choose tools that enforce policy
Pick tools that match your business requirements. Classification, backup and access reviews should run automatically as part of everyday data management, not depend on someone remembering a checklist.
Pilot one area first
Start with customer or financial data. Once the governance strategy works there, expand to other business units.
Keep a feedback loop
Hold retrospectives and ask users what's getting in their way. Governance policies should change as your systems and the rules around them change.
Large orgs with many business units have extra coordination to work through, and our guide to enterprise data governance in Salesforce gets into it.
Which Salesforce features does governance build on?
Three Salesforce platform features are the essential elements most governance controls sit on. It's worth knowing how they work before you write a single policy.
Custom metadata types
Custom metadata lets you store governance rules as metadata instead of in a spreadsheet. The rules then deploy with your releases and stay under version control, like any other change.
Platform events
Platform events publish activity as it happens. You can use them to alert someone when sensitive data is accessed in an unusual way, the same day rather than at the next quarterly review.
Permission sets and permission set groups
These let you build access controls from small pieces, grouped by job function. It's a lot easier to reason about than one profile per role.
The table below shows which Salesforce features each practice relies on and who usually owns it.
5 Salesforce data governance best practices
These Salesforce data governance best practices build on each other, so it helps to take them in order. None of these best practices asks you to throw out your existing processes.
Effective data governance can mean tightening what's already there.
1. Define clear data ownership and roles
Picture a cleanup project on the Account object. Sales thinks marketing owns it, marketing thinks it's an admin job, and three months later nothing has changed.
That's what happens when no one is named as the owner.
Ownership is also harder to see in Salesforce than you'd expect.
A user can get access from a profile, several permission sets and a sharing rule all at once, so a field that looks locked down on one screen may still be open to people who shouldn't see it.
Three roles cover the basics, and between them they handle data stewardship. An executive sponsor approves governance policies and budget, and settles arguments over shared objects like Accounts and Opportunities.
A data steward handles day-to-day data quality, merges duplicates and asks for validation rule changes.
The third is a DevOps lead, who sets up profiles, permission sets and pipelines so the rules carry from sandbox to production.
In larger companies with multiple business units, a small data governance committee made up of these owners and other key stakeholders agrees the shared rules.
Each business unit then keeps its own data stewards. Data stewardship goes better when those people get ongoing support, such as regular time with the admin team.
The roles also need to talk to each other about metadata. If a steward wants a new picklist value, the DevOps lead should check which flows and Apex triggers it touches before it ships.
To get ownership in place, start by listing every object and flagging regulated or high-risk fields, along with what depends on them. Then:
- Name a sponsor, steward and DevOps lead for each object, and decide who owns its backup coverage.
- Keep ownership policies in custom metadata types so they deploy like everything else.
- Document the role hierarchy, including spots where inherited access could clash.
- Check each deployment package against the ownership policies before it's promoted, and review permissions every quarter.
If you want more detail on who does what in data stewardship, we've written a separate guide to data governance roles and responsibilities.
2. Build data quality controls
Sales and service teams need high quality data to manage customer relationships, and a report can only be as good as the records feeding it.
Salesforce makes it very easy to add fields, which is great until nobody remembers why they exist.
A custom field added without a validation rule drifts. A picklist value removed without checking old records leaves orphaned values sitting in reports.
So start by writing down your data quality standards. Which fields are required, what format does each one take, and how often does it need to be kept up to date?
Then build validation rules that enforce those answers at the point of entry.
Written standards are also what make complete data and data accuracy something you can actually measure.
Migrations are one of the most common ways bad data gets in. Our Salesforce data migration best practices cover test loads and checks before anything reaches production.
For duplicates, Salesforce duplicate management uses matching rules and duplicate rules to find duplicates one record at a time or across your org. You can also track how the cleanup is going.
The standard rules handle simple cases fine. Enterprise data is messier.
The same B2B account might show up as "IBM", "International Business Machines" and "IBM Corporation". A German company might appear with "GmbH" in one record and the full legal form spelled out in another.
It helps to set separate duplicate rules for each record type and use fuzzy matching for international names. If you keep country formatting rules in custom metadata types, stewards can change them without waiting on a developer.
We'd also log every duplicate decision in a custom object, which gives data stewardship a paper trail. After a few months, that log tells you which matching rules need tuning and which mistakes keep coming back.
Validation rules need some housekeeping of their own, or they pile up and start blocking legitimate work.
Sorting them into groups (business logic, data formats, compliance and security) makes it much easier to review one group before each release.
Integration users are worth a separate look.
It's tempting to give them broad field access just to get an integration working, so give each one its own permission set with only the fields it needs, and set an alert for when it touches anything else.
3. Enforce least-privilege access
Least privilege means each user and each process gets only the access it needs, so people see the right data for their job and nothing more.
In Salesforce, data access comes from object permissions, field-level security, sharing rules and permission sets, and they all stack on top of each other.
Orgs that started with one profile per role often end up with dozens of near-identical profiles nobody can explain. Our post on Salesforce permission sprawl shows how to find and untangle that.
A cleaner approach is to build permission sets around what people actually do. One set might control which data a team can see, another which business processes they can run, and another which configuration changes admins can make.
Integration sets work the same way, limited to the relevant data each automated process needs. Then bundle the common combinations into permission set groups, so assignment stays simple without losing fine-grained control.
Fields deserve the same thinking. Data classification sorts them into levels, for example public, internal, confidential and regulated, and field-level security then matches each level.
A regulated field, like one covered by GDPR or HIPAA, gets the tightest access. Our data sensitivity classification guide walks through setting up those levels.
Automation is where least privilege quietly breaks. A flow that runs in system context ignores the running user's object and field permissions, so it can read data that user can't see.
Run flows in user context when the user's permissions should apply.
When a job has to run in system context, give it its own automation user with minimal access, put sensitive steps behind custom permissions and log each run so you can audit it later.
If you want to see how all these access controls fit together, our Salesforce security model breakdown maps the layers.
4. Automate compliance monitoring
Compliance audits once a year aren't enough. Salesforce needs continuous oversight, because a single metadata change can open regulated data to a whole new group of users.
New objects are a similar risk. Someone creates one without the right controls, and it can sit unnoticed until an auditor finds it.
Salesforce's built-in audit tools don't all keep data for the same length of time. The table shows what each one records and how long it lasts.
Setup Audit Trail entries disappear after 180 days. If your retention policy asks for longer, set up a scheduled download.
Field history has the same problem, unless you've bought and turned on Field Audit Trail, a paid add-on.
The built-in trails also miss business context.
That's why it's worth adding your own layer on top: custom audit objects for the changes the business cares about, platform events that send audit activity to an outside compliance system, and reports that pull it all into one view.
Watch sensitive data access, permission changes, configuration drift away from an approved baseline and bulk exports most closely.
Audit evidence can run on a schedule too.
Depending on your industry, that might be GDPR Article 30 records of processing activities, HIPAA access logs that tie users to patient records, SOX IT general controls evidence, or 21 CFR Part 11 audit trails for life sciences.
Line all of this up with your regulatory requirements and data retention policies, so records follow the data lifecycle and get archived or deleted on time. As a bonus, it keeps data storage under control.
There's more on the controls themselves in our guides to implementing Salesforce data compliance and the Salesforce audit trail. For specific regulations, see GDPR in Salesforce and HIPAA on Salesforce.
5. Train people and measure the results
A rule that nobody understands gets worked around. Admins need to see how a metadata change affects the governance framework, and developers need to know how their code has to meet security controls.
Everyday Salesforce users mostly need two things: which of their actions are monitored, and when they're allowed to share data outside Salesforce.
An annual training session rarely sticks.
It works better to put the guidance where people already work, like help text on sensitive fields, Lightning pages built for each role and short screen flows that walk someone through a governance decision.
Store policy text as custom labels or custom metadata. When the policy changes, you update it once and it stays up to date everywhere.
To know whether any of it is working, track a few data quality scores. Accuracy is the share of records that pass validation, and completeness is the share of required fields that are actually filled in.
Timeliness is how long a real-world change takes to show up in Salesforce. Uniqueness is how much duplicate data is left.
Count compliance incidents alongside these and compare them before and after each change. Better scores usually mean more reliable analytics.
For a step-by-step rollout, see how to implement data governance in Salesforce.
What are the most common Salesforce governance problems?
Here are problems to watch for during deployments, integrations or a growth spurt, with a fix for each.
High data volumes make almost all of these worse, and our post on big data challenges in Salesforce environments explains why.
How does Flosum support Salesforce data governance?
Flosum's risk and governance tools cover profiles, permission sets, roles and privileged access. They track configuration drift, unauthorized changes and flow changes across environments, and keep audit trails for internal reviews and regulators.
Flosum Backup & Archive adds backup and point-in-time restore, and Data Migrator moves data between orgs.
If you're SOX-regulated, take a look at our SOX compliance solution. For safer testing, there's our guide to Salesforce sandbox types.
Flosum runs three ways: Salesforce-native as a managed package, Flosum-hosted cloud, or customer-hosted on infrastructure you control. You pick the one your security team will sign off on.
FAQs
Book a demo to see how Flosum helps teams govern Salesforce data, permissions and changes.
Thank you for subscribing
