Object and Field Security: What Users Can Touch

Tämä sisältö ei ole vielä saatavilla valitsemallasi kielellä.

Chapter 4 of Securing Salesforce: Sharing and Visibility, Part 1: The Front Door and the Offices. New to the course? Start with chapter 1.

Here’s the question for this chapter. You’ve let someone in the front door, and you’ve given them a profile and their permission sets. Now they walk down the hall. Which offices can they go into, and what can they touch once they’re inside?

In chapter 1’s building, chapter 2 was the front door and chapter 3 built the access. This chapter is the offices themselves: the objects, and the drawers of information on each record, the fields. I call it structural security: can I see this, or can I not? Which records you can open inside each office is the file cabinets, and that starts in the next chapter.

The ideas in this chapter

Object permissions open the office, not the cabinets. Read, Create, Edit and Delete respect sharing. An object permission is a ceiling, not a grant of records.
Two open every cabinet. View All Records and Modify All Records override sharing. They’re a design decision, written down with a reason, never a fix under a deadline.
View All Fields is just as powerful. It shows every field on the records a user can see, regardless of field permissions.
The detail pulls on the master. In a master-detail relationship, some permissions on the detail turn on permissions on the master when you save.
Field-level security is your base level control. A sensitive field starts on no profile but the admin’s, and is granted Read, or Read and Edit, in a permission set.
The team that adds the field decides. When a subsystem’s team adds a field, it decides in the same release which of its permission sets gets it.
It reaches everywhere. Field-level security goes with the data: list views, reports, search, the API. Know what can get around it.
Hiding isn’t securing. Page layouts, visibility rules and Dynamic Forms control the screen. “Hidden fields are for user convenience, not for field-level security.”
Data bleeds. Once a user has a field, it shows up in every other way into the org. The record’s name and its files aren’t covered by field-level security at all.
When confidential data needs its own object. If the confidential part comes with files, or words that end up in names, give it its own object.
Some requirements can’t be met out of the box. Take them apart layer by layer, and expect a hybrid: field-level security, then the page, then code or the data model.
Find it, then prove it. Classify the sensitive fields, check them on paper, then prove the positive and the negative with three users.

The picture

Here’s the picture the chapter turns on. One field permission reaches every place the data goes. Hiding a field on a page doesn’t.

Click to enlarge

The rule I give every class: before you hide a field, ask whether this person should ever see this value. If the answer is no, that’s field-level security. Take the field away. A visibility rule is convenience, on top of field-level security, never instead of it.

The path through this chapter

Six modules, each standing on its own.

Object Permissions: Create, Read, Edit, Delete. Offices, not file cabinets; the seven object permissions and which ones override sharing; View All Fields; the detail and its master; and choosing object permissions for view, normal, power and admin.
Field-Level Security: Read and Edit, in Permission Sets. Paul and the Security Status field; Read, or Read and Edit; why it reaches everywhere; what can get around it; and checking who can see a field.
Hiding Isn’t Securing: Layouts and Dynamic Forms. Three ways to hide a field on the screen; Paul’s airport page and the list view I build next; the traps on the page itself; and the two questions to ask before you hide a field.
Data Bleed: List Views, Reports, Search and Files. Where a granted field shows up; the name you can’t hide; the files on the record; the day I found the reviews; and when confidential data needs its own object.
Layer by Layer: The Assigned-Rep Field. A requirement out of the box can’t meet: only the assigned rep sees one field. Field-level security, the page, an LWC and its Apex, or a record of its own; display and edit; and the hybrid that holds.
Checking a Field: Who Can See It, and Proving It. Data classification as the list to check; the paper answer; three users; Log In as Another User and its limit; and runAs in Apex tests.

The order is the order you’d secure a field in. Open the office, grant the field, keep the page in its place, find where the data bleeds, work the hard cases, and then prove it.

Click to enlarge

Then check what stuck with the study guide.

What an architect decides here

For each object, which object permissions each level of its subsystem’s permission sets carries, starting from Read.
Who, if anyone, gets View All Records, Modify All Records or View All Fields, and the written reason.
Which fields are sensitive, how they’re classified, and that each one starts with no access on any profile but the admin’s.
For each sensitive field, which permission sets give Read and which give Read and Edit, decided by the team that adds it.
That no sensitive field is protected only by a page layout or a visibility rule.
How sensitive records are named, which objects can have files attached, and when confidential data gets its own object.
For a requirement out of the box can’t meet, which layer is added next and why, and whether the rule lives in code or in sharing.
Who reviews code that runs in system mode, and that it’s there on purpose.
The three users for each sensitive field, and the runAs tests for code that shows a locked-down field.

Beyond the exam: what AI changes. An agent doesn’t read your page layout. It works through actions and the API, so for an agent every visibility rule is invisible: only field-level security and sharing count. And an agent asked a broad question searches everything it can reach, so whatever bleeds to a user bleeds to an agent running as that user, in seconds. Test the agent like a fourth user: it should fail the same negative test. Chapter 20 goes further.

Explore

Each module lists its own sources, each checked 2026-11-01. Two to start with:

Object Permissions (opens in a new tab), Salesforce Help (checked 2026-11-01)
Dynamic Forms Tips and Considerations (opens in a new tab), Salesforce Help (checked 2026-11-01)

Next: Steve’s 25 Ways to Share a Record: The Map