What Breaks If I Change This Field? Mapping Salesforce Dependencies in a Graph Database

Salesforce orgs that have been in use for years accumulate fields, flows, Apex classes and reports that depend on one another in ways nobody fully remembers. Before deprecating a field or splitting a package, a team needs to answer one question with confidence: what breaks if I change this? We built a toolkit that extracts metadata dependencies from large, long-lived orgs and loads them into a graph database so that question has a reliable answer.

Why the question is hard

In a mature org, a single field can be referenced by formula fields, validation rules, flows, Apex code, reports and more. Some of those references are direct. Others run through a chain: a formula uses a field, a flow uses the formula, a report uses the flow's output.

Searching the codebase finds some of this. It misses anything that lives in declarative configuration rather than code, which in Salesforce is a large share of the business logic.

Extract the dependencies automatically

The toolkit uses the Salesforce Metadata API to retrieve an org's metadata and extracts dependencies across fields, flows, Apex and reports. Doing it automatically matters: a manual audit of a large org is slow, and it is out of date as soon as someone changes something.

The toolkit is built with Node.js and Python.

Why a graph database

Dependencies are relationships, and relationships chain. "What depends on this field, and what depends on those things?" is a question about paths through a network, which is what graph databases are designed for. The toolkit loads the dependencies into Neo4j, where they can be visualised and queried.

In a relational database, following dependencies several levels deep means increasingly complex joins. In a graph, it is a path query. That makes the questions teams actually ask practical:

• Everything that depends, directly or indirectly, on a given field.
• Which automations touch a field before a report reads it.
• Which parts of the org are tightly connected, and therefore risky to split into separate packages.

Trace consumption, not just references

The toolkit traces field consumption across formulas and automations. Knowing that a field is referenced somewhere is only a start. Knowing how it is consumed, through which formulas and which automations, is what lets a team plan a change safely.

Test against real orgs

A dependency tool that works on a tidy demo org proves very little. Long-lived orgs contain unusual configurations, legacy components and naming that no sandbox reproduces. This toolkit was validated against genuine production-scale orgs, which is the only way to trust its answers on the orgs that need it most.

Where this helps

For engineering teams, the practical value is planning:

• Field deprecations, knowing every consumer before removing a field.
• Package splits, understanding which components depend on each other.
• Large refactors, sequencing changes so dependencies are handled in order.

A checklist before changing a mature Salesforce org

• Inventory dependencies automatically; do not rely on memory or code search alone.
• Include declarative configuration: formulas, flows and reports.
• Follow dependency chains more than one level deep.
• Test your tooling against a real production-scale org.
• Re-run the analysis before each major change, because orgs keep changing.

The anonymised write-up is in our work library. For another way we keep large Salesforce configurations under control, see keeping thousands of CRM configuration items consistent. This kind of work falls under our product improvement service.