Require a field contract
Before creating a field, record the decision it supports, object, type, allowed values, source, owner, sensitivity, and retention. If nobody can name a workflow or report that consumes it, the field may not belong in the production schema.
Reuse a clear existing field only when its definition truly matches; overloaded fields create invisible coupling.
Control enumerations and changes
Stable internal values should be distinct from display labels. Renaming a label can be harmless, while changing an internal value can break integrations and historical reporting. Version significant changes and test downstream consumers.
Restrict free text when the data drives automation, but provide an escape path for genuinely new cases.
- Business definition
- Technical name
- Type and values
- Source of truth
- Consumers
- Sensitivity
- Owner
Retire instead of endlessly hiding
Measure population, freshness, and consumption. When a field is obsolete, stop new writes, migrate consumers, archive required history, and then remove or lock it according to platform capability.
Maintain a searchable data dictionary that reflects the deployed schema, not an aspirational spreadsheet.
Select ten active fields and identify their owner, source, consumers, and last meaningful use; queue any field that cannot be explained for review.