Study guide

Study guide for chapter 6 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 four objectives from the exam section Access to Records, the biggest section at 39% of the exam: organization-wide defaults, the role hierarchy, the object relationships that share for you, and the overrides that go around sharing. Chapter 10 finishes the relationships, and chapter 16 finishes the overrides. The exam guide aligns to Winter ‘23, and a few settings have arrived since then, so those are in their own list at the end. Know both, and know which date each belongs to.

For the Exam

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

How access is decided (supports REC-1 and REC-9)

I know the two rules: between the office and the cabinet, the most restrictive wins; inside the cabinet, the most generous grant wins. (Two rules, at two different lines)
I know the four kinds of access grant: explicit, group membership, inherited and implicit. (Four kinds of access grant)
I know access lives in the object’s table, its share table with a row cause per grant, and the group maintenance tables, and which objects have no share table. (Where Salesforce keeps the answer)
I know access is calculated in advance, when the setup changes, so moving a role or changing many owners is expensive. (Worked out in advance)

Org-wide defaults (supports REC-1)

I know the question for every object: is there even one user who mustn’t see a record? Then it’s Private. (Your very first stop)
I know what Private, Public Read Only and Public Read/Write each allow, and that only the owner can share or delete even on Public Read/Write. (Three levels, precisely)
I know a default never gives the object: without Read from a profile or permission set, the user sees nothing. (Three levels, precisely)
I know the special levels: Controlled by Parent, Public Read/Write/Transfer for cases and leads, Public Full Access for campaigns, the price book levels, and that a Private account forces Private opportunities and cases. (The special objects)
I know the external default can never be more open than the internal one, and that guest users are always Private. (Two defaults)
I know opening up a default takes effect at once, locking down only after the recalculation, and that Apex sharing on a custom object holds its default at Private. (Changing a default)

Owners and queues (supports REC-1 and REC-2)

I know the owner gets full access, but still needs the object, and that some objects, such as products and master-detail details, have no owner. (The owner gets full access and Not every object has an owner)
I know who can transfer a record, and what moves with it: the hierarchy access moves, and manual shares are deleted by default. (A record moves)
I know queues can own records, who can be a member, and that each queue has its own Grant Access Using Hierarchies setting. (Way 4: queues)
I know the ownership skew line: an owner of more than 10,000 records should have no role, or a role at the top in its own branch. (When one owner owns too much)

The role hierarchy (supports REC-2)

I know the hierarchy shares what’s owned by or shared with users below, up and never across, by role and not by the Manager field. (What the hierarchy does)
I know the hierarchy can be turned off only for custom objects. (What the hierarchy does)
I know each role sets its access to the contacts, opportunities and cases on accounts its users own. (Every role you create is a sharing decision)
I know a role stands for a level of data access, not a job title, and the four things a hierarchy is for. (Design it for access)
I know the best practice of no more than 10 levels, and the role limits by org creation date. (How deep, and how many)
I know the two places for overlays: their own branch with rules, teams or territories, or folded in with the reporting cost. (Overlays)

Confidential records and the overrides (supports REC-2 and REC-9)

I know the ways to keep a record from the top: a branch that starts at the top, an owner with no role, a queue with its hierarchy off, the hierarchy turned off on a custom object, or a restriction rule where the object supports one. (Own it in a branch and Three more tools)
I know a queue protects a record only while the queue owns it. (Three more tools)
I know View All, Modify All, View All Data and Modify All Data go around sharing, that restriction rules don’t stop View All Records or View All Data, and that they don’t apply to code in system mode. (What gets through anyway)

Relationships that share (supports REC-6)

I know the two kinds of Controlled by Parent: chosen for the account family, and built into every master-detail detail. (Two kinds of Controlled by Parent)
I know a detail has no owner, and so no sharing rules, manual sharing or queues. (What a detail gives up)
I know the relationship’s Sharing Setting, Read Only or Read/Write on the master, decides who can change the details. (The Sharing Setting)
I know a junction object needs access to both masters, and takes its owner from the primary one. (Two masters)
I know when a child needs a lookup: its own owner, or an audience smaller than the parent’s. (Lookup or master-detail)
I know converting master-detail to lookup makes the default Public Read/Write, and lookup to master-detail makes it Controlled by Parent. (Changing your mind)

Who can see other users (supports REC-1)

I know the User object is Private or Public Read Only, and that seeing a user includes lookups, list views and search. (Two defaults for user records and What seeing a user means)
I know the ways to open users back up: View All Users, user sharing rules (only for users with roles), manual sharing of a user, and Manage External Users. (Opening it back up)
I know Standard Report Visibility, and that standard report types follow the primary object’s sharing while custom report types follow both. (Standard Report Visibility)

What changed since the exam’s Winter ‘23 alignment (dated, beyond the exam today)

I know that in orgs created before February 8, 2024, records open to Roles and Subordinates can reach portal users when digital experiences are turned on, so queues use Role and Internal Subordinates where you mean only your own people. (Way 4: queues)
I know that since Winter ‘27, Keep manual shares when transferring records can keep manual shares when the owner changes; it’s off by default. (A record moves)
I know the Sharing Settings page now has Grant access using hierarchies by default in new queues, which sets the starting value for new queues only. (Way 4: queues)

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.

Set the defaults for the future you can see, not only for today’s users: next year’s site, next year’s partners.
Open is a decision too. Write down why an object is Public Read/Write, the same as why one is Private.
Look for the Owner field before you design ownership into an object.
Draw the hierarchy before you build it, and ask what level of data access each role stands for.
Start at the top when an org holds confidential data: who is there, and what permissions they hold.
Ask the sharing question on the data model, before anyone picks master-detail in the field wizard.
Plan the expensive changes: default changes, role moves and owner changes on many records, with a time and a recalculation in mind.
Share with a bucket, not a person, to keep share rows few and changes cheap.

Words to Know

Term	In one line
Org-wide default	How locked an object’s records start, before any other way of sharing
Default external access	A second default for outside users who log in, never more open than the internal one
Access grant	One reason a user can see a record: explicit, group membership, inherited or implicit
Share table	The table of grants for an object, one row per grant, each with a row cause
Row cause	The reason recorded on a share row: the owner, a rule, a team, a manual share, code
Group maintenance tables	Where Salesforce keeps who belongs to which group, including a group for every role
Full access	What the owner gets: read, edit, share, transfer and delete
Queue	A group that can own records until someone takes them
Grant Access Using Hierarchies	The setting that shares records up the role hierarchy; off only for custom objects and queues
Overlay	Someone whose access crosses branches, such as sales operations
Controlled by Parent	A child’s access decided by its parent record
Sharing Setting	On a master-detail field: the access to the master needed to change its details
Junction object	A custom object with two master-detail relationships
View All Users	The permission to read every user record, whatever the User default

Check Yourself

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

1. A user has Edit on the object, and a sharing rule gives them Read Only on a record. A team gives them Read/Write on the same record. What can they do?

Edit. Inside the cabinet, the most generous grant wins, so the team’s Read/Write counts. Between the office and the cabinet, the most restrictive wins, and the office gives Edit, so nothing is lost. Reread Two rules, at two different lines.

2. All employees should read every account. Partners on a site should see only their own. How do you set the defaults?

Internal Public Read Only, external Private, then open accounts up for partners with the external tools later in the course. The external default can’t be more open than the internal one. Reread Two defaults.

3. You set a large object from Public Read/Write to Private. An hour later, users still see records they shouldn't. Is it broken?

Probably not. Locking down takes effect only after the recalculation finishes; until then users keep the old access. Opening up would have been immediate. Check Background Jobs. Reread Changing a default.

4. A design gives each product an owner and shares products by owner. What's wrong?

Product2 has no Owner field, so there’s no ownership-based sharing to design. What users can do with products comes from object permissions and price books. Reread Not every object has an owner.

5. A rep shared an account by hand with a colleague. The account moves to a new owner and the colleague loses access. Why?

By default, Salesforce deletes manual shares when the owner changes. Since Winter ‘27, Keep manual shares when transferring records can change that for the org. Reread A record moves.

6. Two sales managers sit in the same role. Can each see the other's opportunities through the hierarchy?

No. The hierarchy shares up, never across. Peers in the same role don’t get each other’s records, and the Manager field plays no part. If they need to, open it with another way. Reread What the hierarchy does.

7. Sales operations support every region. Someone proposes a role above all the regional managers. What do you weigh?

Folded in, they get access through the hierarchy, but they show up in every roll-up report as if they managed the regions, and everything below climbs to them. In their own branch, you open what they need with a rule, a team or territories. Reread Overlays.

8. HR complaint cases must not reach the CEO. You can't turn off the hierarchy for cases. What can you do, and what gets through anyway?

Have them owned in a branch that starts at the top, or by users with no role, or held in a queue with its hierarchy off while it owns them. Restriction rules don’t support cases today. Anyone with View All on cases, or View All Data, still sees them, so check the CEO’s permissions too. Reread Own it in a branch and What gets through anyway.

9. Some people who see a project mustn't see some of its time entries. Time entries are the detail in a master-detail. What now?

A master-detail can’t do that with sharing: whoever sees the master sees all its details. Make it a lookup, so the child has its own owner, default and sharing. Before you convert, plan the default: converting to a lookup sets it to Public Read/Write. Reread Lookup or master-detail and Changing your mind.

10. User records are Private, and a user sharing rule shares a group of high-volume site users with an internal group. It doesn't work. Why?

Only users with roles can be in user sharing rules, and high-volume site users have no roles. Reread Opening it back up.

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.