Salesforce Dependency Analysis: 2 Checks and 9 Steps

Salesforce dependency analysis shows which components use a field, flow or class, so you know what breaks if you change it. Start with Where is this used? on the field page. Then query the Tooling API object MetadataComponentDependency for a fuller list.

Clientell AI, the AI Salesforce admin, maps those dependencies for you in read-only mode and shows what would break before any change. Start with the free Salesforce health check. The manual method follows.

How do I see where a field is used in Salesforce?

Open Setup, then Object Manager, then the object, then Fields and Relationships, then the field. Click Where is this used?. Salesforce lists the components that reference that custom field, such as page layouts, flows, validation rules, formula fields and Apex classes.

It takes under a minute per field. That is also its limit. You check one field at a time, and you cannot export the result in bulk.

How do I query dependencies with the Tooling API?

The Tooling API object MetadataComponentDependency stores one row per link between two components. The component that uses something is MetadataComponent.... The thing it uses is RefMetadataComponent.... You can query it from the CLI or any REST client.

First, get the field's Id from the Tooling API:

SELECT Id, DeveloperName, TableEnumOrId
FROM CustomField
WHERE DeveloperName = 'Region'

Then list what uses it:

SELECT MetadataComponentName, MetadataComponentType
FROM MetadataComponentDependency
WHERE RefMetadataComponentId = '00N000000000001AAA'

Run it with the Salesforce CLI:

sf data query --use-tooling-api --query "SELECT MetadataComponentName, MetadataComponentType FROM MetadataComponentDependency WHERE RefMetadataComponentId = '00N000000000001AAA'"

Replace the Id with your field's Id. For example, on a field used in one layout, one validation rule and one flow, the rows come back as Layout, ValidationRule and Flow. A flow can show up more than once, because each flow version is its own component.

To list every custom field that something references, filter by type instead:

SELECT MetadataComponentName, MetadataComponentType,
       RefMetadataComponentName, RefMetadataComponentType
FROM MetadataComponentDependency
WHERE RefMetadataComponentType = 'CustomField'

Any custom field missing from that result has no tracked references. That makes it a candidate for cleanup, not a verdict.

What are the limits of MetadataComponentDependency?

Salesforce documents these limits on the object (Salesforce Developers, MetadataComponentDependency):

We ran these against a developer org to check. A filter on RefMetadataComponentType and on RefMetadataComponentId worked. A filter on RefMetadataComponentName returned an error, and COUNT() was not supported. Test your own org, because behavior can change between releases.

A big org needs a narrow query per type under the 2,000 cap, or a Bulk API 2.0 export.

What does each method miss?

Neither method sees everything. This table shows the gaps.

Two gaps matter most. First, outside systems leave no trace in metadata. An integration can write to a field every month, and no dependency tool will show it. Second, Apex that builds a query as a string, such as 'SELECT ' + fieldName, hides the field name from the parser. Search your code for the field's API name as plain text too.

Metadata shows what the setup references, not what people or systems do with the field. Pair it with a fill count. Our guide to finding unused fields shows the SOQL for that.

How do I check before I delete or change something?

1. Run Where is this used? on the field.
2. Run the Tooling API query for the field's Id.
3. Search reports for the field's label, because the Tooling API leaves reports out.
4. Search your Apex and flows for the API name as text.
5. Ask the owner of each connected system if it reads or writes the field.
6. Count the filled values with SOQL, to see if data still flows in.
7. Hide the field from layouts and turn off field-level security.
8. Wait through one business cycle, such as a month-end close.
9. Delete in a sandbox first, then in production.

A deleted custom field can be restored for 15 days, then it is erased with its data (Salesforce Ben). Export the data before you delete.

Dependency checks matter for more than fields. For flows, see how to clean up Salesforce flows. For the wider picture, read the technical debt guide.

How do I run a dependency check in Clientell AI?

The safe order is a read-only scan first, then sandbox, with rollback ready. Clientell AI asks before it changes anything in production. See privacy and security.

Try it in Clientell AI: "Show everything in my org that uses the Region field on Account, including flows, reports and layouts, and tell me what breaks if I delete it."

Start the 14-day trial, no card needed.

FAQ: common questions about Salesforce dependency analysis

What is the best Salesforce dependency analysis tool?

For one field, Where is this used? is the fastest. For a list across the org, query MetadataComponentDependency. Third-party tools and Clientell AI add reports, code search and ranking. Compare what each one reads.

Can I query dependencies for a flow or an Apex class?

Yes. Use the component's Id in the RefMetadataComponentId filter, or filter MetadataComponentType to find what a type uses. The same limits apply.

Sources for this Salesforce dependency analysis guide

• Salesforce Developers, MetadataComponentDependency
• Salesforce Ben, How to restore deleted Salesforce fields
• Query tests run in a Salesforce developer org on 09-10-2026.

Last updated: October 9, 2026