Impact Analysis answers the question every consultant has before touching something in a client org: if I change this, what else will break? Select any metadata component, and dx0 searches the indexed org for references across every relevant metadata type — returning a grouped list of exactly where it's used, with the matching lines in context.
Before you start: indexing
Impact Analysis runs against a local index of the org's metadata, not a live Salesforce connection. When you connect an org, indexing starts automatically. The index covers:
Apex classes and triggers
Flows
Lightning Web Components and Aura components
Visualforce pages and components
Validation rules
Page layouts
Workflow field updates
Reports
Sharing rules and assignment rules
Custom fields
Lightning pages (FlexiPage)
Email templates
Custom labels
That covers every place in a Salesforce org where a field API name, class name, or component reference is likely to appear.
If the org hasn't been indexed, or if significant time has passed since the last index, you can always refresh the index from the org detail page or the "where is this used?" page. We only retrieve changes made since the last index, so in practice in only takes a few seconds.
How the search works
When you select a component and run the analysis, dx0 doesn't just search for the name you typed. For a custom field like Account.CustomerPriority__c, it searches for multiple representations simultaneously:
The fully qualified name (
Account.CustomerPriority__c)The stripped field name (
CustomerPriority__c) — catches usages in Apex code likeacct.CustomerPriority__cThe Salesforce record ID — catches references in layouts and configuration files
The field label — catches references in email templates and reports
Stripped-name results go through a false-positive filter pipeline before they appear in results. For Apex files, an AST parser verifies the field is accessed on the correct object type. For Flows, the filter traces variable types through the flow definition to confirm the reference is genuinely to this field. Results that match the name but can't be confirmed in context are separated into a Similar results bucket at the bottom of the page — they're worth checking manually if you want to be thorough, but they didn't meet the bar for confirmed references.
This distinction matters in practice. A field named Status__c will appear in dozens of Apex files across an org — the filter pipeline strips out the false matches and leaves you with the ones that actually reference your field on your object.
Reading the results
Results are grouped by metadata type — Apex classes, Flows, Validation Rules, and so on — with a match count per file. Click Details on any file to see the matching lines in context (5 lines before and after each match), the full file path, and an AI explanation of why this file references the component and what it does with it.
The result summary tells you how many files matched and how many total files were searched. Zero results is a meaningful signal: if a field has no references across all indexed metadata, it may be genuinely unused.
Field Utilization tab
For custom fields, a Field Utilization tab appears alongside the References tab. This shows what percentage of existing records have a non-null value in this field — a direct measure of whether the field is actually being populated.
A field that appears in many Flows and Apex classes but has 0% utilization in the data is often a sign that the automation that was supposed to populate it isn't working, or was never completed.
Practical scenarios
Before retiring a field. Check that a field has no references in Apex, Flows, or reports, and that the Field Utilization tab shows low or zero data population. Both signals together give you a confident case for marking it for deletion.
Before renaming a picklist value. Picklist value labels appear in Flows, validation rules, and email templates as literal strings. Run the search on the field to find every automation that checks or sets the current value — each one will need updating after the rename.
Before deleting an Apex class. Find every class, trigger, and Flow that references it before removing it. The grouped results show exactly which components have a dependency, so you can plan the removal in the right order.
Scoping a field migration. A client wants to consolidate two overlapping fields into one. Run impact analysis on both to see every place each field is used. The union of those results is your migration scope.
Answering "is this actually used?" A field that has been on the object for years but no one seems to use. Combine the References tab (no automation references it) with the Field Utilization tab (populated on 2% of records) and you have a data-backed answer — not a guess.





