On this page9 sections
Why unused fields deserve a review
Every CRM accumulates fields that seemed useful at the time. A launch adds a campaign source, a sales experiment adds a qualification score, and a partner program adds a referral code. Months later, some of those fields are empty, some are filled by automation, and some are edited by hand in ways nobody can explain. An unused field is not harmless, because reports, forms, and integrations keep treating it as if it still matters. A short monthly review finds those fields before they distort a dashboard or slow down the team.
Define what counts as unused
Start by defining the observation window and the evidence that makes a field "unused." A field with no values in the last ninety days is a candidate, but only if the team also confirms that no report, form, automation, or integration depends on it. Count manual entries separately from values written by a workflow, because an automation can keep a field populated long after anyone reads it. Record the definition before pulling the list so the review does not drift toward whichever fields are easiest to remove. Keep the definition visible to everyone who runs the review. Revisit it only when the team's process changes.
Pull the field inventory before the values
Export the field inventory first: object, field name, API name, type, owner, and last modified date. Then pull the share of records with a value and the number of distinct values for each field. Doing the inventory first makes the value query easier to reproduce and prevents a reviewer from guessing which fields exist. Save both extracts with the date and the user who ran them. The inventory is the stable list; the value counts are the evidence that changes month to month.
Check reporting and automation dependencies
Before proposing a retirement, search every report, dashboard, list view, form, and automation for the field's API name. Exports of report definitions are more reliable than asking people whether the field is used, because a report can be owned by someone who left the team. Record each dependency and its owner. If a dashboard reads the field but shows it only to an executive, that is still a dependency. A field is not a retirement candidate until every dependency has an owner and a decision.
Separate empty from low-use
A field with few values may still be essential, especially if it records a rare exception or a compliance decision. Review the actual values rather than only the count. A field used twenty times but tied to a legal hold is more important than a field used a thousand times for a campaign tag nobody reads. Classify each candidate as empty, low-use but meaningful, duplicated by another field, or superseded by a system of record. The classification decides whether the answer is retirement, consolidation, or a documentation fix.
Retire in stages, not in one sweep
Retirement should be a staged change. First hide the field from forms and layouts while keeping the data in place. Wait a full reporting cycle and confirm that no query breaks and no user asks for it back. Then remove it from automations and integrations, and only after that mark it as deprecated in the schema. Deleting the field is the last step, and for regulated or customer-history data it may never be appropriate. The stages give the team a chance to notice a dependency that the audit missed.
Preserve the history that matters
Before any destructive change, export the field's values for the records in scope and store the extract with the review notes. If the field feeds a historical report, keep a snapshot of that report rather than relying on the field remaining available. Document the retirement date, the approver, and the replacement field if one exists. This record protects the team when someone asks months later why a number changed. It also makes the retirement reversible long enough to investigate a surprise.
Make the review part of the operating rhythm
Run the review on the same day each month, with the same inventory export and the same dependency search. Keep a short list of fields approved for the next stage and fields that need more evidence. Review the previous month's changes first, because a field that was hidden last month may now be safely removed. The rhythm matters more than the size of the list. A small, consistent review prevents the slow accumulation that makes a CRM hard to trust.
Watch for the social cost of cleanup
Field cleanups sometimes fail because they remove something a person relies on without telling them. Announce candidate fields to the teams that own the records, and give them a week to object with a reason. Treat an objection as evidence, not obstruction, and record the decision. The goal is a schema that matches how the team actually works, not a tidy list that ignores practice. A review that people trust will be repeated; one that surprises them will be resisted.
