IAPL - Where Used

Find what uses a Salesforce component, and what the component uses, before you change or delete it.

How it works

The panel opens at once with the current sf target-org selected. The other authenticated orgs load in the background.

1. Pick the type: field, custom object, Apex class, trigger, flow, validation rule, layout, Lightning page, custom label, LWC, Aura, Visualforce page or component, or static resource.
2. Filter the component list by typing. It shows what exists in the repo right away, then adds what exists in the selected org. Components found in only one place are marked. Pick with a click or with the arrow keys and Enter.

You can also right-click a file in the explorer, or put the cursor on a name in the editor and press Ctrl+Alt+U.

The result has three blocks:

• Used by (org): MetadataComponentDependency references to the component. Flow versions are grouped by flow, marking whether the active version uses it. Old versions also block a deletion.
• Uses (org): what the component references, for example the fields a validation rule or a flow reads. Fields are shown with their object (Quote.TaxGroup__c). Click a name to search for it.
• Repo: git grep over the package directories in sfdx-project.json, including untracked files. Hits are grouped by category. Profiles and permission sets are marked for cleanup. Translations are highlighted because they break deploys when the component is gone. A hit that is only a namesake (same field API name on another object) is tagged possible or dropped when the line names the other object.

A verdict sums it up: in use, free, or free after cleaning permissions and translations. Copy Markdown puts the report on the clipboard for a ticket or PR.

Limits

Salesforce does not record who calls a flow (subflows, Apex, LWC), nor references to standard fields or standard objects. For flows the panel still shows what the active version uses; used-by comes from the repo only, and the panel says so.

Requirements

Salesforce CLI (sf) with an authenticated org and git on PATH. The session is read once per org with sf org display and kept in memory to run queries over REST. The token is never shown or stored.