2026-06-19 · FieldRat
How to find unused fields in Salesforce
Most Salesforce orgs accumulate custom fields faster than anyone reviews them. Before you delete one, you need to know two things: is anyone using it, and what else depends on it. Here's how to answer both without breaking production.
Why "unused" isn't the same as "safe to delete"
A field can sit at 0% population and still be load-bearing. The classic case: a formula field on a related object references it, so the field itself never gets touched by a user but the formula breaks the moment you delete it. Same with old integration mapping fields — a legacy lookup from a sunset middleware tool can show zero record activity for years while a scheduled Apex batch still queries it nightly. Population percentage answers "does anyone fill this in." It does not answer "does anything reference this." You need both before deleting anything.
Step 1: Check field population
Start with how often a field actually holds data across your records. A field at 0–2% population across a large object is a strong unused-field candidate — but check the object's record count first; a 0% field on an object with 40 records isn't the same signal as 0% on an object with 400,000. Manually, this means exporting records and counting non-blank values per field, which doesn't scale past a handful of fields. FieldRat's Field Analysis runs this as an async Salesforce batch job and reports population percentage per field without any record data leaving the org.
Step 2: Scan for dependencies before you touch anything
Low population doesn't mean low risk. Check whether the field is referenced by:
- Validation rules and formula fields
- Flows, Process Builder, and workflow rules
- Apex classes, triggers, and test classes
- Reports, dashboards, and list views
- Page layouts and Lightning record pages
- Integrations and API field mappings
Setup's native "Where is this used?" view covers a subset of this, one field at a time, and misses flows and Apex references entirely in most orgs. FieldRat's Quick Scan checks 11 metadata types natively in seconds across however many fields you select at once; Deep Scan extends to 23 metadata types via a metadata ZIP for full coverage — including Apex and flow references — before a retirement decision.
Step 3: Score the deletion risk
Population percentage and dependency count are two separate numbers — combining them into one score is what makes prioritization across hundreds of fields tractable instead of a spreadsheet you never finish. FieldRat computes a 0–100 Deletion Risk Score from usage, dependency breadth, and whether any dependency hit lands in a critical metadata type (Apex, flows, integrations). A field with 0% population, three dependency hits, and none of them critical sorts to the bottom of the risk list — that's your safe-to-review queue, ranked instead of guessed at.
Step 4: Retire with evidence, not guesswork
Before deleting a field in production, you want an audit trail: who reviewed it, what the dependency scan showed, and when it was retired. FieldRat's retirement workflow produces audit-ready Excel and CSV exports of the scan results, so the deletion decision has paper behind it if anyone — a compliance reviewer, your manager, or your own future self six months from now — asks why a field disappeared.
FieldRat runs all of this natively inside Salesforce, free, with Field Analysis and Field Dictionary always included.
See how FieldRat compares to other field cleanup tools on the comparison hub, or read the full docs.