Salesforce data governance: how to run an ongoing program

Salesforce data governance is the standing program that keeps CRM records accurate after the cleanup crew leaves. It names an owner and a steward for each core object and writes down the standards records must meet. It enforces those standards at entry and measures quality on a dashboard. A small council then meets monthly to fix what the numbers show and approve new fields. Without that loop, a clean org drifts back to messy within a few quarters.

Why does a one-time cleanup stop working?

Because the habits and integrations that created the mess are still running. A cleanup fixes the stock of bad records, while governance controls the flow of new ones.

Most orgs we review had a cleanup at some point. The duplicates came back through the same web form, the same import template and the same sync job. Nobody owned the account object, so nobody noticed until a forecast or a campaign went wrong. Treat governance as an operating habit with names, rules and a calendar attached, not as a project with an end date.

Who should own Salesforce data, and how is that different from a steward?

An owner is a business leader accountable for an object's fitness for use. A steward is the hands-on person who maintains the standards, reviews exceptions and fixes records day to day.

Assign both by object, not by department. Sales leadership usually owns accounts and opportunities, while marketing operations owns leads and campaign members. The service lead owns cases. A sales operations analyst might steward accounts and contacts, with a marketing operations specialist stewarding leads. The Salesforce admin enforces rules in configuration but should not be the owner of business definitions. When the admin owns everything, every data question becomes a ticket, and definitions get decided by whoever builds the field.

Which standards should be written down first?

Start with the fields your reports, routing and integrations depend on. Write the standard in plain language before anyone touches configuration.

• Required fields per record type and per stage, including when a value becomes mandatory rather than only at creation.
• Picklist values with a short definition for each, plus who may request a new value.
• Naming conventions for accounts, opportunities and campaigns, such as legal name versus trading name and how to label renewals.
• Account hierarchy rules: what qualifies as a parent, how subsidiaries and locations attach, and who approves changes to the tree.
• Format rules for phone, country, state and website, since inconsistent formats defeat matching.
• A definition of an active record, so stale data can be identified consistently.

Keep the standards in one place the whole company can read, such as a page linked from the Salesforce home tab. A standard that lives in an admin's head cannot be enforced or audited.

How do you stop bad data at the point of entry?

Use the platform's own controls so the correct value is the easiest one to enter. Prevention is cheaper than any remediation queue.

Validation rules enforce required values and formats at the moments that matter, such as moving an opportunity past a stage. Restricted picklists replace free text wherever a report groups by that field. Matching rules and duplicate rules flag or block likely duplicates as records are saved. Enrichment tools can fill firmographic fields from a trusted source, which reduces manual typing. Confirm with your Salesforce account team which enrichment options your edition includes.

Integrations need explicit rules too. For every shared field, write down which system wins when values conflict. Also record whether the sync may create records or only update them, and which external ID it matches on. An ERP might own billing address and payment terms, while Salesforce owns contact roles and opportunity data. Without that table, two systems overwrite each other quietly and users stop trusting either.

What should a data quality dashboard actually measure?

Measure completeness, duplication, staleness and conformity for each owned object. Set targets from your own baseline rather than borrowed industry figures.

Completeness can be built as a formula field that scores each record on the fields your standard marks as required. A report then averages that score by owner, team or source. Duplicate rates come from the duplicate record sets that duplicate rules generate, or from a scheduled report on shared keys such as email domain. Staleness is a report of records with no activity or modification since a date you define. Conformity checks catch values outside the standard, such as countries typed as free text.

Record the first reading for each measure as your baseline. Then let the council set a target per object based on what the business needs from that data. A number with no owner and no target is decoration, so put the owner's name on every dashboard component.

What happens when the dashboard shows a problem?

A problem becomes a remediation item with an owner, a fix and a prevention step. Fixing records without changing the cause just schedules the same cleanup again.

• Triage: the steward confirms the issue, sizes it and identifies the source, such as a form, an import or a sync job.
• Fix the records: small volumes by hand or with a list view, larger volumes with a reviewed data load and a backup taken first.
• Fix the cause: a new validation rule, a changed form mapping, an updated integration rule or user training.
• Verify: check the measure again at the next council meeting and close the item only when the number moves.

Keep remediation items in the same backlog as other Salesforce work so they compete for time openly. Hidden data work tends to be the first thing dropped.

How do you control new fields and picklist values?

Route every new field, object and picklist value through a short request that states the purpose, the owner and the reports that will use it. The council or the object owner approves it before anyone builds.

Unreviewed field requests are how orgs end up with three fields for the same idea and none of them populated. A simple request form should ask whether an existing field already covers the need. It should also ask who maintains the value and whether an integration touches it. Record the decision and the field's definition in your org documentation. Review unused fields as well, since retiring them is part of change control.

Why does data governance matter more for Agentforce and Data 360?

AI agents and unified profiles act on whatever records they are given. Poor ownership, duplicates and stale values turn into wrong answers delivered with confidence.

An agent that summarizes an account will repeat an outdated contact or merge two customers' histories if the underlying records are wrong. Data 360 identity resolution depends on consistent keys and formats across sources. Governance supplies those inputs: defined fields, trusted sources per attribute and measured quality. It also tells you which objects are ready to expose to AI and which should wait. Confirm specific Data 360 and Agentforce data requirements with your Salesforce account team, as packaging changes often.

What does a working governance cadence look like?

A monthly data council of object owners, stewards and the admin reviews the dashboard, approves changes and assigns remediation. Stewards handle exceptions between meetings.

Keep the agenda fixed: dashboard movement since last time, open remediation items, pending field and picklist requests, and integration issues. The meeting should end with named actions. A quarterly review with leadership can revisit standards and targets as the business changes.

Adjust the matrix to your structure, but keep one accountable party per row. Shared accountability usually means no accountability.

What mistakes undermine a governance program?

• Making IT or the admin the owner of business definitions they cannot decide.
• Writing standards nobody can find, or that contradict the validation rules in the org.
• Adding many validation rules at once and pushing users toward placeholder values.
• Tracking quality measures with no baseline, no target and no named owner.
• Letting integrations create records without matching on an external ID.
• Cancelling the council when things look fine, which is when drift starts unnoticed.

Data problems we have seen in client work show how fast this compounds. An aircraft-engine MRO company arrived on Salesforce with half of its records duplicated. Its Sales Cloud and Account Engagement build added prospect sync with duplicate detection. A medical-device manufacturer's Pardot cleanup removed 970+ invalid prospects and fixed the misconfiguration that kept creating duplicates.

Where should a team start this quarter?

First, name an owner and a steward for accounts, contacts, leads and opportunities, and write the standards for their most-reported fields. Next, build the dashboard and capture a baseline for each measure.

Then hold the first council meeting, pick the two worst measures and open remediation items for them. Add prevention rules one at a time as each cause is found. If you want an outside view, an optimization engagement can assess the current state and set up the governance loop with your team.