Study guide
This content is not available in your language yet.
Study guide for chapter 4 of the Securing Salesforce: Sharing and Visibility course. Read the six 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 carries three of the Sharing and Visibility exam’s objectives: recommending object permissions for a set of users, recommending field permissions for a set of users, and hiding data at the user-interface level. Chapter 3 began the first one with permission sets and groups; this chapter finishes it with the permissions themselves. Their section, Permissions to Standard Objects, Custom Objects, and Fields, is 27% of the exam. The exam guide aligns to Winter ‘23, so the changes since then are in their own list at the end.
For the Exam
Section titled “For the Exam”Tick them off as you go. Each one links to where it’s taught.
Object permissions (supports OBJ-1)
- I know the seven object permissions and how they build on each other: Create includes Read, Edit includes Read, Delete includes Read and Edit, and Create doesn’t include Edit. (The seven object permissions)
- I know Read, Create, Edit and Delete respect sharing: they open the office, not the file cabinets. (Most of them open the office)
- I know View All Records and Modify All Records override sharing, and don’t override field-level security. (The two that open every cabinet)
- I know View All Fields shows every field on the records a user can see, regardless of field permissions, and needs at least Read. (View All Fields)
- I know some permissions on a master-detail detail turn on permissions on the master when you save in Setup, and that through the API you fix those dependencies yourself. (The detail and its master)
- I can map object permissions to levels of access, such as view, normal, power and admin, in each subsystem’s permission sets. (Choosing object permissions)
Field-level security (supports OBJ-2)
- I start a sensitive field on no profile but the admin’s, and grant it in a permission set. (Paul and the Security Status field)
- I know the choices for a field: Read, or Read and Edit, with no access as the default for anything sensitive. (Read, or Read and Edit)
- I know field-level security reaches list views, reports, search results, related lists, email and mail merge templates, custom links and the API, and overrides less-restrictive page layout and search layout settings. (It reaches everywhere)
- I know what can get around it: some user permissions such as Edit Read Only Fields, a universally required field, View All Fields, and code in system mode. (What can get around it)
- I know View Field Accessibility can’t check access for permission sets, and use the Field Access Summary instead. (Checking who can see a field)
Hiding on the screen (supports OBJ-3)
- I know the three ways to hide a field on the screen: page layouts, visibility rules on Lightning pages, and Dynamic Forms. (Three ways to hide a field)
- I know a visibility rule can only hide a field the user already has, and that “Hidden fields are for user convenience, not for field-level security.” (The list view I build next)
- I know the traps on the page: a hidden required field can be saved empty, a hidden field’s edits aren’t saved, Dynamic Forms rules are desktop only unless Dynamic Forms on Mobile is on, dependent picklists ignore visibility rules, and section rules wait for a save. (Traps on the page itself)
- I can ask the two questions: should this person ever see this value, and should they see it here, now? (So what are they for?)
Data bleed (supports OBJ-2 and OBJ-3)
- I know a granted field shows up in list views, reports and dashboards, global search and the API. (Where a granted field shows up)
- I know the record name goes wherever the record goes, and when an auto-numbered name is safer. (The name you can’t hide)
- I know Require permission to view record names in lookup fields, and what it changes. (The name you can’t hide)
- I know files on a record follow the record, not the fields: with Set by Record, read-only access to the record gives Viewer access to its files. (The files on the record)
- I know when confidential data, especially with documents, needs its own object. (When confidential data needs its own object)
A requirement out of the box can’t meet (supports OBJ-2 and OBJ-3)
Test knowledge. The assigned-rep pattern: one sensitive field, visible only to one user, on a record other users can see. It’s a pattern architects meet again and again, in real orgs and on the architect journey. A likely area, not a known question.
- I know why field-level security alone can’t show a field to only the assigned rep, and why a visibility filter leaks. (Layer 1, Layer 2)
- I know the locked-down answer: no field-level security for reps, and an LWC whose Apex reads the field in system mode on purpose and checks the user. (Layer 3, in code)
- I know display is easy and edit is the work: a separate edit LWC whose Apex checks the user again before it saves. (Display is easy; edit is the work)
- I know the modeling answer: a lookup child with a Private default and the assigned rep as owner works; a master-detail child, Controlled by Parent, doesn’t. (Layer 3, in the data model)
Checking a field (supports OBJ-2)
- I know the data classification fields, Data Sensitivity Level and Compliance Categorization, and that they’re a list to check, not a lock. (First, know which fields are sensitive)
- I test a field with three users: the admin, someone who should see it, someone who shouldn’t. (Prove it: three users)
- I know Log In as Another User needs Modify All Data and login access, and skips login flows. (Log in as another user)
- I know
System.runAsenforces the user’s sharing, object and field permissions, and works only in test methods. (Prove it in code: run as)
What changed since the exam’s Winter ‘23 alignment (dated, beyond the exam today)
- I know the Field Access Summary (Summer ‘26) shows one field’s access across all profiles, permission sets and permission set groups. (Checking who can see a field)
- I know that since Summer ‘26, Apex database operations in code saved at API version 67.0 or later run in user mode by default, so system mode has to be asked for on purpose. (Layer 3, in code)
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 object permission is a ceiling, not a grant of records. Which records is still the file cabinets.
- View All Records, Modify All Records and View All Fields need a written reason. Never a fix under a deadline.
- A new field isn’t finished until its access is decided, by the team that adds it, in the same release.
- Never make a sensitive field universally required.
- Hide for convenience, secure with field-level security. Never one instead of the other.
- Enforce required values with validation rules, not the page.
- Test the page as each kind of user, on each device.
- Keep sensitive words out of record names.
- Ask who can see the record before you let people attach files to it.
- Search as a restricted user before go-live, and write down what comes back.
- When out of the box can’t meet a requirement, add one layer at a time, stop when it holds, and write down why each layer is there.
- Every system-mode query is there on purpose, and someone reviews it.
- Prove the negative. A field checked only as the person who should see it is half tested.
Words to Know
Section titled “Words to Know”| Term | In one line |
|---|---|
| Object permission | What a user can do with records of an object: Read, Create, Edit, Delete and more |
| View All Records / Modify All Records | Object permissions that open every record of an object, regardless of sharing |
| View All Fields | An object permission that shows every field on the records a user can see |
| Field-level security | Read, or Read and Edit, on one field, everywhere the data goes |
| Edit Read Only Fields | A user permission that edits read-only fields regardless of other settings |
| Page layout | Which fields appear on detail and edit pages, by profile and record type |
| Visibility rule | A filter that shows or hides a component on a Lightning page |
| Dynamic Forms | Visibility rules on single fields and field sections |
| Data bleed | A granted field showing up in list views, reports, search and the API |
| Record name | The name shown in page layouts, list views, related lists and search results |
| Set by Record | File sharing that gives users access to a record’s files based on their access to the record |
| System mode | Code that runs without the user’s object, field and sharing access; asked for on purpose since Summer ‘26 |
| Controlled by Parent | The default for a detail record: access follows the master record |
| Data Sensitivity Level | A field’s classification, from Public to MissionCritical |
System.runAs | Runs part of an Apex test as another user |
Check Yourself
Section titled “Check Yourself”Short scenarios in the style of the course. Decide your answer before you open it.
1. A support user can't see some cases, the sharing isn't built yet, and someone suggests View All Records on Case to close the ticket. What's wrong with that?
View All Records overrides sharing: the user sees every case, not just the ones they need. It’s a design decision, written down with a reason, never a fix under a deadline. Build the sharing that grants exactly the records the job needs. Reread The two that open every cabinet.
2. You give a permission set View All Records on Runway, a detail of Airport, and save. What else changed?
Setup also turned on View All Records on Airport, because the master gets View All Records when the detail has it. If you meant to open only runways, you opened every airport too. Reread The detail and its master.
3. A new Security Status field should be seen by pilots and changed by the admins only. How do you set it up?
Leave it off every profile except System Administrator, which gets Read and Edit. Give Read in the pilots’ View Airports permission set. Then check the Field Access Summary: two lines, and anything else is a question. Reread Paul and the Security Status field.
4. A Dynamic Forms filter hides a field on small airports. A user with Read on the field builds a list view. What do they see?
Every airport’s value, small airports included. A visibility rule only hides the field on the page; the user still has the field in list views, reports, search and the API. Reread The list view I build next.
5. A field is required in the Lightning App Builder and hidden by a visibility rule. A user saves the record. What happens?
The record saves without the field, because a hidden required field isn’t enforced. If the value must be filled in, use a validation rule. Reread Traps on the page itself.
6. HR's detail fields are protected with field-level security, but staff attach review documents to employee records that everyone can see. Is the data safe?
No. Files follow the record, not the fields: anyone who can see the record can view, download and share what’s attached. Give the confidential part its own object, with its own access and its own files. Reread The files on the record.
7. Only the assigned rep may see an account's Special Access field, and all reps still need the account. Someone proposes a master-detail child object for Special Access. Will it work?
No. A detail record is Controlled by Parent, so every rep who can see the account sees it. A lookup child with a Private default and the assigned rep as owner works, or no field-level security for reps and an LWC whose Apex shows the field only to the assigned rep. Reread Layer 3, in the data model.
8. You tested a sensitive field as a user who should see it, and it's there. Are you done?
No. That’s the positive. Test as a user who shouldn’t see it too, on the page, in a list view, in a report and in search: the negative. With the admin, that’s three users. Reread Prove it: three users.
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 an exam.