Entity Relationship Diagram (ERD)
An Entity Relationship Diagram (ERD) is a graphical representation of a data model.
Definition
An Entity Relationship Diagram (ERD) is a graphical representation of a data model. It shows the entities in a system, the attributes those entities hold, and the relationships that connect them. In Salesforce an entity usually maps to an object, an attribute maps to a field, and a relationship maps to a lookup or master-detail link between two objects. An ERD is sometimes called a data model diagram, and it is the standard artifact architects use to picture how an org's data fits together.
Salesforce ships its own ERD tooling. Schema Builder is the built-in canvas that draws your objects and their relationships and lets you build new ones by dragging and dropping. Salesforce also publishes formal ERDs for its clouds and packaged products, using a documented notation with crow's-foot cardinality and diamond markers for master-detail. Architects sketch an ERD before they build, then keep it as a living reference as the schema changes.
How to read and use a Salesforce ERD
Entities, attributes, and relationships
An ERD has three building blocks. Entities are the things you store data about, drawn as boxes. Attributes are the properties of each entity, listed inside the box. Relationships are the named connections between entities, drawn as lines. In Salesforce the mapping is direct. Each box is an object, standard or custom. The lines inside are fields, and the lines between boxes are object relationships. Salesforce's published notation draws entities as boxes with rounded corners. Each box shows the object's label, its API name, and its fields. Key fields are marked with a hash symbol and non-key fields with a bullet. Reading an ERD well means looking at two things at once. First, what objects exist and what they hold. Second, how they join, and in which direction. A new team member can understand an org's structure faster from one good diagram than from clicking through Setup for an hour. That speed is why the artifact has lasted for decades across every database platform, not just Salesforce.
Cardinality and crow''s-foot notation
Cardinality describes how many records on one side of a relationship can match a record on the other side. ERDs encode this at the ends of each relationship line. Salesforce's data-model notation uses crow's-foot symbols. A crow's foot on one end means many occurrences on that end can relate to each occurrence on the opposite end. The absence of a crow's foot means at most one. So a single account with many contacts is drawn as a line with one plain end at Account and a crow's foot at Contact, which reads as one-to-many. One-to-one relationships have plain ends on both sides. Many-to-many relationships do not connect two boxes directly. They route through a third box, a junction object, with a crow's foot facing each parent. Getting cardinality right on paper matters because it drives real platform choices. It tells you whether you need a lookup, a master-detail, or a junction object before you create a single field, which saves rework later.
Showing lookup versus master-detail
Salesforce has two main object relationship types, and a good ERD makes the difference visible. A lookup relationship loosely links two objects. The child can stand alone, and deleting the parent does not delete the child by default. A master-detail relationship is tighter. The detail record cannot exist without its master, the master controls sharing and security, and deleting a master cascades to its details. In Salesforce's published notation a diamond on the singular side of a relationship marks the master role. A relationship line with that diamond is master-detail. A plain line with no diamond is a lookup. Some tools also vary line color or style to reinforce the distinction. This visual cue is not decoration. Anyone reviewing the diagram can see, at a glance, which deletes will cascade, which children inherit the parent's sharing, and where roll-up summary fields are even possible. Those behaviors flow from the relationship type, so showing the type clearly is one of the most useful things an ERD does.
Schema Builder, the built-in ERD
Schema Builder is Salesforce's native ERD tool. You reach it from Setup by entering Schema Builder in the Quick Find box. It opens a canvas that shows your objects and the relationships between them as a live graph. You drag objects from a side panel onto the canvas, and the platform draws the relationship lines for you. It displays field values, marks required fields, and shows both lookup and master-detail relationships on the same view. Schema Builder is not read-only. You can create custom objects, add fields, and define new relationships right on the canvas, and the platform implements those changes in the org. It also saves the layout of your diagram whenever you move an object, so the picture you arrange persists. The trade-off is polish. Schema Builder is built for fast, in-org visualization and light building, not for formatted documents you hand to auditors. Most architects use it for daily exploration and reach for a third-party tool when they need a shareable, styled deliverable.
Third-party ERD tools and the metadata behind them
Outside the platform, tools like Lucidchart, draw.io, ER/Studio, and Dataedo produce richer ERDs than Schema Builder. They offer better styling, change tracking, version history, and the ability to compare schemas across orgs. These tools read the org's live structure through Salesforce APIs rather than guessing. They commonly query the Tooling API, walking metadata such as EntityDefinition and EntityParticle, to learn which objects exist, which fields they have, and how they relate. From that metadata they render a diagram that matches production rather than someone's memory of it. The value is accuracy plus presentation. A generated ERD does not drift the moment a developer adds a field in a sandbox, because you can regenerate it from current metadata on demand. For formal documentation, regulated programs, or large orgs with hundreds of objects, that repeatability is worth the extra cost. The pattern most teams settle on is simple. Use Schema Builder to think and to build, and use a metadata-driven tool to publish the version of record.
ERDs as planning and living documentation
An ERD earns its keep at two moments in a project's life. The first is planning. Before anyone creates an object, an architect sketches the model: which entities exist, what each one holds, and how they connect. Reviewing that sketch with developers, admins, and business analysts surfaces design problems while they are still cheap to fix, well before they turn into built fields and migrated data. The second moment is documentation. A mature org keeps a living ERD that reflects the current schema and updates it as objects and fields change. It usually lives in a shared space such as Confluence, SharePoint, or a Git-backed site, and people reference it during onboarding, troubleshooting, and integration design. The honest caveat is upkeep. Stale ERDs are extremely common, and a diagram that no longer matches production can mislead more than it helps. The diagrams that stay valuable are the ones tied to a process. Teams that refresh the ERD as part of every release, or regenerate it from metadata, are the ones whose documentation can actually be trusted.
Worked example: a recruiting data model
Picture a recruiting app to see the notation in action. You have a Position object and a Candidate object. A single position can receive many candidates, and a single candidate can apply to many positions, so the relationship is many-to-many. On an ERD you would not draw a line straight between Position and Candidate. Instead you add a junction object, Job Application, and route the relationship through it. Job Application has two master-detail relationships, one to Position and one to Candidate. On the diagram each of those lines carries a diamond on the parent side, marking the master role, and a crow's foot on the Job Application side, showing that each parent can own many applications. Now add a Hiring Manager object linked to Position with a lookup. That line gets no diamond, because a position can reference a manager without being owned by one, and a manager record can exist on its own. In a few boxes and lines, the diagram captures every relationship type Salesforce offers and tells a builder exactly what to create.
Use Schema Builder to view and build your data model
Schema Builder is the fastest way to see your org as an ERD and to build on it. Here is how to open it, read the diagram, and use it to add to your model.
- Open Schema Builder
From Setup, type Schema Builder in the Quick Find box and select it. The canvas opens showing whichever objects were last on your layout.
- Add the objects you want to see
Use the Objects panel on the left to select objects, then click them onto the canvas. Drag boxes to arrange them. The platform draws the relationship lines automatically and saves the layout when you move a box.
- Read the relationships
Follow the lines between boxes. Schema Builder shows lookup and master-detail relationships, the fields on each object, and which fields are required, so you can confirm cardinality and relationship type at a glance.
- Build directly on the canvas
Switch to the Elements panel to drag a new object or field onto the diagram, or add a relationship field. The platform applies the change to your org, so treat it as real configuration, not a sketch.
Choose which objects appear and toggle showing or hiding relationships, field labels, and field types to reduce clutter on a busy canvas.
Drag new custom objects, fields, and lookup or master-detail relationships onto the canvas to build your model without leaving the diagram.
Schema Builder remembers where you place each object, so your arrangement persists between sessions for the objects on your view.
- Schema Builder edits are live. Adding or deleting an object or field on the canvas changes your org immediately, so use a sandbox when experimenting.
- A canvas with hundreds of objects becomes unreadable. Show only the domain you care about rather than the whole org at once.
- Schema Builder is for in-org visualization and light building. For polished, shareable documentation, export to or generate from a third-party tool instead.
Trust & references
Cross-checked against the following references.
- Salesforce Data Model NotationSalesforce
- Design Your Own Data Model With Schema BuilderSalesforce
Straight from the source - Salesforce's reference material on Entity Relationship Diagram (ERD).
- Object Relationships OverviewSalesforce
- Create a Many-to-Many Object RelationshipSalesforce
Hands-on resources to go deeper on Entity Relationship Diagram (ERD).
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What does an ERD show?
Q2. What's Salesforce's built-in ERD tool?
Q3. Why maintain an ERD?
Discussion
Loading discussion…