What is field governance?

Control over the field layer: what exists, who may add or change a field, what each field means, and when unused fields are retired. It is the most concrete part of data governance and usually the highest yield.

Why do CRMs accumulate unused fields?

Because creating one is easy and retiring one requires knowing whether anything depends on it. Absent a review cycle, fields only accumulate, and the cost is paid by every user who fills in a form.

How do you decide whether a field can be deleted?

Check whether it feeds a live report, view, automation or integration, and check its population rate. A field feeding nothing and populated on a small share of records is a candidate — deprecate it before deleting.

Who should be allowed to create fields?

A named, small group, with a stated request path for everyone else. Open field creation is the single most reliable way to end up with several fields meaning the same thing.

Field Governance

The rules controlling who may create, alter or retire fields, and the review that applies before they do.

Why the field layer matters

Every field is a small tax on everyone who touches a record and a permanent obligation to keep it meaningful. Fields are created in seconds and retired approximately never, so the layer only grows — and its growth is paid for in adoption.

The connection to adoption

Removing fields nothing reads is consistently the highest-yield change to CRM adoption and the least often attempted. It reduces the work the system imposes without reducing anything it returns, which is exactly the trade that changes a user's willingness to use it.

The audit

Enumerate every custom field per object, with its creation date and creator if available.
For each, determine whether it feeds a live report, a saved view, an automation or an integration. This is the dependency check and it is the part that takes the time.
Compute population rate on records created in the last quarter — not all-time, which flatters fields that were used once and abandoned.
Classify: in use; populated but feeding nothing; neither populated nor used. The third group is straightforward removal.
Look for synonyms — several fields capturing the same concept under different names. These are the ones causing reporting disagreements.

Retirement without breakage

Deprecate before deleting: remove from layouts, mark the label, and wait a full reporting cycle. Anything depending on it will surface.
Export the values before deletion. Cheap insurance against a dependency nobody found.
Delete in small batches with a gap between them, so a break can be attributed to a specific change.

Controlling the flow

An audit fixes the stock once. The layer regrows unless field creation is restricted to a named group with a request path, every new field carries a stated purpose and owner, and there is a scheduled review. Without those three, the same audit is due again within a year — which is the general pattern for any governance treated as a project rather than a structure.

RELATED TERMS

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.

Data Hygiene

The continuous practice of keeping records accurate, complete and current — as distinct from data quality, which is the state that practice produces.

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.

COMMON QUESTIONS

What is field governance?: Control over the field layer: what exists, who may add or change a field, what each field means, and when unused fields are retired. It is the most concrete part of data governance and usually the highest yield.
Why do CRMs accumulate unused fields?: Because creating one is easy and retiring one requires knowing whether anything depends on it. Absent a review cycle, fields only accumulate, and the cost is paid by every user who fills in a form.
How do you decide whether a field can be deleted?: Check whether it feeds a live report, view, automation or integration, and check its population rate. A field feeding nothing and populated on a small share of records is a candidate — deprecate it before deleting.
Who should be allowed to create fields?: A named, small group, with a stated request path for everyone else. Open field creation is the single most reliable way to end up with several fields meaning the same thing.