The Salesforce data model is the way your org's data is structured. Objects are the tables, fields are the columns and records are the rows. Salesforce ships standard objects such as Account, Contact, Lead and Opportunity; you add custom objects and fields for your own business, and connect them with relationships: lookup, master-detail, many-to-many through a junction object, and a few special types.
This guide was first published in 2020 as "Data Modelling In Salesforce". It has been rewritten for 2026 and now also covers object relationships in depth, the limits that shape a design, and how the Data 360 data model differs from the core one.
What is the data model in Salesforce?
Trailhead's Data Modeling module defines a data model as the way database tables are represented so people can understand them. In Salesforce terms:
- Standard objects come with Salesforce: Account, Contact, Lead, Opportunity, Case and many more.
- Custom objects hold information specific to your company or industry, for example a Property object for a real estate firm. Their API names end in
__c. - Fields on every object fall into four groups: an identity field (the record ID, 18 characters case-insensitive, with a 15-character case-sensitive version), system fields such as Created Date, a name field (text or auto-number), and custom fields you add, also ending in
__c. - Field types decide what a field holds: text, number, checkbox, date, picklist, formula, relationship and so on.
The core Salesforce data model
The core Salesforce data model is a handful of standard objects, led by Account, Contact, Lead, Opportunity and Case, that most Sales and Service Cloud orgs are built around:
| Object | Holds | Main links |
|---|---|---|
| Account | Companies (or people, with person accounts) | Parent of contacts, opportunities and cases |
| Contact | People who work at an account | Belongs to an account; linked to opportunities through contact roles |
| Lead | Prospects not yet qualified | Converts into an account, a contact and an opportunity |
| Opportunity | Potential deals | Belongs to an account; has products and contact roles |
| Case | Customer issues | Linked to an account and contact |
| User | People who log in | Owns records; hierarchical relationship for managers |
Lead conversion shows the model at work: as Trailhead explains, converting a lead uses its data to create a business account, a contact and an opportunity. Our guide to opportunities in Salesforce covers that object in detail.
What are the object relationships in Salesforce?
Salesforce has six relationship types: lookup, master-detail, many-to-many (through a junction object), hierarchical, external lookup and indirect lookup. Lookup and master-detail are the ones you will use most.
| Relationship | How it behaves | Use it when |
|---|---|---|
| Lookup | Loose link; each record stands alone with its own owner and sharing | Records are related only sometimes, e.g. a case's related asset |
| Master-detail | The detail depends on the master: it inherits sharing, is deleted with the master, and the master can have roll-up summaries | The child has no meaning without the parent, e.g. invoice lines on an invoice |
| Many-to-many | A junction object with two master-detail fields | Each record on both sides can link to many on the other, e.g. students and courses |
| Hierarchical | A special lookup available only on the User object | Management chains between users |
| External lookup | Links a standard, custom or external child to an external object parent, matched on the parent's External ID | The parent data lives outside Salesforce |
| Indirect lookup | Links an external child object to a standard or custom parent, matched on a unique custom External ID field | External records need to point at Salesforce records |
Trailhead's object relationships unit covers the first three behaviours, including the cascade delete: deleting a master deletes its detail records, and the master-detail field always sits on the detail object.
Relationship limits that shape your design
As of November 2026, a custom object can have at most two master-detail relationships and 40 relationships in total. Salesforce Help's Object Relationships Overview sets the limits: each custom object can have up to two master-detail relationships and up to 40 relationships in total, and each relationship field counts toward the object's custom field limit. For many-to-many designs, Help's page on creating a many-to-many relationship adds:
- The first master-detail field you create on the junction object becomes the primary relationship; the second becomes the secondary one.
- A junction object can't be the master in another master-detail relationship.
- Both masters can have roll-up summary fields over the junction records.
- A user can't delete a parent record that has more than 200 junction records if the junction object has a roll-up summary to the other parent.
How to design a Salesforce data model that scales
A scalable model reuses standard objects, picks relationships for how records must behave, and avoids putting too many records under one parent or owner.
- Start from standard objects. Account, Contact, Opportunity and Case come with reports, automation and AgentExchange (formerly AppExchange) support. Create a custom object only when no standard object fits.
- Choose relationships for behaviour, not convenience. Master-detail gives roll-ups and shared security but forces a parent on every record and deletes children with it. Use a lookup when the child must survive on its own.
- Avoid data skew. Trailhead's large data volumes module warns against more than 10,000 child records under one parent, such as a catch-all "Unassigned" account, or one user owning huge numbers of records. Both cause record locking and slow sharing recalculation.
- Keep only data you need. Use a data-tiering approach, and consider external objects for large data sets you only need part of at a time.
- Plan external IDs. Add unique External ID fields for records that come from other systems, so integrations and imports can match on them.
- Document it. Keep a diagram and a field dictionary; future admins will thank you.
How to view your data model with Schema Builder
Schema Builder is Salesforce's built-in tool for seeing and editing the model. Trailhead's Schema Builder unit describes the steps:
- In Setup, enter Schema Builder in Quick Find and open it.
- Clear the selection, tick the objects you want to see, and click Auto-Layout.
- Drag objects around to make the diagram readable; this doesn't change anything.
- Drag elements from the Elements tab to create objects and fields, including relationship fields.
Security, validation and data loading on top of the model
The data model decides what can be stored; three other layers decide who sees it, what is allowed in, and how it gets there.
- Security: object and field permissions come from profiles and permission sets, and record access from sharing. Master-detail children inherit the master's sharing, lookups do not. See what a profile is in Salesforce.
- Data quality: validation rules and formula fields enforce and derive values on each object. Our validation rules guide has examples.
- Loading data: load parents before children and match on External IDs. Our Data Loader guide walks through it.
The Data 360 data model is different
Data 360 uses its own layered model of data lake objects and data model objects, separate from the core CRM objects. Some page-one results for this search describe Salesforce's Data 360 (earlier called Data Cloud), which has its own layered model. Salesforce's Data 360 architecture guide describes data lake objects (DLOs) as the storage layer for ingested and federated data, and data model objects (DMOs) as the harmonised layer, built by mapping DLO fields to the standard Customer 360 Data Model to support unified profiles, segmentation and activation. DMOs are not the same as the CRM objects above, although CRM objects are a common source. Our Data Cloud services page covers that work.
Common data model mistakes
Most data model problems come from creating too much custom structure too early.
- Creating custom objects that duplicate standard ones, such as a custom "Customer" object next to Account.
- Using master-detail everywhere, then finding that records can't exist without a parent or are deleted by accident.
- Text fields where picklists or lookups belong, which ruins reporting. See our guide to creating reports in Salesforce.
- Automation built before the model is settled, so every change breaks a flow or a trigger.
Getting help
A data model is the hardest part of an org to change later. Techila is a Salesforce Summit Partner; our Salesforce implementation team designs and reviews data models before build starts. Talk to us about yours.
Frequently asked questions
What is the Salesforce data model?
It is the structure of your Salesforce data: objects act as database tables, fields as columns and records as rows. Relationships between objects, such as lookup and master-detail, connect records, for example contacts to their account.
What is the difference between lookup and master-detail relationships?
A lookup is a loose link: each record stands on its own and the lookup can usually be left blank. In a master-detail relationship the detail depends on the master, inherits its sharing, is deleted when the master is deleted, and supports roll-up summary fields on the master.
How do you create a many-to-many relationship in Salesforce?
Create a custom junction object with two master-detail relationship fields, one to each object you want to relate. Each junction record links one record of each object, and both masters can have roll-up summary fields over the junction.
How many master-detail relationships can an object have?
Salesforce Help says each custom object can have up to two master-detail relationships and up to 40 relationships in total, and each relationship field counts toward the object's custom field limit.
Where can I see my org's data model?
Use Schema Builder: in Setup, search for Schema Builder in Quick Find, select the objects you want and click Auto-Layout. It shows objects, fields and relationships, and you can create objects and fields from it.