Beta Eight scan engines Free and open source
SF Dependency Checker
Find every place a field is used before you delete it — and know when the answer is incomplete.
Runs entirely inside your org. Metadata is read through a Named Credential pointed at your own org — nothing is sent to CronCoders or any third party.
View source on GitHub Book a setup call
The problem
Salesforce's own Where Is This Used? under-reports, and it never tells you what it missed. So the field gets deleted, the deploy goes green, and a Flow breaks in production two days later.
The usual response is to stop deleting anything. The org fills up with fields nobody dares touch, and every release carries risk that nobody can size.
Who it is for
Salesforce admins, architects and consultants doing org cleanup, technical debt reduction or pre-release impact analysis — especially in orgs carrying years of Flows, Apex, formulas and reports.
A full dependency scan on a custom field, from target selection to CSV export.
What it looks like in the org
What it does
Pick a target
Any object, or one specific field on it.
- Type-ahead filtering on both the object list and the field list
- Scan a single field, or choose "Entire object" to scan the object as a whole
- Warns before the scan starts if the target cannot be fully covered
Eight scan engines in one pass
The Dependency API on its own is not enough, so it is only one of eight.
- Dependency API — broad org-wide references for custom fields and objects
- Flow — field references inside Flow metadata, down to the element they sit in
- Validation Rule — fields used in validation rule formulas
- Formula Field — fields used in other formulas and default values, including cross-object references through relationships
- Apex — field references in classes and triggers
- Report — columns, groupings and filters
- Layout — page layouts that display the field
- List View — list views using the field as a column or a filter
Tells you what would actually break
Not every reference is a problem. The ones that are get marked BREAKS.
- Blockers include Flows, Apex, triggers, validation rules, formula fields, lookup filters, field sets, quick actions, workflow rules and sharing rules
- Page layouts are deliberately not blockers — Salesforce drops deleted fields from layouts silently, and layouts outnumber real problems roughly twenty to one
- One toggle hides everything except references that would break
Honest about what it could not see
The difference between "found nothing" and "could not look" is the whole point.
- Proven references are shown as found; uncertain matches are labelled (likely), so a guess is never presented as a fact
- A coverage note after each scan lists exactly which scanners were skipped and why
- Standard fields have no Dependency API identity — you are told that before the scan, not after
- Results that hit the platform's 2,000-row cap are flagged as incomplete
- An empty result reads "No references found — but coverage was incomplete", never a false all-clear
Work with the results
Every hit carries enough context to act on without opening Setup.
- Component type, component name, how it is used (formula, SOQL, condition, layout item, column, field reference) and the location inside the component
- The actual line of code or formula clause that references the target
- Which engine found it, and at what confidence
- Totals, break count and per-component-type badges (Layout: 251, ApexClass: 14, Flow: 6)
- Sort by component type or name, and export the full result set to CSV named after the scanned target
Built to survive a real org
Long scans fail loudly instead of hanging.
- Every scan is stored with its target, status, counts, coverage flags, scanners run and skipped, error detail and timings
- A dedicated history tab for reviewing past checks and tracking an object over time
- A job killed by a platform limit reports Failed with a readable reason rather than spinning forever
- Custom metadata settings for Named Credential name, API version, max rows per query, max callouts per chunk and cache TTL, with safe fallbacks
- Guided uninstall wizard for clean removal
- Runs cleanly in Developer Edition and Trial orgs
Install it
Typical setup time: About 10 minutes for the package, plus 15 for the guided connection wizard.
Before you start
- My Domain enabled on the org
- System Administrator access to create an External Client App and Named Credential
- API access enabled for the running user
- Developer, Enterprise, Unlimited or Trial edition
Get the package
Install in a sandbox Install in production Deploy from source
Install in a sandbox first. Promote to production once you have tested it there.
After installing
- Assign the packaged permission set to yourself
- Run the guided setup wizard from the app's Setup tab
- Create the External Client App, External Credential and Named Credential — the wizard shows your org's exact My Domain URL, token endpoint and credential name, each with copy-to-clipboard
- Assign the credential permission set
- Run the live connection test, which verifies the connection with a real query rather than assuming it works
What it touches
- Data
- Runs entirely inside your org. Metadata is read through a Named Credential pointed at your own org — nothing is sent to CronCoders or any third party.
- Editions
- Developer, Trial, Enterprise, Unlimited
- License
- MIT
- Distribution
- Unlocked Package
This tool asks you to create an External Client App and a Named Credential, which is the part that looks alarming. Here is exactly what that is for.
- The Named Credential points at your own org. It is how the package calls the Salesforce Metadata, Tooling and Dependency APIs from Apex, which cannot be done without one.
- Object and field names are validated against your org's real schema before they are used in a query, so a crafted input cannot become SOQL injection.
- Access is controlled by the packaged permission set. Assign it to the admins who need it, not broadly.
- The guided uninstall wizard removes the permission set assignments, the package and the credential permission set in the right order, so nothing is left behind.
Questions people ask before installing
How is this different from Salesforce's own Where Is This Used?
Where Is This Used? relies on the Dependency API alone, misses several reference types, and gives you no signal when it has missed something. This runs the Dependency API as one of eight engines, parses the metadata directly for the rest, and tells you explicitly which scanners were skipped and why.
Does any of my org data leave Salesforce?
No. The Named Credential points back at your own org. The tool reads metadata and stores scan history as records inside your org. Nothing is transmitted to CronCoders or any third party.
Why does it need an External Client App and a Named Credential?
Apex cannot call the Salesforce Metadata, Tooling and Dependency APIs without an authenticated connection, even back to its own org. The guided wizard walks the five steps and finishes with a live connection test that runs a real query rather than assuming success.
It is not on the AppExchange. Is that a problem?
It means the package has not been through the Salesforce security review, so you should review the source before installing — which is why the source is public. Install it in a sandbox first and test it there.
Can I trust a result that says nothing was found?
Only when the coverage note says coverage was complete. If any scanner was skipped or a query hit the 2,000-row cap, the summary says so instead of giving you an all-clear.
How do I remove it cleanly?
The guided uninstall wizard unassigns the packaged permission set, uninstalls the package, then deletes the credential permission set, in that order.
Want it running without doing it yourself?
The software is free. Paid installation, configuration and support are available.