Study guide

🌐 Also in 19 languages

Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Українська · Español (México) · Français (Canada) · Deutsch (Schweiz)

Image generated with AI

Study guide for chapter 7 of the Data Architect course. Read the four 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 opens Part 2 and the exam’s Large Data Volumes section (20%), with data skew from Data Modeling. Query design is the next chapter; this one is about volume, hot spots, sharing at scale and the lifecycle. Platform numbers change, so check the current ones before you rely on them.

For the Exam

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

LDV-1: a model that scales

• I size a design for growth across the retention period, not today’s volume, and I multiply the children. (Don’t Ask How Big It Is Today, Now Multiply the Children)
• I know volume affects more than queries: sharing, ownership, locking, list views, reports, batch, loads, deletes and recovery. (Queries Aren’t the Only Thing That Slows Down)
• I know when controlled denormalization is justified by scale, and what it costs. (Clean Models Can Become Expensive Models)
• I know not to turn the operational CRM into the warehouse, and that reporting snapshots aren’t a warehouse strategy. (Don’t Make Core CRM Your Warehouse)
• I know volume has shape: twenty million records doing what? (Volume Has Shape)

DM-5: data skew

• Test knowledge: I know parent-child skew and the guidance of no more than about 10,000 children per parent; it’s a design threshold, not a cliff. Where security allows, Controlled by Parent on the child takes away the parent’s implicit shares to maintain. (Parent-Child Skew)
• I know the account pool fix for an artificial parent, and to hide placeholder parents from users. (The “Unassigned” Account, and Account Pools)
• Test knowledge: I know Salesforce’s best practice of no more than 10,000 children for one master-detail parent, and what master-detail brings at volume: no owner on the detail, cascade delete, no reparenting unless allowed, roll-up summaries, parent locking. I count the children before I choose master-detail or lookup, and I know converting back to a lookup needs no roll-up summaries on the master. (Master-Detail at Volume)
• Test knowledge: I know ownership skew (one user owning more than 10,000 records of an object) and the fix: no role, or a separate stable role at the top, and out of public groups used by sharing rules. (Ownership Skew)
• I know lookup skew: many active records pointing at one record, and the record locking it can cause. (Lookup Skew)
• I can tell a dangerous skew from a harmless one by its activity, not just its count. (Not Every Skew Is Equally Dangerous)
• I fix skew on a real business entity with a meaningful split (a child account per distribution center), never fake copies of it. (Steve Trucking: Where Are the Hot Spots?)

DM-2: sharing at scale

• I know access structures (owners, roles, groups, shares) are data too, and they scale. (Sharing Is Data Too)
• Test knowledge: I know the share object (AccountShare, Object__Share): one row per grant, with a row cause; the three kinds of tables behind record access (object record, object sharing, group maintenance); and that sharing with groups rather than individuals means fewer sharing rows. (The Share Table Has Its Own Number of Zeros)
• I know a role hierarchy change at volume is a data operation, so stability is a design feature. (The Role Hierarchy Isn’t an Org Chart)
• Test knowledge: I know deferred sharing calculations: make all the changes, then recalculate once in a maintenance window, tested first in a full copy sandbox. (Sharing Recalculation Is Real Work)
• Test knowledge: I know granular locking (on by default) lets unrelated group operations run together, but doesn’t fix a poor design. (Granular Locking Helps)
• I know performance isn’t an excuse to make data public that should be private. (Don’t Optimize Away Security)

LDV-2: archiving and purging

• I can keep retention, archiving and purging apart, and set them at the start of a project. (Deletion Is Inevitable)
• I put backups in place before anything is deleted, and know backup and archive are different capabilities (Salesforce Backup & Recover, Archive). (Back Up Before You Delete)
• Test knowledge: I can choose an archive destination by constraint: big objects, an external store through Salesforce Connect (OData, SQL adapters or a custom adapter), or Salesforce’s Archive. (Where Should the Archive Live?)
• Test knowledge: I know what big objects are: built for very large volumes (consistent performance from a million records to a billion); reached through Apex, APIs and their index, not the standard UI; object and field permissions only, no sharing rules; no triggers or flows. (Where Should the Archive Live?)
• Test knowledge: I know how to purge at volume: soft-deleted records stay in the Recycle Bin for 15 days and still slow queries; for a million records or more, Bulk API 2.0 hard delete; children before parents. (Deletion Is Inevitable)
• I know the three-step archive (copy and flag, verify, delete and flip), and that it must be restartable. (The Three-Step Archive)
• I know archived data must stay findable and keep its security. (An Archive Nobody Can Find Is Almost a Deletion, The Archive Still Has to Be Secure)

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.

• Salesforce is built for transactions on structured data, on a multitenant database where Salesforce writes the SQL. Millions of records perform well because somebody designed for them. (Built for Transactions)
• My large data volume ruler (records in one object): around a million, a little drag; ten million, some effect but still performing; heading toward fifty million, list views take seconds, and past it you’re the convertible with your hair blown back; at a hundred million or more, ask whether the records should be here at all.
• What works today may fail tomorrow.
• Sometimes the best fix is not to create the problem: keep GPS, photos and status history out of core.
• The number tells me where to look; the behavior tells me how worried to be.
• At this scale, organizational changes become data operations.
• Scale fixes still have to preserve meaning.
• Find the hot spots on the diagram: look at the arrows and ask how many records pile up on each side.
• Test the Number of Zeros you’re actually designing for.
• AI is going to add more zeros. Model agent-generated volume explicitly.
• Who owns machine-created records depends on whether ownership matters for sharing. Created by and owned by aren’t the same question; decide what Owner means for each object. (Who Should Own Machine-Created Records?)
• If you’re not archiving today, are you ever going to archive?
• Design the exit when you design the entrance. Five answers per object: when it stops being active, where it goes, how we prove it, how someone finds it, when it’s deleted.
• Whether agents can reach archived data is the business’s decision.

Words to Know

Term	In one line
Large data volume (LDV)	Enough records that the platform’s behavior, not just the count, shapes the design
Data skew	Too many records concentrated on one parent, owner or lookup value
Parent-child skew	Too many children under one parent record
Ownership skew	One user owning more than about 10,000 records of an object
Lookup skew	Many active records referencing one record, causing lock contention
Account pool	Several placeholder parents sharing the children of an artificial parent
Controlled by Parent	A sharing setting where the child’s access comes from its parent, so the parent has no implicit shares to maintain
Share object	The table of sharing rows for an object (AccountShare, Object__Share): one row per grant, with a row cause
Big object	An object built for very large volumes, reached through Apex, APIs and its index; object and field permissions only
Sharing recalculation	The platform working out access again after a change to owners, roles, groups or rules
Deferred sharing calculation	Holding recalculation until a batch of changes is done, then running it once
Granular locking	Locking only the parts of the group-membership tables an operation needs
Retention	How long data is kept, and why
Archiving	Moving data out of the active workload while keeping the access the business needs
Purging	Permanently removing data at the end of its retention
Three-step archive	Copy and flag, verify, then delete and flip

Check Yourself

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

1. A company makes a million deliveries a year, growing 30 percent, and keeps five years. What volume do you design for?

About 9 million deliveries kept across five years, not one million, and then their children: about 14.5 million line items at 1.6 a delivery, and 72 million status events at eight a delivery. Reread Don’t Ask How Big It Is Today.

2. 300,000 contacts sit under one account called "Unassigned Contacts." What do you do?

It’s artificial parent-child skew. Spread the contacts across an account pool of placeholder parents, each under the threshold, and hide those placeholders from normal business views. Or ask whether the contacts need an account at all. Reread The “Unassigned” Account, and Account Pools.

3. One Retail Partner will have 3.6 million work orders. Someone proposes Redrock 001, 002 and 003 accounts. Your view?

No: that corrupts a real business entity. Look for a split the business recognizes, like a child account per distribution center, and archive completed deliveries to keep the active children low. Reread Steve Trucking: Where Are the Hot Spots?.

4. An integration user owns 2 million records and sits in a regional role that's about to move in a reorganization. What's the risk, and the fix?

Moving it forces access recalculation across 2 million records. Give high-volume owners no role, or a separate stable role at the top, keep them out of sharing-rule groups, and decide whether ownership should drive access for these records at all. Reread Ownership Skew.

5. A reorganization will change hundreds of roles, groups and sharing rules over a weekend. How do you run it?

As a data operation: test it at real volume in a full copy sandbox, defer sharing calculations, make all the changes, recalculate once in an agreed maintenance window, then verify, with a fallback plan. Reread Sharing Recalculation Is Real Work.

6. The team plans to archive 20 million records with one job that copies and deletes. What would you change?

Three steps: copy and flag as pending, verify the archive (counts, identifiers, relationships, retrieval), then delete and flip, with states so a failure at record 14 million can restart safely. And a backup before anything is deleted. Reread The Three-Step Archive.

7. The customer doesn't want data stored outside Salesforce, but needs to keep years of appointment history. Where could the archive live?

On-platform: big objects, or Salesforce’s Archive. With big objects, plan the access path first: no standard UI or reporting, queried through the index. And keep it findable, like showing archived appointments below the live ones. Reread Where Should the Archive Live?.

Explore

• Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab), Salesforce Help (checked 2026-11-01): 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 facts.