Skip to content
SteveTechArcSteveTechArc Courses

Salesforce Data Architecture

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)

Chapter 3 of Data Architect, Part 1: Becoming a Data Architect. Previous: Modeling Data for Meaning.

Here’s a question I ask every class. If somebody says “I work with Salesforce,” what’s the API name of the product object?

It’s Product2. It’s my first litmus test. Somewhere along the way, Salesforce built the product object, realized it wasn’t working, and had to leave it behind. They couldn’t just take it away, so they added Product2. Even Salesforce lives with its old structures.

Salesforce also gave itself room to grow. Its standard objects carry no prefix or suffix, and we, the people customizing orgs, can never occupy that space. So Salesforce can keep adding objects and never collide with anything we build.

Here’s the lesson in that: creating an object takes ten minutes. Living with it takes years. Every object and every field you add is a commitment. It takes storage. It picks up limits. It gets a sharing model, whether you designed one or not. It needs a license for every person who touches it. And now AI reads it too, so what you name it and how you describe it decides what an agent understands about your data. Adding is easy. Taking away is hard.

This chapter turns Salesforce’s building blocks into decisions.

Architect and senior developer sorting delivery data into owned, referenced, archived and content zones on a glass wall on a rainy day

Image generated with AI.

The structures at a glance

Section titled “The structures at a glance”

Salesforce gives you six places to hold data. I put them on one slide, because the first job is knowing they all exist:

StructureWhat it’s forThe catch
Standard objectsSalesforce’s own model: Account, Contact, Opportunity, Case, Asset and the restUse them for what they’re meant for, or they fight you
Custom objectsYour own business dataEasy to create, hard to retire
External objectsData that lives in another system, shown in SalesforceEvery touch is a callout
Big objectsHuge volumes you must keep but rarely openNo standard UI or reporting; you query through the index
FilesDocuments, photos and other contentFile storage climbs fast
AttachmentsThe old way to store filesLegacy: use Files

Picking one is only part of it. Before the structure comes the question of where the data should live at all: on core, referenced where it already sits, or archived.

The path through this chapter

Section titled “The path through this chapter”

This chapter is big, so it comes in ten parts. Each one stands on its own. In Chapter 2 we decided what the model should be; here we decide how it should live on Salesforce.

  1. The Salesforce data platform: more than a database. What makes Salesforce different, and why the platform has a shape.
  2. Look to the mothership: the standard data models. The Sales and Service models Salesforce has already built, files, storage, and person accounts.
  3. Build your own: custom objects. What the New Custom Object screen decides, the fields you didn’t create, and how to read any API name: standard, custom or managed package.
  4. Where does this data live? On core, referenced, or archived, decided before any object is created.
  5. Choose the right object. The clean-fit test, the baggage standard objects bring, person accounts, and the licenses that decide what people can use.
  6. Fields are architecture too. Field type by field type, the behaviors that surprise people, and why every field gets a description.
  7. Relationships have consequences. Lookup or master-detail, three levels deep and two parents wide, the logical junction object and the Salesforce Junction Object, and the limits that bite.
  8. Ownership and lifecycle. Who owns a record, the share table where ownership becomes access, and what happens to a record over its life.
  9. Keeping data consistent. The consistency ladder: every layer has a cost, and you never “fix” history to satisfy a new rule.
  10. Design the Salesforce physical model. A slice of Steve Trucking, from logical model to Salesforce, built up step by step, with the reasoning.

When you’ve finished, check yourself with the chapter study guide: a checklist for the exam, the habits beyond it, the words to know, and a few questions.

What an architect decides here

Section titled “What an architect decides here”
  • What Salesforce already models, before inventing anything: look to the mothership.
  • Where each kind of data lives, on core, referenced or archived, before choosing a structure.
  • Which structure holds it, knowing what each one gives up.
  • How the objects relate, who owns the records, and what that means for access and scale.
  • Which licenses the model depends on, checked before the objects are designed, not after.
  • How the data stays consistent, and what each consistency layer costs.

Beyond the exam: AI-assisted building can create objects and fields in minutes. When adding is nearly free, “every structure is a commitment” matters more, not less. Each module ends with what AI changes for that decision.

Explore

Section titled “Explore”

Next: Understanding Enterprise Data