HOW TO CHECK WHERE A SALESFORCE FIELD IS USED BEFORE DELETING IT.

Deleting a Salesforce field is fast. Finding out afterward that a Flow, a formula, or a nightly integration depended on it is not. Before you delete, repurpose, or rename a custom field, it is worth a few minutes to check what actually references it.

This is a practical checklist, not a guarantee. No check — manual or tool-assisted — proves a field is safe to delete. It reduces how much you are guessing.

1. 01Start the native delete flow, then stop. In Setup, begin deleting the field. Salesforce will list any references it detects before you confirm — read the list, then cancel if you want to investigate further before committing.
2. 02Check formula fields on the same and related objects. Formula fields that reference the field will not always surface clearly in the native check, especially across object relationships.
3. 03Search Flows for the field's API name. Include inactive and deactivated Flows — a paused automation can still represent a real dependency someone plans to reactivate.
4. 04Check Validation Rules and Apex. Validation Rule conditions and Apex classes or triggers that reference the field's API name in code are easy to miss with a UI-only review.
5. 05Check Reports and Page Layouts. A field can be report-critical for a team that never touches the underlying automation — check whether it appears in report filters, groupings, or columns, and on any active layout.
6. 06Ask outside Salesforce. None of the above sees external systems. Confirm with integration owners, marketing automation admins, and reporting/BI owners whether anything reads or writes the field's API name from outside the org.
7. 07Document what you found before acting. Whatever you find — or don't find — write it down. A one-line "checked, nothing found" note is worth far more after the fact than a field that was simply deleted.

Salesforce's field-deletion flow is a real, useful check — it commonly blocks deletion when it detects references in formula fields, some Validation Rules, some automation, and Page Layouts. For a single field, deleted carefully, reading what it reports is often enough.

It runs one field at a time, at the moment of deletion, and does not produce a record you can review, share, or file before you reach that screen — which is the gap the rest of this checklist, or a structured tool, exists to close.

If you are reviewing more than one field, or you want a documented result instead of a manual pass you have to trust from memory, Dependency Map runs steps 2 through 5 above — Apex, Flows, Workflow Rules, Validation Rules, formula fields, Reports, and Page Layouts — for every selected custom field on one object in a single read-only run, and labels every finding Direct or Heuristic so you know which ones still need a human look.

It does not replace steps 1, 6, or 7 above. Salesforce's own delete-time check and a conversation with your integration owners are still worth doing — Dependency Map exists to make the metadata-side review faster and documented, not to replace judgment.

For where Dependency Map fits alongside KeelCadence's other workbooks, see Salesforce Audit Tools: Where KeelCadence Fits.