2026-06-19 · Updated 2026-07-26 · 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.

Quick answer: how to find unused fields in Salesforce

Run a field usage report and flag fields at 0–2% population relative to the object's record count. Setup has no built-in report for this — export and count, or use a tool.
Scan every candidate for metadata references — flows, formulas, validation rules, Apex, reports, layouts, integrations — before deleting. Zero population does not mean zero dependencies.

Four different things people mean by "unused"

Cleanup conversations go wrong because "unused" hides four separate questions. Be precise about which one you're testing:

Unpopulated — the field rarely or never holds a value. Measured by population percentage across records.
Not recently changed — the field holds stale values nobody has updated in months. A field can be 90% populated and still be dead weight from a process that ended years ago.
Not referenced — no flow, formula, validation rule, Apex class, report, or layout points at it. This is a metadata question, not a data question.
Truly unused — unpopulated and unreferenced and not needed by any external system or process. Only this category is a retirement candidate.

Population checks answer the first two. Dependency scans answer the third. The fourth needs both plus a human review — which is why the rest of this guide runs in that order.

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.

Field Analysis Dependency scanning 0–100 risk score Retirement workflow

FieldRat runs all of this natively inside Salesforce, free, with Field Analysis and Field Dictionary always included.

Beyond fields: unused objects, flows, and validation rules

The same two-signal method — usage first, dependencies second — extends to the rest of your org's cleanup backlog. An object with no record creates in a year is a candidate, but check lookups, flows, and Apex that reference it before archiving. A flow with zero interviews in its run history still needs a check for subflow calls. A validation rule that never fires might be inactive by luck, not by design — confirm what bypasses it before deleting. Fields are the highest-volume cleanup target and usually where the platform limit pressure is (see the custom field limit guide), but the discipline is identical at every layer: measure, scan, then retire with evidence.

Want the whole org checked in one pass — access risk, silent failures, and upcoming deprecations alongside field debt? TechParrot (the team behind FieldRat) runs a free OrgAudit — 65 automated checks, read-only, with an executive-ready report.

Finding unused fields in Salesforce: FAQ

How do I find unused fields in Salesforce?

Run a field usage report to find custom fields at 0–2% population relative to the object's record count, then scan each candidate for dependencies across flows, validation rules, Apex, reports, and layouts before deleting. Low population alone isn't enough — a 0% field can still be referenced by a formula, flow, or integration.

How do I find unused objects, flows, and validation rules in Salesforce?

The same two-step method applies beyond fields: measure usage (population or last-referenced activity), then check dependencies before removing anything. FieldRat scans references across up to 23 metadata types — including flows, validation rules, Apex, and layouts — so you can see what is genuinely unused versus what is quietly load-bearing.

Is there a Salesforce field usage report?

Setup has no built-in field usage report. You either export records and count non-blank values per field manually (which doesn't scale), or use a tool. FieldRat's Field Analysis runs as an async Salesforce batch job and reports population percentage per field without any record data leaving the org.

Does field usage mean the same as field population?

Not quite. Field population measures how often a field holds a value across records. Field usage in the cleanup sense also includes whether metadata — flows, Apex, reports, layouts — references the field. A field can have 0% population yet high usage if something depends on it. Safe deletion needs both signals.

Do I need a full Salesforce org audit or just field cleanup?

They answer different questions. Field cleanup (FieldRat) works the field dimension continuously — usage, dependencies, safe retirement. A full org audit checks everything once: access risk, silent failures, upcoming deprecations, and field debt together. TechParrot, the team behind FieldRat, runs a free 65-check OrgAudit (techparrot.io/products/orgaudit) — a common pattern is OrgAudit first to diagnose, FieldRat after to keep fields clean.