Pick a Salesforce standard object. See exactly what cascade-deletes with it, what just gets orphaned, and why — before you find out the hard way.
Checking latest Salesforce API version…
Pick a record type
You're modelling: "If I delete one record of this type, what happens to everything connected to it?"
1 = only direct relationships. Higher values follow cascade chains further (e.g. Account → Opportunity → Quote → Quote Line Item is 3 deep). Most real cascades are shallow, so this mainly matters for long chains.
Before you rely on this: things this tool can't know
This models well-documented default platform behaviour. Real orgs add their own rules on top — always check these yourself before deleting for real:
Custom automation — Apex triggers, Flows, and Validation Rules on delete/before-delete are entirely org-specific. Check Setup → Object Manager → [Object] → Triggers, and Setup → Flows (filter by object).
Restore behaviour — undeleting a record from the Recycle Bin does not reliably restore everything that cascade-deleted with it. Always verify child records after any restore.
API version drift — the relationships modelled here reflect long-stable, current platform behaviour. Very old orgs on deprecated API versions should double-check anything unusual against Salesforce's release notes for their version.
Industry Cloud objects (Health Cloud, Financial Services Cloud, Order Management, etc.) — these only exist if that specific cloud is licensed in your org, and several have both a legacy managed-package version (custom objects, e.g. FinServ__FinancialAccount__c) and a newer standard-object version (e.g. FinancialAccount) depending on your org's edition and migration history. Object names below are verified against Salesforce's own official documentation, but relationship behaviour is deliberately not modelled for these — confidence here is genuinely lower than for core Sales/Service objects, and importing your own org's describe() data is the right way to get a real answer.
Objects added from Salesforce's full 6,342-page official object reference (a large batch spanning Sales, Service, Product Catalogue, Order Management, Workforce Engagement, and Partner & Channel) — object names and relationship existence are directly sourced from that document, but it turns out to consistently label every reference field's "Relationship Type" as "Lookup," even for fields I independently know cascade-delete in practice (e.g. CaseComment, OpportunityLineItem). So relationships in this batch default to Lookup rather than an unverifiable guess at cascade behaviour — treat these as "this relates to that," not a confirmed deletion outcome, and import your own org's data for anything that actually matters for a real decision.
Advanced: import your own org's real schema (no login form, no credentials, no third party)
Salesforce's own describe() data for any object already includes exactly the flags this tool needs (cascadeDelete, restrictedDelete). The safest way to get it: use your own already-logged-in sandbox session — nothing is typed anywhere, no separate login, no third-party tool involved.
Simplest, one object at a time — while logged into your sandbox, open a new tab and go directly to: https://YOUR-INSTANCE.my.salesforce.com/services/data/v61.0/sobjects/Account/describe/
(swap in your instance and the object you want). Your browser's existing session shows you the JSON directly — select all, copy, paste below.
For several objects at once, or your whole org — use Salesforce's own Developer Console (Setup gear icon → Developer Console), not your browser's. Open Debug → Open Execute Anonymous Window, paste the Apex below, and click Execute:
Worth knowing before you run this: a real org can have thousands of standard objects, and Apex debug logs have a size limit. This script outputs a simple line-per-relationship format rather than JSON specifically because of that — if the log does get cut off, you only lose the last incomplete line, not the whole payload (JSON needs to be structurally complete to parse at all, so any truncation breaks everything). It still defaults to custom objects only — the part your org's schema this tool genuinely can't know about otherwise, since standard objects are already covered by the built-in model. Flip includeStandardObjects to true only if you're confident the total will fit in one log.
If you do need standard objects included too and hit truncation, the practical workaround is running this in batches — e.g. add a name filter like if (!d.getName().startsWith('A')) continue; temporarily, one letter range at a time, rather than everything in one log.
Then in the log panel at the bottom, tick "Debug Only" to cut the noise, and copy every line starting with SCHEMA| (the trailing DONE line confirms how many objects came through, and whether it matches what you expected). Paste those lines below exactly as they appear — one relationship per line means a truncated log just loses its last line, not the whole thing.
Only ever run this against a sandbox, never production.
Exported the whole log as a file instead (Developer Console → File → Download Log)? Drop the raw .log file below directly — no need to copy/paste anything.
📁 Drag a .log, .txt, or .json file here, or click to browse