Here's the thing you came for: the honest rundown of how to make a Salesforce ERD, plus a free reference of how the core standard objects relate to each other. An entity relationship diagram maps your org's objects and the relationships between them — the Account → Contact → Opportunity web, and every custom object and lookup you've layered on top. It's how you understand an org at a glance, onboard someone, or design a change without missing a dependency.
There are three real ways to build one, and they trade off the same way every documentation choice does: effort now versus staying true later.
Option 1 — Schema Builder (built into Salesforce)
Setup → Schema Builder gives you a canvas: drag objects on, and it draws the fields and the relationship lines between them. It's live against your metadata, and you can even create objects and fields from it.
Where it stops: it bogs down fast. Past a few dozen objects the canvas becomes a hairball you spend more time arranging than reading, there's no way to show only the relationships you care about, it carries no field descriptions, and you can't export or share it as documentation. It's a fine way to look at a slice of the model interactively; it's not a way to produce something you hand to a stakeholder.
Option 2 — A drawing tool (Lucidchart, draw.io, diagrams.net)
Draw the boxes and lines yourself, or use one of the Salesforce-import connectors some of these tools offer. You get a clean, shareable, presentation-ready diagram — laid out exactly how you want it.
Where it stops: the moment you finish, it starts drifting. Someone adds a custom object, a new lookup, a junction — and none of that updates your diagram. A hand-drawn ERD is a photograph of the schema on the day you drew it, which for a living org is usually a few weeks before it stops being trustworthy. Great for a fixed design discussion; a maintenance trap as living documentation.
Option 3 — The metadata / describe API
For developers: query the describe endpoints (or the Metadata API) and generate the relationship graph programmatically. It's exact and scriptable, and it's how tools build ERDs under the hood — but it's code, not something most admins will run, and you still have to render and maintain the output.
The core standard model (so you're not starting from zero)
Before your customizations, every org shares the same spine. The free reference above has the full table; the shape of it:
- Account is the hub — Contact (
Contact.AccountId), Opportunity (Opportunity.AccountId), and Case (Case.AccountId) all relate to it, and Account even relates to itself (Account.ParentId) to form the account hierarchy. - Opportunity owns its line items — OpportunityLineItem is a detail of Opportunity, and each line connects through a pricebook entry to a Product.
- Junctions handle the many-to-many cases: OpportunityContactRole links opportunities and contacts, CampaignMember links campaigns to leads and contacts, and AccountContactRelation powers Contacts to Multiple Accounts.
- Lead stands apart until conversion, when it creates an Account, Contact, and Opportunity rather than relating to them.
That standard spine is identical everywhere. What you actually need a diagram for is everything you added on top of it.
The honest catch — the value isn't the drawing, it's staying true
Every option above can produce an ERD. The one that lasts is the one that doesn't depend on a human keeping it current — because a data model diagram's entire job is to be accurate, and an inaccurate one is worse than none, since people trust it right up until it burns them. Schema Builder is live but unshareable; a drawing is shareable but instantly stale; the API is exact but it's a coding project.
That's the boundary, and it's a specific one: generating the relationship graph from your org's metadata — and keeping it current as the schema changes — is exactly the part that can be automated, while deciding what a particular diagram should emphasize for a particular conversation stays a human's call. SchemaForce's relationship map is the automated half: it reads your org and lays out how every object connects — standard and custom — as a live map you explore, so "what relates to what" is current by construction instead of accurate-as-of-the-last-time-someone-redrew-it. You keep the judgment; what you stop doing is the redrawing.
Start here
If you need an ERD right now for a design session, Schema Builder or a drawing tool is the fast path — just date it and know it's a snapshot. If what you actually want is a data model you can trust every time you look, that's the case for generating it from the org. (Documenting the fields on those objects, not just the relationships, is the companion job — the standard fields reference covers that side.)
