Every Salesforce org, before anyone customizes it, starts from the same standard data model — the same core objects, related to each other the same ways. Learn this spine once and you can walk into any org and orient yourself fast, because the custom objects and lookups a team adds are all layered on top of it. Here's the shape of it. (For the relationship table with the exact fields and types, there's a downloadable reference; for building a diagram of it, see how to create a Salesforce ERD.)
Account is the hub
Most of the standard model hangs off Account — the company or organization you do business with.
- Contact relates to Account through
Contact.AccountId(a lookup) — a person at that company. - Opportunity relates to Account through
Opportunity.AccountId— a deal with that company. - Case relates to Account through
Case.AccountId(and to a person throughCase.ContactId) — a support issue for that customer. - Account relates to itself through
Account.ParentId, which builds the account hierarchy — subsidiaries under a parent company.
If you picture Account in the middle with Contacts, Opportunities, and Cases hanging off it, you've got most of the standard model in one image.
Opportunities, line items, and products
An Opportunity doesn't just carry an amount — when you use products, it owns a set of line items:
- OpportunityLineItem is a detail of the Opportunity (it can't exist without its parent).
- Each line item connects, through a PricebookEntry, to a Product and a Price Book — which is how a deal knows the price of what's being sold.
This little cluster is where a lot of orgs' revenue detail actually lives, and it's easy to miss if you only look at the Opportunity's own fields.
Many-to-many: the junction objects
Some relationships aren't one-to-many — a contact can be on many opportunities, a campaign has many members. Salesforce models these with junction objects, records that sit between two others:
- OpportunityContactRole links Opportunities and Contacts (with a role like Decision Maker).
- CampaignMember links Campaigns to Leads and Contacts.
- AccountContactRelation links Contacts to multiple Accounts (the Contacts to Multiple Accounts feature).
When you're hunting for "how are these two objects related" and there's no direct lookup, a junction object is usually the answer.
Leads sit apart — until conversion
A Lead is deliberately not wired into the Account/Contact/Opportunity web. It stands alone while it's being qualified. When it's converted, it doesn't link to those objects — it creates them (an Account, a Contact, and optionally an Opportunity), and records the results in its ConvertedAccountId, ConvertedContactId, and ConvertedOpportunityId fields. So "how does Lead relate to Account" has an unusual answer: through conversion, not a live relationship.
Ownership ties it together
Nearly every object has an OwnerId — a lookup to the User who owns the record (and on Leads and Cases, the owner can be a Queue instead of a person). Ownership drives sharing and a lot of reporting, so it's part of the model even though it's easy to overlook.
The honest catch — the standard model is the easy part
This spine is identical in every org, which is exactly why it's the part you don't need help with. What you actually need to see is everything your org built on top: the custom objects three admins added, the lookups wiring them into the standard model, the junction objects modeling your particular many-to-many cases. None of that is in a generic diagram — it only exists in your org.
That's the boundary. This explains the standard model; seeing your model — standard and custom, current — is a different job, and drawing it by hand means it's stale the moment someone adds an object. SchemaForce's relationship map reads your org and lays out how every object actually connects, standard and custom, as a live map — so the parts that are unique to you are as legible as the standard spine everyone shares.
