Skip to content
SteveTechArcSteveTechArc Courses

The Standard Data Models

Also in 28 languages

Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

An aisle of a builders' supply warehouse, its racks stacked with ready-made standard doors, windows and stair parts, a cart waiting in the aisle.
Image generated with AI

Module 2 of 10 in the chapter Salesforce Data Architecture, chapter 3 of the Data Architect course. Each module stands on its own. Previous: The Salesforce Data Platform: More Than a Database · Next: Build Your Own: Custom Objects

The question this module answers: What has Salesforce already modeled for you, and how is it put together?

In module 1 I told you to look to the mothership: before you invent something, look at how Salesforce itself does it. This module is where we actually look. Salesforce has already modeled a lot of business for you, in its standard objects, and two of those models do most of the work in most of the orgs I walk into: the Sales model and the Service model. Before you can decide whether something deserves a custom object, you need to know what’s already there. That’s the next two modules.

What Makes an Object Standard

Section titled “What Makes an Object Standard”

A standard object comes out of the box. Salesforce built it, it has a defined purpose, and it comes with its own fields and relationships. You can add fields to it, build automation around it and change its layouts, but you can’t redesign it: the standard fields and relationships are Salesforce’s.

Look at the names. Account, Contact, Case. No prefix, no suffix. That’s Salesforce keeping that space for itself. Everything we build ends in __c, so Salesforce can add new standard objects at any time without ever colliding with anything in your org. And it does, every release.

Somewhere along the way somebody built a product object that didn’t work out and had to be left behind. That’s why the API name is Product2. It’s my first litmus test when someone tells me they know Salesforce.

The Sales Model

Section titled “The Sales Model”

Start on the left, with the Lead: someone who might become a customer. A lead isn’t really part of the model yet. It’s a holding area. When you convert it, Salesforce creates the real records: an Account, a Contact, and, if there’s a deal, an Opportunity. That’s why I draw the Lead off to the side.

The Account is the company. Its Contacts are the people at it. An Opportunity is a deal with that account. So far, nothing you didn’t expect.

Then it gets interesting. What’s in the deal? Each line is an Opportunity Product, and an Opportunity Product doesn’t point straight at a Product. It points at a Price Book Entry: this product, at this price, in this price book. The Price Book Entry sits between the Product and the Price Book, so the same product can have one price in the standard price book and another in your partner price book.

That’s two relationships that became things, one after the other. Remember the Delivery Item from chapter 2, between the Delivery and the Product, and the Dog Trick between the Dog and the Trick? Salesforce did exactly the same thing here, twice: the Opportunity Product between the Opportunity and the Price Book Entry, and the Price Book Entry between the Product and the Price Book. When you can read that, you can read most of the standard data model.

The Sales model The Sales model. A Lead, off to the left, converts into an Account. An Account has Contacts and Opportunities. An Opportunity uses a Price Book and contains Opportunity Products. Each Opportunity Product is priced by one Price Book Entry. A Price Book lists Price Book Entries, and a Product appears in Price Book Entries, so each Price Book Entry joins one Product and one Price Book. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.28.0", "built": "2026-10-15", "id": "DGM-DA-PD-21", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "object-model/conceptual 1.8.0", "theme": "stevetecharc 1.4.0"} converts into has has uses contains is priced by lists appears in Lead Account Contact Opportunity Price Book Opportunity Product Price Book Entry Product exactly one zero or one one or many zero or many © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Here’s that chain up close, with the fields that hold it together:

The pricing chain up close The pricing chain as a detailed data model. An Opportunity Product carries its Opportunity ID, its Price Book Entry ID, a quantity and a sales price, and is priced by one Price Book Entry. The Price Book Entry carries its Price Book ID, its Product ID, a list price and a Use Standard Price flag. A Price Book has a name and an Is Standard flag; a Product has a name and a product code. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.28.0", "built": "2026-10-15", "id": "DGM-DA-PD-23", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "object-model/logical 1.8.0", "theme": "stevetecharc 1.4.0"} is priced by lists appears in Price Book Price Book ID RECORD ID Name Is Standard Opportunity Product Opportunity Product ID RECORD ID Opportunity ID Price Book Entry ID Quantity Sales Price Price Book Entry Price Book Entry ID RECORD ID Price Book ID Product ID List Price Use Standard Price Product Product ID RECORD ID Name Product Code exactly one zero or one one or many zero or many © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

One rule people trip over: there’s a standard price book, and a Price Book Entry in any other price book can simply use the product’s standard price. Know which price book an opportunity uses before you load its products.

The Service Model

Section titled “The Service Model”

Now the other side of the house. Same Account, same Contacts. When something goes wrong, the customer opens a Case.

The case is usually about something the customer has, and Salesforce has an object for that: the Asset. In module 5 I’ll call it the standard object people overlook. It’s a thing the customer has, whether they bought it from you or not.

And what is the customer entitled to? That’s the Entitlement: the support an account is eligible to receive, often tied to an asset, a product or a service contract. Put an entitlement on a case, and now the case knows what level of support it’s supposed to get.

The Service model The Service model. An Account has Contacts, Cases and Assets. A Contact reports Cases. A Case can be about one Asset, and an Entitlement, which belongs to an Account, covers Cases. A line from the Case back to itself, around its corner, is the Parent Case: a case is the parent of zero or many cases, and each case has zero or one parent. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.28.0", "built": "2026-10-15", "id": "DGM-DA-PD-22", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "object-model/conceptual 1.8.0", "theme": "stevetecharc 1.4.0"} has has reports owns is about covers parent of Account Contact Asset Case Entitlement exactly one zero or one one or many zero or many © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Look at the line that runs from the Case back to itself. Every case has a Parent Case field, and it points at another case. That’s a self-lookup: a relationship from an object to itself. It confuses a lot of people the first time they see it, so here are the two reasons I use it.

One: a big issue that breaks into smaller ones. The customer reports that the whole installation is down. We open sub-cases for the network, the hardware and the configuration, each worked on its own, and they all resolve upward: the parent case isn’t done until they are.

Two: history. A case was closed last month, and now the same problem is back. The new case points back at the original, so anyone who opens it can see this has happened before, and what was done about it.

We’ll come back to self-lookups when we get to relationships in module 7.

Notice that the Account and the Contact sit in the same place in both diagrams. They’re the same records. A sales rep and a service agent are looking at the same customer, from different sides of the house. That’s one of the strongest arguments for staying standard: the models were built to meet.

Files and Attachments

Section titled “Files and Attachments”

Not everything on a record is a field. Contracts, photos, PDFs and spreadsheets are files, and they belong in Salesforce Files, not the old Attachments model, which is legacy. If the document already lives in SharePoint Online, OneDrive, Google Drive or Box, Files Connect lets users reach it from Salesforce without copying it in.

Files are counted differently from records. Salesforce splits storage in two: file storage holds attachments, Files, Salesforce CRM Content, Chatter files and the like, and data storage holds your records. File storage climbs fast when every record gets photos or scans, so large volumes of images, like the photos from a field app, often belong outside Salesforce entirely, with Salesforce keeping only a link. Module 4 comes back to that.

Two Columns or Two Hundred

Section titled “Two Columns or Two Hundred”

Data storage is counted differently from a database too. In a normal database, a table with two columns and a million rows is small, and a table with a hundred columns and a million rows is an elephant. Salesforce weighs them the same: most records count as about 2 KB, no matter how many fields they have. There are exceptions. A campaign counts for more, an email message counts at its real size, and a person account counts as about 4 KB, because it’s an account and a contact.

Here’s a tip. Whenever I walk into a new org, one of the first places I go is Setup → Storage Usage. I’ll even ask a client for a screenshot on the first call. That screen doesn’t lie. It tells you which objects are growing, and which ones are already the elephants.

Person Accounts: When the Customer Is a Person

Section titled “Person Accounts: When the Customer Is a Person”

The Account and Contact model works beautifully for a company and the people at it. But what if your customer isn’t a company? What if it’s a person?

That’s the person account: an account and a contact combined into a single record, for individual people. Their contact fields come along, and the custom ones show up with their own suffix, __pc. Each one counts against both account and contact storage, because underneath it’s both.

One warning before you turn them on: once person accounts are enabled, they can’t be disabled. That’s the Reversibility Test from chapter 1 in its purest form. Module 5 gives you my position on when they’re worth it.

What an Architect Decides Here

Section titled “What an Architect Decides Here”
  • Which parts of the business Salesforce has already modeled, before anything new gets designed.
  • Whether a concept lands in the Sales model, the Service model or both, knowing they share the Account and the Contact.
  • Where documents and images live: Salesforce Files, a connected file system, or off-platform with a link.
  • What the data will cost in storage, counted the way Salesforce counts it: records, not columns.
  • Whether the customer is a company or a person, before turning on something that can’t be turned off.

And when Salesforce doesn’t have what you need? You build it. That’s next.

Explore

Section titled “Explore”