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)
Study guide for chapter 1 of the Data Architect course. Read the seven 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 chapter is lighter on exam facts, and that’s on purpose. It’s about how an architect thinks, and no exam objective belongs to it alone. But the exam is built from scenarios: a business, some numbers, a constraint, and several answers that could work. The habits in this chapter are how you read those scenarios. So the checklist below says which objective each point supports, rather than claiming it’s tested directly.
For the Exam
Section titled “For the Exam”Tick them off as you go. Each one links to where it’s taught.
Reading a scenario like an architect (supports every objective)
- I separate the real requirement from the design it arrived in (“we need Approver 2 and Approver 3 fields” versus “we need to track every approval”). (Don’t Just Take the Requirement)
- I look for the implied requirements nobody stated: ownership, freshness, failure, retention, access. (Look for the Implied Requirements)
- I put numbers on it: volume per day, per year, with growth, and I notice when one more zero changes the answer. (Know Your Numbers)
- Among several answers that work, I compare what each gains and gives up against the stated requirements and constraints. (Know What You’re Trading Away, Constraints Change the Answer)
- I treat cost, licensing and limits as part of whether a tool fits, not an afterthought. (The Nine Questions)
The data model (supports DM-1)
- I can judge a model by whether it supports the business, can grow with it, and performs. (Support. Grow. Perform.)
- I can spot a model that’s too flat (Field 1, Field 2, Field 3), over-normalized, or built on the wrong standard object. (Too Flat, Too Complicated, or Just Wrong)
- I know why a picklist suits a short, stable list and a lookup suits a list that keeps growing or arrives from an integration. (Many Ways to Solve the Problem)
- I know a key that carries meaning (part of a name, say) breaks when that meaning changes. (Some Decisions Are Cheap to Change)
Changing what’s already there (supports DM-1 and SDM-2)
- I know why changing a field’s type, or making an existing field Required, can break things later, and why the platform blocks a type change while code or flows reference the field. (Be Careful About Changing the Bones)
- I know the pattern add rather than mutate, deprecate rather than surprise, and that Field Usage can mark a field as a deprecation candidate. (Be Careful About Changing the Bones)
- I know the master-detail facts behind the Reversibility Test: the detail’s access and ownership follow the master, deleting a master deletes its details, roll-up summaries need master-detail, and a lookup converts to master-detail only when every record has a value. (The Reversibility Test, Explore)
Licenses and sharing (supports SDM-1)
- I know high-volume community users (Customer Community among them) have no roles and don’t use the sharing model, so access comes from sharing sets and share groups, and Apex sharing can’t reach them. (A Worked Example: Apex Sharing)
Failure (supports MIG-1 and the integration chapters)
- I know “job completed” isn’t the same as the data is correct, and how reconciliation finds the records that didn’t make it. (Partial Success Is Still Failure You Need to Understand)
Beyond the Exam
Section titled “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.
- Someone has to hold the blueprint. Architecture is making good decisions with incomplete information, and knowing their consequences.
- The data model is the bones. Everything else is built on it.
- The Reversibility Test: how hard is this to reverse, and how much will depend on it?
- Architecture creates gravity. Dependencies make change expensive, not change itself.
- Think about the blast radius, inside Salesforce and across the enterprise. Architecture is two-way traffic.
- Write down why: context, options, decision, consequences, owner, review. Supersede; don’t erase.
- Best at what? A suboptimal decision can be part of an optimal architecture, if you know you’re making it.
- Carry a picture of optimal, so you know which way you’re moving away from it, and why.
- Think Correct. Think Fast. Speed comes from thinking done before the moment.
- Build for today. Plan for tomorrow. Plan for failure. And use 30 percent growth when nobody gives you a number.
- Learn the nine questions, not just the answers.
- AI is a rocket booster. Generation isn’t judgment, irreversible is still irreversible, and human review isn’t a ceremony. Trust but verify.
Words to Know
Section titled “Words to Know”| Term | In one line |
|---|---|
| Architectural decision | One that’s hard to reverse, with a lot depending on it |
| Reversibility Test | How hard is this to reverse, and how much will depend on it? |
| Gravity | The dependencies that collect around a decision over time |
| Blast radius | Everything else that moves when a decision changes |
| Decision record | Context, options, decision, consequences, owner and review point, kept small |
| Trade-off | What an option gains, and what it gives up to get it |
| Implied requirement | Something the business expects without asking, like recovery when a load fails |
| Steve’s Number of Zeros | One more zero in the volume can change the whole architecture |
| Reconciliation | Comparing what should have happened with what did, record by record |
| Deprecate | Mark something as on its way out, then retire it deliberately, instead of changing it in place |
| High-volume user | A community user (Customer Community among the licenses) with no role, outside the sharing model |
| Schema sprawl | Objects and fields that pile up because they were cheap to create, until nobody designed the model |
Check Yourself
Section titled “Check Yourself”Short scenarios in the style of the course. Decide your answer before you open it.
1. A sales team asks for Approver 2 and Approver 3 fields, each with a date, on the Opportunity. What do you ask, and what might you build?
Ask why, and how many approvals there can be. If there can be more than two or three, the requirement is to track every approval, not to add fields: a child object, one record per approval. Reread Don’t Just Take the Requirement.
2. Someone wants to rename a field's label, and someone else wants to change the format of the customer identifier five systems already store. Which deserves more of your attention, and why?
The identifier. The label is cheap to change. The identifier fails the Reversibility Test: hard to reverse, and a lot already depends on it. Spend attention in proportion to the cost of being wrong. Reread Some Decisions Are Cheap to Change.
3. A text field has been in use for years. The business wants it to hold a number now. What's your approach?
Don’t mutate it in place. Find what depends on it (Flows, Apex, reports, integrations, agents) and what happens to the old data. Usually: add a new field, migrate deliberately, and deprecate the old one. Reread Be Careful About Changing the Bones.
4. 1,200 locations, 100 appointments a location a day, about 305 days a year, two records per appointment, five years kept, 30 percent growth. Roughly how many records, and why does it matter?
About 73 million records in the first year (36.6 million appointments, two records each), and over 650 million across five years with growth. Same feature, a couple more zeros, a very different architecture. Reread Know Your Numbers.
5. A nightly load reports "completed" on a million records. How do you know it worked?
You reconcile. The receiving side confirms each record it saved; the sender compares what it sent with what was confirmed. Missing confirmations mean it didn’t work, whatever the job status says, and tell you which records to retry, route to a person, or alert on. Reread Partial Success Is Still Failure You Need to Understand.
6. A community of 15 million Customer Community users needs complex record access. Someone proposes Apex sharing. What's the problem?
They’re high-volume users: no roles, outside the sharing model, so there’s no share record for Apex to write. Access comes from sharing sets and share groups. The license decided which sharing tools exist. Reread A Worked Example: Apex Sharing.
7. An AI tool generates twenty objects for a new app in minutes. What's the architect's job now?
Decide whether we should have five. Understand the model well enough to defend it: why these objects and relationships, where the keys and master data are, what happens at scale. Verify the facts it relied on. Generation isn’t judgment. Reread Cheap Implementation Moves the Value.
Explore
Section titled “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.