Impact analysis is great for showing you where something is used. But sometimes, that’s not the full story. A field might be used in an Apex class, but that class might also be referenced in a Visualforce page, which is then tied to a button, and finally ends up on a layout.
That’s where Recursive Impact Analysis comes in.
How it works
When you run an impact analysis, some components in the dependency tree will have a small graph icon next to their name.
That icon means you can go deeper. Click it, and HappySoup will show you not just where the field (or component) is used, but also where that usage is used.
And the best part: the hierarchy stays in place. You can keep drilling down step by step.
Example chain:
Field > used in > Apex Class > used in > Visualforce Page > used in > Custom Button > used in > Layout
In this example, a simple field change could ultimately ripple all the way to a page layout.
Recursive impact analysis takes your org analysis to the next level:
Spot indirect risks – See the full chain of dependencies, not just the first layer.
Understand coupling – If two components are linked through a chain, changes in one could affect the other.
Avoid surprises – What looks like a small change might have big consequences.
Real-world example
Let’s say you’re thinking about deleting or modifying the CustomerPriority__c field.
At first glance, you see it’s used in an Apex class. No big deal, right? But with recursive impact analysis, you drill deeper:
That class is referenced in a Visualforce page.
The page is tied to a custom button.
The button appears on the Account layout.
Suddenly, it’s clear: changing the field could indirectly break a button on the layout, which directly impacts your users. Without recursive analysis, this risk would have been completely hidden.
Recursive impact analysis is subject to the same limitations of standard impact analysis.