You've inherited an org, or you're finally cleaning one up, and the question is the same: which of these hundreds of custom fields are actually dead? Salesforce makes it surprisingly hard to answer — there's no "last used" date on a field and no built-in view of how full it is.
Before you delete anything, it pays to be precise about what "unused" even means, because the word hides two different questions.
"Unused" is two questions, not one
A field can be unused in two unrelated ways:
- Nobody fills it in. The field exists, but its column is mostly empty — near
0%populated across the records. That's a data question. - Nothing references it. No flow, validation rule, formula, report, layout, or integration points at it. That's a dependency question.
These are independent, and that's the trap. A field that's 0% populated can still be wired into a flow that's about to start writing to it. A field that's 100% full can be dead weight nothing reads — populated once by an old integration and ignored ever since. Safe to delete needs both answers: no data and no references. Treat either one alone as "unused" and you'll eventually delete something load-bearing.
Finding the fields nobody fills in
Salesforce has no native field-usage report, so the population question takes manual work. The aggregate route is per field:
SELECT COUNT(Region__c) populated, COUNT(Id) total
FROM Account
COUNT(Region__c) counts the records where the field is non-null; compare it to the total to get a fill rate. It's accurate, but it's one query per field, and COUNT() only tells you the field holds data — not that anyone uses it. The alternative — exporting the object and counting blanks in a spreadsheet — is the same answer with more steps. Either way, on an org with a few thousand custom fields this is a project, not a check, which is exactly why it rarely gets done.
Checking what references a field
For the dependency question, Setup → the field → Where is this used? is the native starting point. It catches some references, but it misses whole categories and tells you nothing about automation order, where the real surprises live. So the careful admin opens the flows, reads the validation rules, and scans the reports by hand — thorough, slow, and easy to leave incomplete.
Empty is not the same as safe to delete. Population tells you nobody fills it in; only dependencies tell you nothing breaks.
Doing both at once
This is where SchemaForce earns its place in a cleanup. An opt-in usage scan runs aggregate COUNT() queries across your objects — counts only, never the values inside records — and returns a population figure for every field. You can sort least-used first, filter to "≤ 5% used," and limit to custom fields, so the long tail of dead columns surfaces in seconds instead of a week of SOQL.
It's deliberately careful about what that means. A field that's custom, barely populated, and undocumented gets flagged as a likely cleanup candidate — phrased exactly that way, "likely unused," never "safe to delete." For the second half of the decision, the field's impact view traces what references it: the validation rules, layouts, lookups, automations, and integrations in its path. Pair "nobody fills it in" with "nothing reads it," and a deletion you'd otherwise dread becomes one you can defend.
Be honest about "unused"
A few limits worth stating plainly, because cleanup is where overconfidence gets expensive. Population is a data signal, not a reference signal — keep them separate. The cleanup flag is "likely unused," a prompt to review, not a delete button. The usage scan is opt-in and point-in-time — a timestamped snapshot, not real-time — and on a very large org it can be partial, since it works within an API budget and skips objects it can't count. The dependency map is drawn at the level of which components reference a field: it names the flow, it doesn't read the flow's internal logic, and its automation coverage is strongest for custom fields. And all of it is metadata only — definitions, counts, and dependencies, never the contents of your records.
Field cleanup is one of the highest-leverage things you can do to an aging org, and one of the easiest to do badly. The way to do it well isn't a bigger delete button — it's having both answers, population and references, in front of you before you touch a thing.
