Fill rate is a useful first-pass signal, but it cannot tell you whether a field is safe to change. A guide to reviewing layout, FLS, record-type, formula, validation rule, Apex, and setup-change signals before you touch a field.
Read-only diagnostics · Review-ready workbooks · No package install · No Connected App
You inherit a Salesforce org. There are hundreds of custom fields on the Account, Opportunity, and a few heavily customized objects. Leadership wants the org cleaned up. Nobody can tell you which fields are safe to touch, why they were created, or who still depends on them.
The natural first move is to sort fields by fill rate and start with the ones at 0%. Fill rate is a genuinely useful signal, and it is the right place to begin. But fill rate alone cannot tell you whether a field is safe to change. A field with no data may still be referenced by automation, formulas, validation rules, reports, integrations, or a managed package. A field that looks unused globally may be essential on a single record type.
This guide explains what fill rate does and does not tell you, the additional signals worth reviewing before any change, and how to turn a list of cleanup review candidates into documented decisions backed by supporting evidence. It is written for admins, consultants, and platform owners preparing for cleanup, handoff, UAT, import, or migration work.
A 0% fill rate is a signal, not a decision. It tells you that a field is not currently holding data on the records you measured. It does not tell you whether the field is wired into the way the org works.
An empty field can still be referenced in a Flow or Apex class, used in a formula that feeds another field, checked by a validation rule, surfaced in a report or dashboard, written to by an integration that only fires in certain conditions, or owned by a managed package whose internal logic you cannot see. It may also belong to an old business process that has paused but not ended.
Low fill rate identifies a field worth reviewing. It does not confirm the field is unused, and it never confirms the field is safe to delete.
Fill rate is a strong first-pass usage signal, and it is worth understanding precisely. For a given field, it compares how many records have a value against how many records exist:
Grouping fields into usage bands makes the picture easier to scan. A common approach is active, moderate, low, and unused. Fields in the unused or low bands rise to the top as cleanup review candidates, while active fields can usually be set aside quickly.
This is exactly the kind of signal you want at the start of a review. It narrows hundreds of fields down to a shortlist worth investigating. The mistake is treating the shortlist as a delete list.
Fill rate measures one thing: how often a field is populated. It is silent on almost everything else that determines whether a field can be safely changed.
This is why fill rate works best as one input among several. The sections below cover the additional context and reference signals that turn a usage number into a defensible review decision.
Two fields can share the same low fill rate and mean completely different things. Distinct value count helps tell them apart.
A field with a 3% fill rate and a single distinct value is often a leftover default, a one-time flag, or a field that was set once and never used meaningfully again. A field with the same 3% fill rate but hundreds of distinct values across its history tells a different story — that data was entered deliberately, by many people, over time.
Distinct value count does not decide anything on its own. It helps you judge whether the populated data is meaningful or incidental, which changes how carefully the field needs to be reviewed before any change.
Record types often represent different business processes on the same object. A field can look unused when measured across every record, yet be central to one of those processes.
The same field, two views
Globally, this field looks like an obvious cleanup candidate. On the Partner Account record type, it is clearly part of an active process. Removing or hiding it would break the partner workflow even though the global number suggested it was safe.
Reviewing fill rate by record type, where record types exist, is one of the most effective ways to avoid flagging process-specific fields as global cleanup candidates. For a deeper treatment of this, see the guide to reviewing Salesforce field usage by record type.
Usage and exposure are different questions. Fill rate measures whether a field holds data. Layout presence and field-level security measure who can see and edit it.
A hidden populated field — one that holds data but is not on any layout and is restricted through FLS — is very different from an exposed unused field that sits on a layout but is rarely filled in. The first may be a leftover from a retired integration or migration that nobody can see. The second is visible to users every day even though they ignore it.
FLS also distorts the fill rate itself. If most users cannot see or edit a field, they cannot populate it, which suppresses the number. A field with restricted visibility will almost always look underused, even when it is doing exactly what it was designed to do.
Layout coverage and FLS exposure are supporting evidence for a review decision: they tell you who would be affected by a change, which is often more important than the raw usage number.
Reference signals point you toward the places a field is mentioned in your org's configuration. They do not prove a dependency, but they tell you where to look before making a change.
Supported reference signals
Reference signals are review signals, not guarantees. They tell you where to investigate, not what is safe to change.
Metadata-based review is powerful, but it has real limits. Being honest about them is what keeps a cleanup review trustworthy.
None of this makes metadata review less valuable. It means the output is supporting evidence for a human decision, not a substitute for one. The goal is to narrow the work and surface what to confirm, not to automate the decision.
Before acting on any cleanup candidate, work through the signals in order. Each step adds context; no single step is the decision.
Field cleanup review checklist
For a broader walkthrough of field cleanup beyond fill rate, see the Salesforce field cleanup checklist, and for the wider org context, the Salesforce technical debt assessment.
KeelCadence Field & Object Audit is a diagnostic workbook you run before cleanup, not a tool that makes cleanup decisions for you.
It helps admins and consultants organize field cleanup review by surfacing usage, exposure, cleanup review candidates, supported reference signals, record-type context, setup-change signals, and validation notes in a review-ready XLSX workbook. The signals are gathered in one place so you can move through the checklist above with supporting evidence rather than guesswork.
How the audit works
Relevant Workbook
Field & Object Audit organizes field usage, layout and FLS exposure, cleanup review candidates, record-type context, supported reference signals, setup-change signals, and validation notes into a review-ready XLSX workbook — so cleanup decisions are made with supporting evidence, not fill rate alone.
Evaluating diagnostic tools for access and data safety? See the Salesforce diagnostic tool security checklist.
Fill rate is the right place to start a field cleanup review, and a poor place to end one. Used alone, it turns a shortlist of candidates into a delete list and skips every signal that catches the costly mistakes.
The goal is not to delete fields faster. The goal is to avoid changing fields without enough evidence.
How do I know if a Salesforce field is safe to delete?
There is no single signal that confirms a field is safe to delete. Metadata can tell you how often a field is populated, whether it appears on layouts, who has field-level security access, and whether it is referenced in formulas, validation rules, or Apex source text. These are supporting evidence for a review decision, not proof. A field should only be changed after the signals are reviewed together and a business owner confirms it is no longer needed.
Is fill rate enough for Salesforce field cleanup?
No. Fill rate is a useful first-pass usage signal, but it does not reveal business ownership, automation references, report usage, integration writes, managed package internals, or whether a field matters on a specific record type. A 0% fill rate is a reason to investigate a field, not a decision to remove it.
What is a Salesforce cleanup candidate?
A cleanup review candidate is a field that shows low or no usage and is worth reviewing before any change. It is a starting point for investigation, not a confirmation that the field is unused. Treating a candidate as a delete-ready field skips the review step where most cleanup mistakes are caught.
Why do record types matter during field cleanup?
A field can look unused at the global level but be heavily used on a single record type that represents a specific business process. Reviewing fill rate by record type helps admins avoid flagging a process-specific field as a global cleanup candidate.
Can metadata show whether an integration uses a field?
Not reliably. External integrations write to Salesforce through APIs that are not fully described in org metadata. Metadata may show that a field is populated, but it cannot confirm which external system writes to it or whether that system still depends on it. Integration usage usually requires separate review with the teams that own those systems.
Should managed package fields be included in cleanup review?
Managed package fields should be reviewed with caution. Their internal logic is not visible in your org metadata, so a field that looks unused may still be required by the package. Confirm ownership before changing any field that belongs to a managed package.
KeelCadence Field & Object Audit turns Salesforce field and object metadata into a review-ready XLSX workbook with usage, exposure, cleanup review candidates, record-type context, supported reference signals, setup-change signals, and validation notes.