The Data Governance Framework: Who Owns what Field, and Why?

Every CRM I've ever inherited had the same problem. Multiple fields that seemed to track the same thing. Lead Status and Lifecycle Stage and Contact Status — three different fields, three different owners, three different definitions, none of them agreed upon. Reps had developed personal interpretations. Managers ran reports from different fields. The data meant different things to different people.

This isn't a technology problem. It's a governance problem. And it's completely solvable — but only if you approach it with the same rigour you'd apply to any other system design challenge.

Why Governance Breaks Down

Data governance collapses under two pressures: urgency and autonomy.

Urgency: When a new campaign needs to launch in a week, someone creates a field called "Campaign Source Q2 2023" without a formal request. The campaign ends. The field stays. Two years later, no one knows what it was for.

Autonomy: Different teams have different reporting needs. Marketing creates "Lead Quality Score." Sales creates "Rep Quality Assessment." Product creates "User Value Tier." Each is reasonable in isolation. Together, they create a CRM where three different fields are trying to express the same underlying concept with no agreed definition.

The solution is a governance model that's lightweight enough to not impede speed, but rigorous enough to prevent field debt from accumulating.

The Field Ownership Matrix

System-Owned Fields (Read-Only by Humans)

These are the ground truth fields. They're populated by automation: your enrichment provider, your marketing automation platform, your product analytics via Reverse ETL. Human reps cannot edit these fields.

Examples: Industry, Annual Revenue, Employee Count, Last Product Login, Feature Adoption Score, Lead Source, UTM Parameters.

Why read-only? Because manual editing of enrichment-sourced data creates two competing "truths." If a rep changes the Industry field from "Financial Services" to "Banking" because they prefer that label, your segmentation logic breaks. The system's version of truth must be protected.

Sales-Owned Fields (Manual Input Required)

These capture human judgment that automation can't derive. They require a rep to actively input information, and they should be required before key status transitions.

Examples: Next Step, Competitor Noted, Decision Maker Name, Deal Sentiment, Close Date Rationale, Disqualification Reason.

The key governance discipline here: these fields should have a defined set of acceptable values (picklists) rather than free text wherever possible. Free text is unsearchable, unreportable, and ungoverneable. See our piece on standardising disqualification reasons for a detailed treatment of this.

Marketing-Owned Fields (Campaign and Consent Data)

These fields track how someone entered your ecosystem and what they've consented to. They should be set once at creation and never manually overwritten by Sales.

Examples: Original Lead Source, First Touch UTM Campaign, Email Opt-In Status, GDPR Consent Timestamp.

This category is especially important for compliance purposes. If a rep can overwrite an Email Opt-In field, you have a GDPR exposure. If the Lead Source field can be edited by anyone, your attribution data is worthless.

The "New Field" Protocol

Before any field is created in the CRM, the person requesting it must answer three questions:

1. Who will populate this data, and at what trigger? If the answer is "I'm not sure yet," the field doesn't get created.
2. Which report or dashboard will use this data? If you can't name a specific report, you're creating field debt.
3. What operational decision will be made based on this data? If the answer is "it would be useful to track," that's not sufficient.

Fields that can't answer all three questions are curiosity, not governance. They add cognitive load to your reps and noise to your system. Build a culture where the burden of proof is on the field requester, not on the RevOps team to justify saying no.

The Annual Field Audit

Even with a robust governance protocol, field debt accumulates. Run an annual audit:

• Export every custom field in your CRM.
• For each field: when was it last modified? What's the population rate? Is it referenced in any report or automation?
• Fields with a population rate below 10% and no report reference are candidates for deprecation.
• Follow the CRM de-cluttering protocol: hide first, delete after 30 days of no objection.

Governance isn't bureaucracy. It's the difference between a CRM your team trusts and one they work around. Build the former.