Study guide
Study guide for chapter 10 of the Securing Salesforce: Sharing and Visibility 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 teaches two objectives from the exam section Access to Records, the biggest section at 39% of the exam: the object relationships that support sharing, and the overrides that go around it. Chapter 6 started both; chapter 16 finishes the ways that take access away. The exam guide aligns to Winter ‘23, and how child access is stored has changed since then, so that’s in its own list at the end. Know both, and know which date each belongs to.
For the Exam
Section titled “For the Exam”Tick them off as you go. Each one links to where it’s taught.
Overrides (supports REC-9)
- I know the two sizes: View All Records and Modify All Records on one object, View All Data and Modify All Data on every object, and that the one-object permissions are the better choice where they fit. (Four permissions, two sizes)
- I know they don’t override field-level security, can’t be given to external users, and aren’t available for ideas, price books, article types and products. (What they don’t open)
- I know View All on an object doesn’t open its standard children, such as an account’s contacts, opportunities and cases, but does open its custom child records. (What they don’t open)
- I know the neighbors: View All Users, View All Lookup Record Names, and Modify Metadata Through Metadata API Functions for deployment users instead of Modify All Data. (Their neighbors)
- I know overrides write no share row, and that the Sharing Overrides list shows profiles but not permission sets, so permission sets need a query on ObjectPermissions. (No row, so where do you look?)
- I know never to test sharing as a user with an override. (Don’t test as the admin)
The six kinds of implicit sharing (supports REC-6)
- I know the six kinds: parent, child, site, case contact, high volume and high-volume parent. (The six kinds)
- I know parent implicit: see an account’s case, contact or opportunity, and you get Read Only on the account, even with accounts Private. (See a child, see the parent)
- I know child implicit: see the account, and you can get its cases, contacts and opportunities, at the level set on the account owner’s role and on account rules and shares. (See the parent, see the children)
- I know it works only for the account and those children, only when the child is Private (not Controlled by Parent), and not through View All. (Where it applies)
- I know orders and contracts behave differently: an order’s owner reads its account, but the account doesn’t open its orders; contracts share the account’s default. (Where it applies)
Child access on the role (supports REC-6)
- I know every role sets Contact Access, Opportunity Access and Case Access on other users’ records on accounts its users own: View, Edit or No access. (Every role you create is a sharing decision)
- I know you can’t set it when the child is Public Read/Write, or contacts are Controlled by Parent, and never below the child’s default. (When you can’t set it)
- I know the four places child access is set: the role, an account sharing rule, an account team and a manual share, and that the owner’s role caps a manual share. (Four places child access is set)
What implicit sharing costs (supports REC-6)
- I know losing one child means Salesforce checks every other child before removing parent implicit access. (The reason, and the check)
- I know parent-child data skew starts at 10,000 children on one account, and to avoid one placeholder account. (When the account has too many children)
- I know the guidance: Public defaults for non-confidential data, Controlled by Parent where security allows, and no more than 10,000 children per parent. (Designing so it stays fast)
External users (supports REC-6)
- I know a site user sees their account and its other site-enabled contacts, and the one setting that shows the contacts who aren’t site users. (Site users)
- I know a site user who is a case’s contact gets Read and Write on that case, whoever owns it, and why ownership and a sharing set aren’t the answer. (The case contact)
- I know case contact access reaches up the customer’s role hierarchy, and can be turned off with Grant site users access to related cases. (How far it reaches)
Where it stops (supports REC-6)
- I know an account hierarchy doesn’t share: the parent account doesn’t open its child accounts, unlike the role and territory hierarchies. (Account hierarchies don’t share)
- I know there’s no implicit sharing on custom objects; use master-detail with Controlled by Parent, or sharing of its own. (No implicit sharing on custom objects)
- I know parent and child implicit sharing can’t be switched off, only designed around. (You can’t switch it on or off)
What changed since the exam’s Winter ‘23 alignment (dated, beyond the exam today)
- I know that since Summer ‘23, enforced in Winter ‘24, child implicit access to cases and contacts isn’t stored as share rows; Salesforce works it out when the user opens the record. (What Salesforce changed)
- I know the same came to opportunities in Winter ‘24, enforced in Spring ‘24, so queries and tests that read those rows return nothing. (What Salesforce changed)
- I know parent implicit access is still a row: AccountShare, row cause ImplicitParent. (What Salesforce changed)
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.
- Keep a written reason for every override, and review them with a query, not only the Setup list.
- Give deployment users the narrow permission, never Modify All Data.
- Prove the negative first, in an empty, fully Private sandbox with a standard user.
- Decide child access on every role you create, including no access where the business means it.
- Keep accounts under 10,000 children, with no placeholder account for everything that doesn’t fit.
- Test what the user can see, not whether implicit share rows exist.
- Decide which account each external user sits under, and whether case contact access stays on.
- Write down where the business assumes access the platform doesn’t give: account hierarchies and custom objects.
Words to Know
Section titled “Words to Know”| Term | In one line |
|---|---|
| View All Records / Modify All Records | Object permissions that see or edit every record of one object, skipping sharing |
| View All Data / Modify All Data | User permissions that see or edit every record of every object |
| Sharing Overrides list | The Setup list of profiles that override sharing on an object; it misses permission sets |
| Implicit sharing | Access Salesforce grants by itself between an account and its children, and for external users |
| Parent implicit sharing | Read Only on an account for a user who sees one of its cases, contacts or opportunities |
| Child implicit sharing | Access to an account’s children for the account owner, set on the owner’s role |
| Contact, Opportunity and Case Access | The role’s settings for other users’ children on accounts its users own |
| Parent-child data skew | One parent record with 10,000 or more children |
| ImplicitParent | The row cause on AccountShare for parent implicit access |
| Case contact implicit sharing | Read and Write on a case for the site user who is its contact |
| Account hierarchy | Accounts linked by Parent Account, which grants no access |
Check Yourself
Section titled “Check Yourself”Short scenarios in the style of the course. Decide your answer before you open it.
1. Sales Operations, spread across many roles, must see every opportunity. Opportunities are Private. What do you give them?
A permission set with View All Records on opportunities, with the reason written down. Not View All Data: prefer the one object over every object. Reread Four permissions, two sizes.
2. A user has View All Records on accounts but can't see the accounts' opportunities. Why?
View All on an object doesn’t open its standard children. They still need Read through sharing. It would open custom child records. Reread What they don’t open.
3. You check the Sharing Overrides list for cases and find only the System Administrator profile. Is that everyone?
No. The list doesn’t show permission sets. Query ObjectPermissions for View All Records and Modify All Records on cases, then follow the permission sets to their users, including through groups. Reread No row, so where do you look?.
4. Every default is Private. A user owns one opportunity and can see its account. Nobody shared the account. Why?
Parent implicit sharing: see a child case, contact or opportunity, and you get Read Only on its account. Change the opportunity’s owner back, and the account goes. Reread See a child, see the parent.
5. Contacts are Controlled by Parent. Does parent implicit sharing apply to them?
No. Implicit sharing works only when the child is Private. A Controlled by Parent child follows the account anyway. Reread Where it applies.
6. A rep owns an account. Another team owns a confidential opportunity on it. The rep can see the opportunity. What did that?
The rep’s role: its Opportunity Access gives view on other users’ opportunities on accounts the rep owns. Set it to no access if the business means it, and give the people who need it access another way. Reread Why “no access” is a real choice.
7. Marketing parks 300,000 contacts under one placeholder account. What's the risk?
Parent-child data skew. When a user loses access to one of those contacts, Salesforce must check the other 299,999 before removing the account. Keep parents under 10,000 children. Reread When the account has too many children.
8. An old Apex test counts implicit child share rows for contacts and now fails. Why?
Since Summer ‘23, Salesforce doesn’t store implicit child shares for cases and contacts, and since Winter ‘24 for opportunities, so the query returns nothing. Test what the user can see instead. Reread What Salesforce changed.
9. A customer creates a case on the site. Assignment rules send it to a queue. How does the customer still see it?
They’re the case’s contact, and a site user, so case contact implicit sharing gives them Read and Write, whoever owns the case. Not ownership, which the assignment removed, and not a sharing set, which would show every case on their account. Reread The case contact.
10. A global account manager owns the parent account of a company's subsidiaries, but can't see the subsidiary accounts. Is that a bug?
No. An account hierarchy doesn’t share. Build it with territories, account teams, a criteria-based rule on a real field, or code. Reread Account hierarchies don’t share.
Explore
Section titled “Explore”- Salesforce Certified Platform Sharing and Visibility Architect Exam Guide (opens in a new tab), Salesforce Help (checked 2026-11-07)
The official list of objectives and their weights. Always check the current version before you book an exam.