Field Dependency Analysis

SALESFORCE FIELD DEPENDENCY ANALYSIS.

Before you change, repurpose, or retire a custom field, field dependency analysis maps what references it — so the decision is made with evidence, not a guess.

Read-only diagnostics · Review-ready workbooks · No package install · No Connected App

Salesforce field dependency analysis is the practice of identifying what references a specific custom field before you act on it — a Flow that reads it, a formula field built on it, a Validation Rule that checks it, a Report that groups by it, a Page Layout that displays it.

It matters most in one moment: right before you change, repurpose, or retire a field. A field that looks unused in isolation can still be quietly load-bearing for a process nobody documented.

Evaluated Coverage

WHAT FIELD DEPENDENCY ANALYSIS EVALUATES.

A structured field dependency review looks across the metadata categories most likely to reference a custom field on a selected object:

  • Apex classes and triggers
  • Flows
  • Workflow Rules
  • Validation Rules
  • Formula fields
  • Reports
  • Page Layouts

The scope is deliberately bounded to one selected object at a time — a field-by-field pass across an entire org is not the goal. The goal is a defensible, documented answer to one question: what references the fields on this object, right now, within these categories?

Evidence Model

DIRECT VS. HEURISTIC, NEVER BLENDED.

Not every reference carries the same confidence. Direct references are explicit, structural matches — a Flow element, a formula, or a Validation Rule that names the field directly. Heuristic references are source-text matches that surface a possible connection but require manual verification before anyone relies on them.

The two are never blended into a single count. A field with five Heuristic hits and zero Direct references is not the same review priority as a field with two Direct references, and a workbook that collapses that distinction into one number is hiding the exact information a reviewer needs.

Heuristic findings are leads to verify — not conclusions to act on.

What Salesforce Already Does

WHERE NATIVE SALESFORCE TOOLS ARE ALREADY ENOUGH.

Salesforce is not blind to field usage. When you attempt to delete a custom field, Setup runs its own dependency check and blocks the deletion if it detects certain references — commonly in formula fields, some Validation Rules, some automation, and Page Layouts.

For a single field, deleted one at a time, with time to read and act on whatever Setup reports, that native check is often sufficient on its own. It is free, it is built in, and it catches a meaningful share of blocking dependencies.

Where it runs out of usefulness is scale and documentation: it evaluates one field at a time, only at the moment of deletion, and it does not produce a reviewable record you can share with a stakeholder, a client, or your own future self before you get that far.

Limits

WHAT FIELD DEPENDENCY ANALYSIS DOES NOT CLAIM.

  • It does not claim to find every dependency, and it does not produce a complete dependency graph
  • It does not tell you a field is safe to delete
  • Heuristic references require manual verification and are never counted toward review priority on their own
  • Coverage is limited to what the connecting user can see in Salesforce, and to the evaluated metadata categories
  • It does not see external systems, middleware, or integrations that reference a field's API name outside Salesforce

For the external-system side of this problem specifically, see Salesforce external field dependencies.

When To Run It

WHEN TO RUN A FIELD DEPENDENCY REVIEW.

  • Before you delete, repurpose, or rename a custom field
  • Before a cleanup or field-deprecation decision, alongside fill-rate and usage review
  • Right after inheriting an org where field history is undocumented
  • When a stakeholder asks what depends on a specific field before a change request is approved
  • As part of consultant discovery, to document field dependencies for a client handoff

For the practical, step-by-step version of this — checking one specific field before you delete it — see how to check where a Salesforce field is used before deleting it.

Relevant Workbook

Dependency Map

Dependency Map surfaces detected references within evaluated coverage across Apex, Flows, Workflow Rules, Validation Rules, formula fields, Reports, and Page Layouts for the custom fields on one selected object — with Direct vs. Heuristic labels throughout.

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

FAQ

FREQUENTLY ASKED QUESTIONS.

What is Salesforce field dependency analysis?

Salesforce field dependency analysis is the process of identifying what references a specific custom field — in Apex, Flows, Workflow Rules, Validation Rules, formula fields, Reports, and Page Layouts — before you change, repurpose, or retire it. It is a review step, not an automatic guarantee.

Does field dependency analysis prove a field is safe to delete?

No. It surfaces detected references within evaluated coverage. It does not claim to find every dependency, and it does not tell you a field is safe to delete. Findings are review candidates that still require validation against the evidence detail.

What is the difference between Direct and Heuristic references?

Direct references are explicit, structural matches — a Flow element, a formula, or a Validation Rule that names the field. Heuristic references are source-text matches that require manual verification and are never counted toward review priority on their own.

Can Salesforce itself tell me what references a field?

Partially. Salesforce's own field-deletion flow blocks deletion when it detects certain references — typically in formulas, some validation rules, some automation, and layouts — but that check runs one field at a time, at the moment you attempt deletion, and does not produce a reviewable, exportable record you can share before you get that far.

What can field dependency analysis miss?

Heuristic-only matches that were not manually confirmed, automation or logic outside the evaluated categories, and anything outside Salesforce entirely — external integrations, middleware, BI tools, and exports that reference a field's API name without that reference appearing in Salesforce metadata.

Review Before Change

SEE WHAT REFERENCES A FIELD BEFORE YOU CHANGE IT.

Run a read-only Dependency Map review to see detected references across Apex, Flows, Workflow Rules, Validation Rules, and more before you change, repurpose, or retire a field.

Read-only · No package install · No Connected App setup · No Salesforce writes

Home/Resources/Salesforce Field Dependency Analysis

KeelCadence uses session cookies and Google Analytics 4 for site usage insights. GA4 does not receive Salesforce credentials, Org IDs, Report IDs, or payment data. You can opt out for this browser.