Impact analysis
See what breaks before you change or delete a Salesforce field.
Impact analysis answers one question before you touch your schema: what breaks if I change this field? It maps the blast radius — the validation rules, page layouts, lookups, and automations that depend on a field — so you can make the call with the full picture instead of finding out after you ship.
Here's the blast radius for a single field at a glance:
Built from metadata
Impact analysis works from your org's structure — rules, layouts, relationships, and Salesforce's dependency graph. It never reads, stores, or shows record data.
Where to find it
Impact analysis shows up in three places:
An Impact section on every field's page, with a verdict and the references behind it.
An Impact tab on every object, summarizing incoming references and automation.
Ask "what breaks if I change Region__c" or "is this field safe to remove" in plain English.
What's analyzed on a field
The Impact section on the field detail page pulls together everything that depends on the field:
- Same-object validation rules — rules whose formula references the field.
- Cross-object validation rules — rules on other objects that reach this field through a parent relationship.
- Page layouts — the layouts that expose the field.
- Lookups the field powers — the relationship edges that depend on it.
- Automations — Flows, Apex classes, Apex triggers, and Workflow Rules that reference the field, drawn from Salesforce's
MetadataComponentDependency.
The verdict
From those references, the field's Impact section shows one of three verdicts:
| Verdict | Means | Example |
|---|---|---|
| Depends | The field is referenced — review before changing it. | "Referenced by 4 validation rules, 3 page layouts, 2 automations, and powers 5 lookups — review before changing or deleting." |
| Safe | Nothing references the field, and layout coverage was complete. | "No rules, layouts, automations, or lookups reference this field — likely safe to retire." |
| Unknown | No references found, but page-layout coverage was incomplete. | "Verify before removing." |
Why "safe" is conservative
The green safe verdict only appears when SchemaForce captured complete page-layout coverage for the object. If coverage was partial, the verdict is unknown instead — SchemaForce would rather tell you to verify than claim a field is safe to retire when it can't see every layout.
On an object
The Impact tab on an object's detail page summarizes the blast radius for the whole object:
- A verdict — for example, "Changing or deleting
Accountaffects 12 incoming references and 4 automations." - Counts of fields, validation rules, layouts, and record types.
- A Referenced by list of objects that look up to this one.
- An Automation on this object list — Flows and Apex triggers, marked active or inactive.
Honesty about the limits
Impact analysis is precise about what it can and can't see. Keep these in mind:
What impact analysis does not do
- Automation linkage is dependency-graph level, at object granularity. SchemaForce does not parse Flow or Apex internals to confirm exactly how a field is used inside them.
- Automation dependencies are covered for custom fields only.
- A safe to retire verdict is asserted only when page-layout coverage is complete — otherwise you'll see unknown, meaning "verify before removing."
Plan
Impact analysis is part of the core dictionary — it's not gated by plan.