Field Governance: Who May Create a CRM Property
August 1, 2026
Uncontrolled field creation does not fill a database with clutter. It produces a data layer where no field can be trusted, and the damage is not retroactively repairable.
Most CRM instances past a certain age contain several fields meaning roughly the same thing, populated inconsistently by different teams, none of which can be removed because something might depend on them.
This is not untidiness. It is a specific failure with a specific cause, and its cost is that reporting becomes unreliable in a way that cannot be repaired after the fact.
How it happens
Every individual field creation is reasonable. Someone needs to capture something a campaign requires, or a report needs a flag, and creating a field is a two-minute task with no visible cost.
The cost is aggregate and deferred. Three fields for industry means every report chooses one, and different reports choose differently — which surfaces months later as dashboards that disagree for reasons nobody can trace.
The asymmetry
Why it cannot be repaired retroactively
Historical data is the problem. Once records have been written with three inconsistent definitions across two years, consolidating the fields does not consolidate the history. You can pick a survivor going forward; you cannot retroactively determine what each of the others meant at the moment it was written.
This is what distinguishes field sprawl from most data quality problems. Incompleteness can be backfilled and duplicates can be merged, but ambiguity in historical meaning is permanent.
Method: a governance model that is not bureaucracy
Name two or three people who may create fields. Short means short.
Require a stated consumer: the report, view or automation the field will feed. If neither exists yet, the field does not need to exist yet.
Check for an existing field covering the concept. This catches most requests and takes a minute.
Record an owner, so the field has someone to ask when its meaning is disputed.
Log the change with a reason. This is what makes a later audit possible.
The point is not to refuse requests. It is to ensure the second field for a concept is a decision rather than an accident.
Retiring what already exists
Both conditions must hold. Neither alone is sufficient.
| Condition | How to check | If only this is true |
|---|---|---|
| Unpopulated on recent records | Completeness on records created in the last quarter | May be newly abandoned — check for a replacement field |
| No consumer | No report, view, automation or integration reads it | May be dormant but load-bearing at period end |
Source: Test proposed here
Where to start
Audit the fields your reporting actually depends on before writing any policy. The list is usually far shorter than the total field count, and its brevity is itself the argument for governance — it demonstrates how much of the sprawl serves nothing.
Where this fails
Governance cannot fix a data model that is wrong. A CRM with perfectly controlled fields can still be modelling the business incorrectly — wrong objects, wrong relationships, stages that do not describe the process. That is a design review, and applying field governance to it produces well-managed fields on a broken model.
COMMON QUESTIONS
- Who should be allowed to create CRM fields?
- A short list — two or three people, not a department. The purpose is not to say no but to ensure the second field for the same concept is a decision rather than an accident.
- Why can't field sprawl be fixed later?
- Because historical data carries the ambiguity. Once records have been written under three inconsistent definitions, consolidating the fields does not consolidate the history, and you cannot retroactively know what each record meant.
- How do you decide whether to retire a field?
- Safe to remove when it is unpopulated on recent records and no report, view, automation or integration reads it. Age alone means nothing — a three-year-old field feeding the forecast is load-bearing.
- What should be required before creating a field?
- A named report or automation it will feed, a check that no existing field covers it, and a recorded owner. If nobody can name the consumer, the field does not need to exist yet.
WHERE THIS HAS BEEN APPLIED
Client work and research from RevOps HQ, our consulting practice.
KEY TERMS
Data Hygiene
The continuous practice of keeping records accurate, complete and current — as distinct from data quality, which is the state that practice produces.
Field Governance
The rules controlling who may create, alter or retire fields, and the review that applies before they do.
Data Governance
The rules determining who may change what, how changes are reviewed, and how they are recorded. The control that stops a designed system from drifting back to whatever it was before.
Deduplication
Identifying and merging records representing the same person or company.
Single Source of Truth (SSOT)
The declared authority for a given piece of data — the system whose value wins when two systems disagree. Correctly applied it is decided per field, not per system.
Go deeper: CRM Admin 101
The interactive tools behind this writing — process builders, inventories and the audit export — live inside the membership.
See the course