Before deleting or changing any field, object, or class, check dependencies. The Setup UI handles single-component checks; the Tooling API and Salesforce DX handle bulk and automated checks.
- Open the component in Setup
For a custom field, navigate to Setup, then Object Manager, then the object, then Fields and Relationships, then the field name. For an Apex class, Setup, then Apex Classes, then the class name.
- Click Where Is This Used
In Lightning Setup, click Where Is This Used at the top of the detail page. The platform returns a paginated list of every component that references this one, grouped by type.
- Review the impact
Read through the list. Group references by component type to spot the heavy users: a field used in 12 Flows, 3 validation rules, and 2 Apex classes needs careful planning. Components that no longer exist (legacy code) are easy wins; active workflows are not.
- For bulk checks, query MetadataComponentDependency
In the Developer Console or via the Salesforce CLI: SELECT MetadataComponentName, MetadataComponentType, RefMetadataComponentName, RefMetadataComponentType FROM MetadataComponentDependency WHERE RefMetadataComponentName = your-field. Returns the same data as the UI but lets you process it in scripts or reports.
- Plan the change with dependencies in mind
Decide which dependent components stay, which get updated, and which get removed. Document the order: remove or update child references first, then change the parent. Validate against a sandbox before deploying to production.
- Deploy and verify
Use a change set or Salesforce DX deployment. The platform re-checks dependencies during deployment and fails fast if any are missing. If the deployment succeeds, run the affected Flows, classes, and validation rules to confirm behavior matches what you planned.
Single-component check from the Setup detail page. Best for ad-hoc analysis.
Programmatic query of all dependencies. Best for bulk and automated checks.
sf project deploy validate, sf project deploy preview, and dependency-check plugins. Best for CI/CD pipelines.
Strongpoint, Elements.cloud, and similar tools build full dependency graphs across the org for impact analysis.
- MetadataComponentDependency does not cover every reference type. Hard-coded record Ids in formulas, references in dynamic SOQL strings, and runtime field references in Apex are invisible to the dependency API. Static analysis catches the rest; runtime testing catches these.
- Deleting a field that a managed package references requires the package vendor to update first. The platform blocks the delete with a managed-package dependency error. Contact the vendor or uninstall the package before retrying.
- Dependencies on standard objects are not tracked the same way as on custom objects. Many references to standard fields go undetected by the dependency API; verify manually for high-stakes changes.
- Field dependencies (controlling and dependent picklists) and metadata dependencies share the word but not the meaning. Searching Setup for dependency surfaces both, which trips up new admins.