Episode Two Of The Open Source MVP Series
Second episode of the Open Source MVP series, and today we’ve got Pablo Gonzalez, creator of Happy Soup.
I’ll be upfront: this is my personal favourite open source Salesforce application, and it’s genuinely impressive. Pablo came on to talk through the technical side of how it works, why he built it, and why he kept it open source instead of packaging it up and selling it like so many people do.
It’s a long one and there’s a lot in it, including a proper dive into the Dependency API, which is worth understanding whether or not you ever use the app.
The Question It Answers
Every Salesforce developer has been here. You want to delete a field. Or change one. Or you’ve inherited an org and you need to know what a class actually touches before you go near it.
So you ask the obvious question: what depends on this?
And Salesforce’s answer is… not great. The “Where is this used?” button exists and it’s shallow. It tells you the immediate references and stops. It won’t tell you that the field is used by a formula field, which feeds a report, which is on a dashboard the CFO looks at every Monday.
Happy Soup answers the question properly, in both directions.
Both Directions Matter
Dependencies: what does this thing rely on? Everything below it. Useful when you’re trying to understand a piece of metadata, or working out what you’d need to migrate alongside it.
Usage: what relies on this thing? Everything above it. This is the “can I safely delete this?” question, and it’s the one that saves you from an incident.
Crucially, Happy Soup traverses these recursively. Not one level, the whole tree. That’s the difference between “this field is used in one Apex class” and “this field is used in an Apex class, which is called by a trigger, which fires on a process that feeds three reports.”
How It Works Underneath
This was the most interesting part of the conversation for me.
Happy Soup is built on the MetadataComponentDependency object in the Tooling API. That’s the same data source powering the native “Where is this used?” button, so the raw information has been available all along.
What Happy Soup adds is the part that makes it useful:
Recursive traversal. Following the chain properly rather than stopping at one level.
Gap filling. The Dependency API genuinely doesn’t cover everything, so Pablo supplements it with additional queries and metadata parsing for the things it misses.
A usable interface. Results you can actually read, filter and export.
It’s a good lesson in general, honestly. The valuable thing wasn’t access to the data, it was doing the unglamorous work of making the data usable.
Where It Earns Its Keep
Technical debt cleanup. Every mature org has fields and classes nobody has used in years. This tells you which ones are genuinely safe to remove, rather than you guessing and finding out on a Monday morning.
Impact analysis. Before changing a field, see everything that would be affected. This is the one that stops incidents.
Inheriting an org. Along with a data dictionary, this is the fastest way to build a mental model of an unfamiliar org. The dictionary tells you what exists; Happy Soup tells you how it’s wired together.
Building deployment packages. Work out what you need to bring along when moving a component between orgs.
Untangling a monolith. If you’re trying to break a large org into packages, dependency mapping is step one and doing it by hand is not realistic.
The Honest Limitations
Pablo was refreshingly straight about these, which I appreciated.
The Dependency API has gaps. It’s a Salesforce limitation, not a Happy Soup one. Some metadata types simply aren’t tracked properly, so a clean result doesn’t guarantee something is unused.
Dynamic references are invisible. If you build a field name as a string in dynamic SOQL, nothing can detect that. No static analysis tool can, in any language. It’s a genuine argument against dynamic SOQL, incidentally.
Large orgs take a while. Lots of API calls. Be patient.
So treat it as an extremely good first pass rather than gospel. Always sanity check before deleting anything irreversible.
Go Use It
You can run it as a hosted web app or deploy it yourself, and there’s a CLI plugin too if you’d rather script it. Details are all in the repo.
Huge thanks to Pablo for building this and for keeping it free. Go star the repo, and if you find a gap, raise an issue.
Tools like this make everybody’s orgs better, and they only keep existing if people use them and contribute back.
Get Coding With The Force Merch!!
We now have a redbubble store setup so you can buy cool Coding With The Force merchandise! Please check it out! Every purchase goes to supporting the blog and YouTube channel.
Get Shirts Here!
Get Cups, Artwork, Coffee Cups, Bags, Masks and more here!
Check Out More Coding With The Force Stuff!
If you liked this post make sure to follow us on all our social media outlets to stay as up to date as possible with everything!
Youtube
Patreon
Github
Facebook
Twitter
Instagram
Salesforce Development Books I Recommend
Advanced Apex Programming
Salesforce Lightning Platform Enterprise Architecture
Mastering Salesforce DevOps
Good Non-SF Specific Development Books:
Clean Code
Clean Architecture
