Study guide
Study guide for chapter 1 of the Securing Salesforce: Sharing and Visibility 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 has no exam objective of its own. It’s the frame for all of them. The exam guide lists security principles (least privilege, defense in depth, failing securely) among the things candidates often need help with, and this chapter is where the course teaches them. Each point below names the objectives it supports; the later chapters teach each one in depth.
For the Exam
Section titled “For the Exam”Tick them off as you go. Each one links to where it’s taught.
The three layers (supports OBJ-1, OBJ-2 and REC-1)
- I can separate authentication (getting in) from authorization (what you can do once you’re in). (Getting in, and then what you can do)
- I can name the three sets of controls: the front door, the offices (structural security: can you see the object, the field?) and the file cabinets (record access: which records?). (The offices: structural security, The file cabinets: record access)
- I know record access assumes object access: sharing a record with someone who has no access to the object doesn’t let them in. (The file cabinets: record access)
- I know that where the layers meet, the most restrictive wins, both ways: Edit on the object with a Read Only share gives Read, and Read on the object with a Read/Write share gives Read. (Where they meet: the most restrictive wins)
The one exception (supports REC-9)
- I know View All Records and Modify All Records on an object give every record of that object, whatever the sharing, and that View All Data and Modify All Data do it for every object in the org.
- I know none of them overrides field-level security: users still need field permissions, or the separate View All Fields object permission. (The one exception: View All and Modify All)
- I know the side effects of granting View All Records as a quick fix: every record, Modify All’s delete, transfer and approve, and View All Records turned on for a master-detail parent. (Failing securely: when in doubt, the door stays shut) (The one exception: View All and Modify All)
The four principles (supports REC-1, REC-2, OBJ-3 and IMP-3)
- I start new profiles from Minimum Access – Salesforce and add upward, rather than cloning a standard profile. (Least privilege: start from nothing and add)
- I set the organization-wide default to Private if even one user shouldn’t see some records, and open up from there. (Least privilege: start from nothing and add)
- I know the role hierarchy sends records up to whoever sits at the top, and that for a standard object such as Case, Grant Access Using Hierarchies can’t be turned off; a confidential record must be owned in a branch that starts at the top, or by a user with no role. (Need to know: the CEO and the complaint)
- I know hiding a field on a page isn’t securing it: if users have field access, the value can still reach list views, reports, dashboards and global search. (Defense in depth: hiding isn’t securing)
- I know Salesforce’s core access model is grant-based: what no one granted, the user doesn’t have, so the risks are in what we add. (Failing securely: when in doubt, the door stays shut)
- I prove a sharing model with three users (the administrator, a user it’s shared with, a user it isn’t), testing the positive and the negative. (Prove it: three users)
What changed in 2025–2026 (supports OBJ-1 and OBJ-5; newer than the exam’s release alignment, so beyond the exam today)
- I know profile filtering is on by default (a Summer ‘26 release update, enforced in Winter ‘27): users see only their own profile name unless they have View All Profiles. (Profile names are on a need-to-know basis)
- I know Apex enforces sharing by default, and that from API version 67.0, database operations run in user mode by default; older code keeps the old behavior. (Code runs as the user, by default)
- I know the retirement of permissions on profiles was cancelled, and that Salesforce still recommends a permission-set-led model. (Profiles stay, but permission sets lead)
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.
- An architect is building for today and also thinking about tomorrow.
- Ask the failure question: if this goes wrong, how would we know?
- The invisible unlocked door is no longer invisible, because AI can find it.
- Grant only the bare minimum, to the fewest people, and plan how access is revoked, not only granted.
- It’s easier to open up later than to lock it down later.
- Become a great builder first. In any org or sandbox, start at Setup, then Sharing Settings.
- Code should be saved for the use cases that go beyond the capabilities.
- Look at the top of each branch: whoever is there sees everything below. No one person’s login should open the whole company.
- When one object serves two audiences with different needs to know, split it.
- A share proved only for the person who should see it is half tested.
- Treat a retirement date as a plan, not a promise.
Words to Know
Section titled “Words to Know”| Term | In one line |
|---|---|
| Authentication | Getting in: proving who you are |
| Authorization | What you can do once you’re in |
| Structural security | The offices: which apps, tabs, objects and fields a user can see and use |
| Record access | The file cabinets: which records of an object a user can see, and what they can do with each |
| Most restrictive wins | Where object access and record access meet, the user gets the tighter of the two |
| View All Records / Modify All Records | Object permissions that give every record of that object, whatever the sharing (often still called View All and Modify All) |
| View All Fields | An object permission that shows every field on that object, whatever the field permissions, while respecting sharing |
| Least privilege | Only the access the job requires, and nothing more |
| Need to know | Does this person need to see this record? |
| Defense in depth | No single control carries the whole weight |
| Failing securely | When something is missing or wrong, the result is less access, not more |
| Data bleed | Data leaking through a path nobody designed, such as global search or an attached file |
| Profile filtering | Users see only their own profile name unless they have View All Profiles |
| User mode | Code that enforces the running user’s sharing, object and field permissions |
Check Yourself
Section titled “Check Yourself”Short scenarios in the style of the course. Decide your answer before you open it.
1. A user's permission set gives Edit on opportunities. The opportunity default is Read-Only, and she doesn't own the record. Can she edit it?
No. She gets Read, the more restrictive of the two: the permission set opened the office for editing, but the record’s cabinet is open for reading only. Reread Where they meet: the most restrictive wins.
2. A sharing rule isn't giving a manager the accounts she needs, so someone suggests View All on Account. What's the problem?
View All Records ignores sharing for every account, not only the ones she needs. Granted as a fix, it quietly unlocks every cabinet of that object for that user. Build the sharing she needs instead; if she truly needs every account, make it a design decision you can explain. Reread Failing securely: when in doubt, the door stays shut and The one exception: View All and Modify All.
3. A complaint case says the CEO has been harassing the caller. A service agent owns it. Who can see it, and what would you change?
Everyone above the owner in the role hierarchy, the CEO included, and for Case you can’t turn that off. Own confidential cases in a branch that starts at the top of the hierarchy, such as an HR Confidential role, or by a user with no role. Reread Need to know: the CEO and the complaint.
4. Only an account's assigned rep may see a sensitive field. The team uses Dynamic Forms to show it only to that rep. Is the field secure?
No. To show the field at all, every user needs field access, and then it can reach list views, reports, dashboards and global search. Remove the field access, and show the value to the assigned rep through a small component built for that purpose. Reread Defense in depth: hiding isn’t securing.
5. You set accounts to Private and shared one account with a user, who can now see it. Is the share tested?
Half tested. Also log in as a user it isn’t shared with and confirm they still can’t see it, and check the share table for the row and its reason. Reread Prove it: three users.
6. A delegated admin can no longer see other users' profile names after a release. Turn profile filtering off?
No. Give View All Profiles to the people whose job needs it, such as that delegated admin, and leave the setting on for everyone else. Reread Profile names are on a need-to-know basis.
Explore
Section titled “Explore”- Salesforce Certified Platform Sharing and Visibility 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.