Study guide

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 open sketchbook on a drafting table at dawn, a building sketched on one page and a data model on the other, with a pencil, an eraser, a cup and a lamp. — Image generated with AI

Study guide for chapter 3 of the Data Architect course. Read the ten modules first; this page helps you check what stuck.

About this study guide. It’s built only from this course’s own content and the published Salesforce exam guide’s list of objectives. It is never based on real exam questions, and it doesn’t claim to know what’s on the exam. If you’ve taken the exam, please don’t send me questions from it: the certification agreement forbids sharing them, and memorizing answers is the wrong way to become an architect anyway.

This is the chapter where the model meets the platform, and it carries a lot of the exam. It feeds both of the biggest sections, Data Modeling and Database Design, and Salesforce Data Management, a quarter of the exam each. Platform numbers change: the checklist gives the ones the modules cite, with the date they were checked. Learn what each limit is for, and check the current number before you rely on it.

For the Exam

Tick them off as you go. Each one links to where it’s taught.

DM-1: designing the data model on the platform

DM-2: a model that respects sharing and scales

I know a master-detail child has no owner and no share table of its own: access follows the master. (Ownership Comes Along for the Ride)
I know parent-child skew: Salesforce’s guidance is no more than about 10,000 children on one parent. (The 10,000-Child Question)
I know ownership skew (one user owning more than 10,000 records of an object) and the guidance: spread ownership, or keep that user out of the role hierarchy or alone at the top, and out of public groups used by sharing rules. (Ownership Can Become a Scale Problem)
I know the share table: a custom object’s share object is Object__Share; a detail object has none, its access comes from the master; and a change of owner removes manual shares but keeps Apex sharing with its own reason. (The Share Table)
I can decide who owns records that integrations and agents create, based on whether ownership drives sharing. (Who Owns Records That Systems Create?)

DM-4: big objects versus standard and custom objects

I know the three homes for data: on core (sObjects, worked in every day), referenced (another system is the source of truth: Salesforce Connect’s external objects, __x, or custom calls), and archived (on core in big objects, __b, or off core in a warehouse). (On Core and Off Core)
I know external objects make a callout every time they’re touched, so latency and the source system’s availability matter. (Referenced)
I know big objects: huge volumes, queried through their index by exact match or range, no standard UI or reporting, object and field permissions only, no automation. (Archived)
I know most records count as about 2 KB of data storage regardless of fields, and that files are metered separately in file storage. (Two Columns or Two Hundred, Files and Attachments)

SDM-1: licenses and the objects people can use

I know the three internal licenses, Sales Cloud, Service Cloud and Platform, and what each can use. (Three Internal Licenses)
I know licenses are part of the data model: Salesforce Platform users don’t get Leads, Campaigns, Opportunities or Forecasts, and Customer Community users can’t use Opportunity. (Now Let Me Complicate Everything: Licensing)
I know the external license tiers: Customer Community, Customer Community Plus (reports, dashboards, standard sharing), Partner Community (sales objects); and that Partner Community can’t be used with person accounts. (The Stadium)
I know member-based versus login-based licensing, and which population each suits. (How They Pay Changes the Design)
I know some platform licenses limit users to one app of up to ten custom objects, and the record-type pattern for working within it. (When the License Shapes the Model)
I know the Salesforce Integration license is for system-to-system, API-only users. (People Aren’t the Only Users Any More)
I know SLA reporting needs entitlements and milestones, which need Service licenses. (Now Let Me Complicate Everything: Licensing)

SDM-2: keeping data consistent

I can place a rule on the right rung of the consistency ladder: field type and vocabulary, required and unique, validation rules, duplicate rules, automation. (Keeping Data Consistent)
I know a restricted picklist rejects values not on the list, even through the API, and a global value set shares one list across fields (up to 1,000 values). (Rung One)
I know a page-layout requirement protects only that screen, not the data, and that validation rules run on every save. (UI Validation Isn’t Data Validation, Rung Three)
I can scope a validation rule with ISNEW() and ISCHANGED(), a custom permission or a go-live date, knowing which saves (including ones I don’t control, like a batch owner change or a roll-up) each choice still checks. (The Old Record Problem)
I know matching rules and duplicate rules, the limits the module cites (five active duplicate rules per object, three matching rules each), and that they don’t solve identity across systems. (Rung Four: Duplicate Rules)
I know duplicate rules don’t compare records saved at the same moment, that API and import saves are blocked without an alert, and that a save and everything it sets off roll back as one transaction. (Rung Four, All or Nothing)
I know Workflow Rules and Process Builder are out of support; automation means Flow or Apex. (Rung Five: Automation)

Beyond the Exam

The exam is the floor, not the ceiling. These are the habits from this chapter that an architect needs, whether or not a question ever asks about them.

The platform has a shape. Design for the platform you’re on, not a generic database.
Look to the mothership. See how Salesforce models a concept before you invent one.
Every object is a commitment: storage, limits, a sharing model, licenses and dependencies.
Ask where the data lives before you choose an object: on core, referenced or archived.
Read any API name and you know who made it, and what you can change.
If you’re not archiving today, are you ever going to archive?
Prototype big objects before you suggest them.
Different business names don’t automatically mean different objects.
Ask which identities need the data: people, customers, partners, integrations and agents.
Every field gets a description, and classification where it matters.
Describe the relationship’s behavior first; the configuration implements it. Don’t distort the model to get a feature.
The delete question: what should happen to the children if somebody deletes the parent?
Choose which link breaks the chain: make the lookup where the child really has its own life.
Ownership from the primary, access from both: the most restrictive wins.
Separate inactive from gone, and make retention a business rule.
Push the rule as low as it correctly belongs, and give legitimate history a bypass instead of rewriting it.
The diagram isn’t the architecture. Be able to trace every structure back to a business reason.

Words to Know

Term	In one line
Metadata-driven	Objects and fields are definitions the platform reads at runtime, not new physical tables
Multitenancy	Many orgs share the infrastructure, each isolated, like apartments in one building
Governor limits	Limits that keep one tenant from monopolizing shared resources
External object	Data shown in Salesforce through Salesforce Connect, fetched from its source on every touch
Big object	Storage for very large, rarely used data, queried through its index
Person account	An individual represented as an account, for business-to-consumer models
Clean fit	A business concept that matches a standard object’s intended purpose
External ID	A field holding another system’s identifier, used for upserts and matching
Upsert	Update the record if it exists, create it if it doesn’t
Lookup	A relationship where the child keeps its own owner and life
Master-detail	A relationship where the child belongs to the parent: inherited owner and sharing, cascade delete, roll-ups
Logical junction object	The modeling idea: an object that joins two others in a many-to-many and carries its own attributes, however it’s built
Salesforce Junction Object	What Salesforce means by “junction object”: a custom object with two master-detail relationships
Primary and secondary master	A Salesforce Junction Object’s first-created master-detail (owner, look, division) and its second (report scope; becomes primary if the first is removed)
Hierarchical relationship	A special lookup only on the User object, like Manager, that can’t loop back to the same user
Namespace prefix	The vendor’s prefix on a managed package’s objects and fields, like `abc__Inspection__c`
Share table	The share object (`AccountShare`, `Truck__Share`) holding most of a record’s sharing, one row per user or group, with its reason
Roll-up summary	A field on the master that counts, sums or finds the minimum or maximum of its details
Data skew	Too many records under one parent or one owner, causing locks and long sharing recalculations
Member-based / login-based	Paying per external user, or per login each month
Consistency ladder	The layers that enforce data rules, from field type up to automation
Restricted picklist	A picklist that rejects any value not on its list, from any source
Data classification	Field metadata for owner, usage, sensitivity and compliance category

Check Yourself

Short scenarios in the style of the course. Decide your answer before you open it.

1. Users need to see order details that the ERP owns and updates all day. They don't edit them in Salesforce. Copy them in, or not?

Reference them: external objects through Salesforce Connect keep the ERP as the source of truth with no copy to synchronize. Accept that every view makes a callout, so latency and the ERP’s availability matter, and that it suits read access better than heavy editing or reporting. Reread Referenced.

2. The business wants to track distributors, suppliers and retail partners. Three custom objects?

No. They’re all companies, so Account is a clean fit; the different names are roles, carried by a type, a record type or a relationship. Reread The Clean-Fit Test.

3. A design uses Opportunity, but most of the people who need the data have Salesforce Platform or Customer Community licenses. What now?

Those licenses can’t use Opportunity, so the license is an architectural constraint: buy different licenses, move the experience, or redesign, usually toward a custom object. Reread Now Let Me Complicate Everything: Licensing.

4. The ERP sends nightly updates to accounts. How should the integration find the right record without querying for Salesforce IDs?

Store the ERP’s customer number in an External ID field and upsert on it: update if found, create if not. Child records can point at their parent by its External ID too. Reread External IDs.

5. A Delivery Item can't exist without its delivery, never moves, and needs no owner of its own. A Delivery exists before it's routed and can move to another route. Which relationship for each?

Delivery Item to Delivery: master-detail (it belongs to the parent for life, inherits access, cascades on delete). Delivery to Route: a lookup (its own life, optional at first, movable, and deleting a route must never delete deliveries). Reread Start With the Business Relationship.

6. An integration creates 3,300 deliveries a day, all owned by the integration user, which has a role in the middle of the hierarchy. What's the risk, and the fix?

Ownership skew: past 10,000 records, moving that user or changing its groups triggers long sharing recalculations. Spread ownership if it matters for access; otherwise keep the integration user out of the role hierarchy, or alone in a role at the top, and out of groups used by sharing rules. Reread Ownership Can Become a Scale Problem.

7. You add a validation rule, and 20,000 old records break it. A user edits a phone number on one and the save fails. What should the rule have done?

Said when to enforce, not only what must be true: scope it with ISNEW() or ISCHANGED() on the relevant fields, and give records that predate the rule a deliberate bypass rather than rewriting their history. Reread The Old Record Problem.

8. The business wants every delivery photo "in Salesforce": four to five million a year, growing 30 percent. What do you propose?

Separate access from storage. Keep the files in storage built for that volume, outside the core org, and keep a reference, a count or an index record in Salesforce so users can find and see them. Reread Photos.

9. A Crew Assignment has master-detail relationships to Crew (created first) and Truck. A dispatcher can see the crew but not the truck. Can they see the Crew Assignment?

No. Crew is the primary, so it gives the assignment its owner and look, but access needs both parents: the dispatcher needs access to the crew and the truck, at the level each master-detail field’s Sharing Setting asks for. The most restrictive wins. Reread Two Parents Wide.

10. A partner re-sends a manifest file, and the same customer appears twice in it. You have a duplicate rule on Account set to block. Are you safe?

Not from the duplicate rule alone. Records saved at the same moment aren’t compared with each other, only with records already in Salesforce, so both rows can get through. Push uniqueness down to the field: a unique External ID, which the platform checks on every save, so only one wins. Reread Rung Four: Duplicate Rules and All or Nothing.

Explore

Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab), Salesforce Help (checked 2026-09-25): the official list of objectives and their weights. Always check the current version before you book the exam.
Each module’s own Explore section lists the Salesforce documentation behind its platform facts, with the date it was checked.