How to find everywhere a Salesforce field is used
Salesforce will tell you most of the places a field is referenced. The dangerous part of the answer is the remainder — the references no static check can see, which is exactly where deletions go wrong.
9 min readStart with “Where is this used?” on the field, then query MetadataComponentDependency in the Tooling API for a list you can actually work with. Between them you will find layouts, formulas, validation rules, Apex, Flows, reports and most of the rest.
Then handle what neither one sees: field names assembled as strings in Apex or dynamic SOQL, references from Experience Cloud and managed packages, and every external system that reads the field through the API. Those are invisible to static analysis and are the usual cause of a deletion that breaks production a week later.
What the native tooling gives you
Every field in Object Manager has a “Where is this used?” action. It walks the metadata references and returns the components that point at the field — page layouts, record types, formula fields, validation rules, Flows, Apex classes, reports. For a single field on a small org this is often the whole answer, and it should always be the first thing you run.
Its limitation is shape, not accuracy: it is a screen. You cannot diff it, you cannot run it over four hundred fields, and you cannot attach it to a change request as evidence. For anything beyond a one-off check you want the same information as data.
That is MetadataComponentDependency, a Tooling API object you can query with SOQL. It returns dependency edges — a refId and refType for the thing being used, an id and type for the thing using it — and it is what most impact-analysis tooling is built on. It covers a broad set of component types, and it is queryable, which is the part that matters.
What no static reference check will find
Each of these is a real reference that leaves no trace a dependency query can follow. They are the reason “nothing uses this field” is a claim, not a finding.
Field names built as strings
Dynamic SOQL, Database.query(), and anything that composes an API name from a variable or reads it from custom metadata. The field is used; the reference exists only at run time. The same applies to dynamic getSObject access and to field sets resolved by name.
Consumers outside the org
An ETL job, a MuleSoft flow, a data warehouse extract, a partner integration, a reporting tool with its own SOQL. None of them are metadata in your org, so nothing in your org knows they exist. This is usually the largest category and the one discovered last.
Managed package internals
A managed package can reference your field without exposing how. Dependency queries will tell you a package component is involved but not what it does with the field, and you cannot inspect the implementation.
Anything that reads it as data, not as schema
Reports and dashboards saved by users, list view filters, Einstein or analytics models trained on the column, and exports someone automated years ago. Some of these surface, many do not, and none of them fail loudly when the field disappears.
Closing the gap before you change anything
Get the static picture as data
Query
MetadataComponentDependencyfor the field rather than reading the screen, so you have a list you can attach to the change and re-run afterwards. Expect to follow it transitively: a formula field that uses your field is itself used by something else, and the second hop is where the surprise usually lives.Grep the code for the API name
Search the whole codebase — Apex, LWC, Aura, Visualforce — for the literal API name as a string, not just as a field reference. Anything that concatenates or interpolates it will show up here and nowhere else. Include the object-qualified form and the bare form.
Check what leaves the org
Enumerate the integrations that read the object at all, then check each one's field selection. API call logs and Event Monitoring will tell you who is querying the object; the integration's own configuration tells you which fields it asks for.
Deprecate before you delete
Where the answer is uncertain — and after the steps above it usually still is for a widely used field — do not delete. Remove it from layouts, revoke field-level security, rename the label to mark it deprecated, and wait a full business cycle. A field nobody can see but everything can still query fails safely; a deleted field does not.
Where aprity fits
aprity builds the dependency graph from the org's metadata deterministically, then computes the blast radius of a proposed change against it: pick a field, an object or an Apex class and a change type, and it returns what is downstream, node by node. Because it is computed rather than inferred, the same question returns the same answer every time and the result is reproducible for a reviewer.
It also maps integrations from the actual call sites in the code, which is the category that static reference checks miss most often. What it cannot see, nothing can: a field name assembled at run time is invisible to every static analysis, aprity's included — the deprecate-before-delete step above is still the right habit.
- Blast radius computed from the graph, not inferred by a model
- Node-level detail — what reads, what writes, what calls
- Integration map driven by real call sites in the code
- Reproducible: the same change question, the same answer
How to find everywhere a Salesforce field is used — FAQ
Is “Where is this used?” reliable?
For metadata-to-metadata references it is generally accurate, and it should always be your first check. What it cannot report is anything resolved at run time — dynamic SOQL, field names built as strings — or any consumer outside the org, because neither is metadata. Treat it as a floor on the answer, not a ceiling.
What is the Dependency API?
MetadataComponentDependency is a Tooling API object you can query with SOQL to get dependency edges between metadata components. It gives you the same class of information as “Where is this used?” in a form you can script, diff and attach to a change request, which is what makes it usable beyond a single field.
Can I safely delete a custom field that shows no references?
Not on that evidence alone. No reference check sees dynamic references or external consumers, so “no results” means “no results from this tool”. Deprecate first — remove it from layouts, revoke field-level security, mark the label — and let a full business cycle pass before deleting, so anything that still depends on it surfaces while the field is recoverable.
How do I find what a field change breaks, not just where it is referenced?
References are one hop; impact is the transitive closure. A formula that uses your field is used by a report, which feeds a dashboard someone runs monthly. Follow the graph outward rather than reading a flat list, and record the depth you searched to — an impact statement without a stated boundary is not verifiable.
Related guides
How to document a Salesforce Flow
Flow Builder shows you the canvas. It does not tell you what the Flow changes, what it depends on, or what breaks when you edit it — and those are the three things anyone reading the documentation actually needs.
Read the guide GuidePreparing a Salesforce org for an ISO 27001 audit
The certificate is for your information security management system, not for your org. What the auditor wants from Salesforce is narrower and more awkward: evidence that access, change and logging work the way your policy says they do.
Read the guideSee it on your own org, not on a slide.
A free 14-day evaluation documents your org from a computed dependency graph — read-only, no credit card, and you review the output before deciding anything.