Impact Analysis

Impact Analysis answers the question every Salesforce admin asks before a change: "what breaks if I change or delete this field or object?" It returns a deterministic view of everything that depends on the component you are about to touch -- automations, validation rules, Apex, flows, and related objects -- so you can scope the change before you make it.

Impact Analysis lives in the Customer Portal and is powered by aprity's impact_of_change knowledge tool, built from your latest scan. There is no guessing and no vector search: the result is computed from the dependency relationships captured in your scan's structured index, with citations back to the source metadata.

What you get

For a selected field or object, Impact Analysis shows:

• Direct dependents -- the components that reference the selected field or object explicitly.
• Downstream impact -- components that depend on those dependents, so you can see the ripple effect of a change.
• Source traceability -- each item links back to the metadata it came from (Apex class, flow, validation rule, related object, …).

Because it is deterministic, the same selection always produces the same impact set for a given scan.

How it works

1. The aprity scan builds a dependency graph of your org as part of its structured index.
2. When you run Impact Analysis on a field or object, the portal calls the impact_of_change knowledge tool.
3. The tool walks the dependency graph and returns the set of components affected by changing or deleting the selected component.
4. The portal renders the result with links back to the source metadata.

The analysis reflects the last successful scan. If you have changed the org since the last scan, run a fresh scan first so the impact set is accurate.

Plan availability

Impact Analysis is available on the Intelligence and Trial plans. It is not included on Documentation.

Plan	Impact Analysis
Documentation	Not included
Trial	Included
Intelligence	Included

See Plan Comparison for the full feature matrix.

When to use it

• Before deactivating or deleting a field, to find every automation and rule that reads it.
• Before refactoring an object, to scope the blast radius of the change.
• During a code or config review, to confirm a change does not silently break a downstream process.
• When planning a migration, to understand how tightly coupled a component is to the rest of the org.

For deeper questions about a component's behaviour, the same dependency facts are available to the Help Agent, the Story Agent, and the Remote MCP Server.

For anything else, contact support@aprity.ai.