Salesforce has no single "last used" timestamp on a field, so finding unused fields means combining four signals: the "Where is this used?" button on custom fields (which lists references from layouts, flows, reports, and code), AppExchange field-analysis tools that compute population percentages across your records, SOQL or report sampling to see how many records actually hold a value, and a manual review of page layouts and integrations. A field that is unreferenced and unpopulated is a deletion candidate; a field that is unpopulated but referenced is a process problem, not a cleanup candidate. Vantage Point's Salesforce consultants run this analysis as a structured org audit.
Every Salesforce org accretes fields. A rep asks for a checkbox in 2023; an integration partner maps twelve custom fields "just in case"; a managed package installs its own schema; an acquisition brings a second org's data model along for the ride. Multiply by years and the result is predictable: objects carrying hundreds of custom fields, page layouts nobody can scan, and reports full of columns that return blanks.
The costs are real, and they compound — slower page loads and admin work, confused users, integration mappings that break when someone "cleans up" the wrong field, and in extreme cases the hard ceiling of 500 custom fields per object that forces an emergency cleanup under deadline. Vantage Point covered the cost side in The Hidden Costs of Unused Fields; this guide covers the mechanics of actually finding them.
Before measuring anything, separate the questions:
Reference usage — does anything depend on this field? Page layouts, Lightning pages, flows, validation rules, formula fields, Apex, reports, list views, email templates, integrations. A field with active references is load-bearing even if it looks empty.
Population usage — do records actually contain data in this field? A field that appears on a layout but is filled in on 0.3% of records is functionally dead. A field that is 90% populated is alive even if nobody remembers creating it.
Deletion decisions need both numbers. Reference-only fields (populated but unreferenced) are candidates for layout removal. Population-only fields (referenced but empty) usually indicate a broken process — a form that stopped writing to the field, an integration that was re-pointed. Only fields failing both tests go on the deletion list.
For custom fields, Lightning's Object Manager gives you a head start: open the field's detail page and click "Where is this used?" Salesforce lists the components that reference the field — layouts, Lightning record pages, flows, Apex classes, reports, and similar dependencies — with links to each. It is the fastest way to confirm whether a delete will break something.
Know the limits:
That last gap is why reference checking always ends with an integration inventory: list every system that reads from or writes to the org and grep its configuration for the field's API name before scheduling deletion.
Three practical approaches, cheapest first:
1. Reports and list views. For a quick read on one field, build a report on the object with a filter for "field not equal to blank" and compare the count against total records. Crude, free, and often enough to kill a candidate in five minutes.
2. SOQL sampling. For precision or large objects, run an aggregate count directly:
SELECT COUNT(Id) total, COUNT(My_Field__c) populated FROM My_Object__c
The ratio is your population percentage. Run it per record type if the object serves multiple processes — a field can be essential for one record type and dead for the other three.
3. AppExchange field-analysis tools. When you need this across every field on every major object, automation pays. The Field Trip class of analyzers (and successors such as FieldSpy) scan an object and report per-field population percentages, flagging rarely or never-populated fields for review. These tools are designed to be installed, run, and removed, which suits a periodic audit cadence.
Whichever method you choose, record the numbers. A field-usage spreadsheet — object, field API name, reference status, population percentage, owner, decision — becomes the audit artifact that drives the cleanup project and survives re-orgs.
Field deletion is irreversible, and the data goes with it. The safe sequence:
Cleanup without governance is a treadmill. Two habits keep the schema honest: a field-request intake that requires a business owner, a purpose, and a review date for every new custom field; and a recurring audit — quarterly for fast-moving orgs, annually at minimum — that re-runs the reference and population analysis before the next "we're out of fields" emergency. This is exactly the kind of work covered by ongoing org support, and it connects directly to the broader discipline of paying down CRM technical debt before it compounds.
Vantage Point's Salesforce team runs structured field-usage audits that combine dependency analysis, population measurement, and integration inventory — then manages the deprecate-monitor-delete cycle so cleanup never takes a process down with it. For orgs that want this handled continuously, our managed services and ongoing support include scheduled org health checks. Senior consultants only — no junior handoffs; the experts you meet are the experts who deliver.
Vantage Point can run a field-usage audit across your objects and hand you a prioritized cleanup plan — with the exports and sandbox testing to make it safe. Talk to Vantage Point about a Salesforce org audit.
No. There is no native "last used" timestamp on a field. You approximate usage with population percentages (how many records hold a value), reference analysis ("Where is this used?"), and history tracking if it was enabled — which it usually was not for the fields you are auditing.
On a custom field's detail page in Lightning, it lists components that reference the field — page layouts, Lightning pages, flows, Apex, reports, and similar dependencies — with links to each. It does not cover standard fields, some managed-package internals, or any external system such as middleware or a data warehouse.
AppExchange hosts field-analysis tools in the Field Trip tradition that compute population percentages per field, and browser tooling such as Salesforce Inspector can expose per-field usage columns. For a handful of fields, a report filtered on "not blank" costs nothing and answers the question directly.
Not safely. Dependency results can miss reference types and never include external integrations. Export the data, deprecate and hide the field for a full business cycle, test deletion in a sandbox, and only then delete in production.
Orgs can hit a hard ceiling — commonly 500 custom fields per object depending on edition — and teams that hit it discover cleanup under deadline is the worst kind. Regular field-usage audits keep you nowhere near the limit.
Both, in sequence. Remove from layouts first to reduce user noise while preserving data and dependencies. Delete only after the field passes both tests — unreferenced and unpopulated — and survives the deprecate-and-monitor window.