Governance & data quality

A VP of Sales once asked me why the board deck said 4,200 accounts and the routing engine said 5,600. Same org, same day, same objects. The answer was that nobody owned the account grain. Reps created dupes to claim territory, an old data-load created shells with no owner, and an enrichment sync spawned a third copy whenever a domain shifted from acme.com to www.acme.com. Three writers, zero referee, and a 33% gap between two numbers that should have been identical. Governance is the referee. Without it, every clean model I have ever built drifted back to noise inside two quarters, because the model is a snapshot and governance is the thing that keeps the snapshot true.

Governance gets framed as bureaucracy that slows the team down. In practice it is the opposite: it is the small standing cost that stops the large recurring one. Gartner puts the average cost of poor data quality near $15M a year per organization, and almost none of it shows up as a line item. It shows up as the gap above, as a rep who stopped trusting the CRM, as a campaign that mailed the same buyer four times. You either pay a governance tax on purpose or an entropy tax by accident, and the accidental one compounds.

Ownership is the load-bearing wall

Every governed field has exactly one writer, and every governed object has exactly one steward. The writer answers “who is allowed to change this value.” The steward answers “who I escalate to when it is wrong.” Skip either and the field becomes a commons, and the commons always degrades. When enrichment and reps both edit employee count, the last write wins and neither side knows the value is contested. Name the writer, lock field-level security to that writer, then the tug of war stops because only one hand can reach the field.

The steward role is where governance becomes a program instead of a cleanup. A data steward owns a domain (accounts, contacts, opportunities), sets the standard for that domain, and signs off on bulk changes to it. In a mid-size org this is a fraction of one person’s time. The alternative is that nobody owns it and the standard is whatever the last admin remembered.

Prevent at entry, because cleanup never finishes

The cheapest place to stop bad data is the moment before it exists. Free text is where reporting goes to die: an open “Segment” field breeds “Enterprise / enterprise / ENT / Ent.” and every spelling is a separate bucket in a report that was supposed to show four. A restricted picklist closes the door so the API cannot invent a value either.

<!-- Segment as a restricted picklist: the API can't add a 20th spelling -->
<fields>
  <fullName>Segment__c</fullName>
  <type>Picklist</type>
  <valueSet>
    <restricted>true</restricted>
    <valueSetDefinition>
      <value><fullName>Enterprise</fullName></value>
      <value><fullName>Mid-Market</fullName></value>
      <value><fullName>SMB</fullName></value>
    </valueSetDefinition>
  </valueSet>
</fields>

Validation rules carry the same intent for values a picklist cannot express. The discipline is to require what is genuinely known at that stage and validate the rest at the stage where it becomes real. Mark the wrong things required and reps type “N/A” and “asdf” to get past the screen, which is worse than blank because it looks like data.

Detect what slips through

Prevention is never complete, so you monitor. A weekly data-quality query set is the minimum: dupes above threshold, owner-less records, stale enrichment, and broken match keys. Domain normalization is the one I run first, because a broken match key silently corrupts every downstream match.

-- Match keys that will silently fail: protocol, www, path, or null
SELECT Id, Name, Website, Account_Domain__c
FROM Account
WHERE Account_Domain__c LIKE 'http%'
   OR Account_Domain__c LIKE 'www.%'
   OR Account_Domain__c LIKE '%/%'
   OR Account_Domain__c = null
ORDER BY Name

Duplicate rate is the number that quietly corrupts everything above it. Above 5%, rollups over-count and routing sends two reps at one account. Ungoverned mid-size orgs routinely run 10 to 25%. Treat 5% as the ceiling you manage below, not a target you drift toward.

Change control: govern the schema, not just the rows

The rows are only half the problem. The other half is the schema drifting because anyone with admin rights can add a field on a Friday afternoon. Ungoverned orgs accumulate hundreds of custom fields, most unused, and the sprawl makes every future report harder. Change control means a schema change goes through a request, a steward review, and a deployment, never a direct edit in production.

Governance is never finished, because the data underneath decays at roughly 30% a year and the business it describes changes shape every quarter. What you can finish is the discipline: one steward per object, one writer per field, entry constrained, quality monitored weekly, and schema changes gated. Ship those and the CRM stops being the thing everyone routes around, and two numbers that should match finally do.