The Building, the Offices and the File Cabinets

Module 2 of 4 in the chapter Thinking Like a Security Architect, chapter 1 of Securing Salesforce: Sharing and Visibility. Each module stands on its own.

The question this module answers: Why does Salesforce have separate controls for getting in, for objects and fields, and for records, and what happens where they meet?

Here’s a situation you’ll meet in almost every org. A user’s permission set gives her Edit on opportunities. She opens an opportunity, and there’s no way to edit it. Her permission set says Edit. So what happened?

Nothing is broken. She’s just run into two different sets of controls, and they disagree. To see why, I use a building.

Click to enlarge

The front door

The first set of controls is the front door. Before anything else, the building has to know who you are. That’s authentication: your username and password, your second factor, the IP ranges and hours you’re allowed to log in from. I consider authentication finished when the user has a valid session and can start making requests. From that moment on, everything is authorization: what can this person do?

The front door has its own chapter, The Front Door: Logging In to Salesforce, so here I’ll only say this: getting in tells you nothing about what someone can see once they’re inside. Those are separate decisions, made with separate tools.

Click to enlarge

The offices: structural security

Once you’re in the building, you’re not allowed everywhere. You’re allowed onto the first floor and the second floor. You’re allowed into the accounting office, but you’re not allowed into the HR office.

In Salesforce, that’s what I call structural security: the structure of the app. Which apps do you see? Which tabs? Which objects, and which fields on them? Which reports, page layouts and Lightning page assignments, which experience pages? Can you read, create, edit or delete this kind of data at all? To me, structural security comes down to two questions: can you see an object, and can you see a field?

The tools for the offices are profiles, permission sets and permission set groups, along with the places those settings get assigned from: the App Manager, tabs, the Lightning App Builder, report types and the Object Manager. Everything started on the profile, years ago. Today, more and more of it moves to permission sets, and the next chapters show why.

Notice what structural security doesn’t say. It says you may work with accounts. It doesn’t say which accounts.

Click to enlarge

The file cabinets: record access

So now you’ve walked into the HR office. You’re allowed to be there. But all the file cabinets are locked. You say, “I need to go pull somebody’s file,” and they ask you, “Why do you get their file?”

Just because you made it into the HR office doesn’t mean you should see every file. Just because you made it into the accounting office doesn’t mean you should see every file either. That’s record access: of all the records of an object you’re allowed to work with, which ones can you see, and what can you do with each one?

Record access is a completely different set of mechanisms from the offices. The organization-wide defaults set how locked the cabinets are to begin with. Then the role hierarchy, public groups, sharing rules, manual shares, teams, territories, programmatic sharing and more each unlock particular cabinets for particular people. Many of them work by writing rows to a share table that sits behind the object, recording who has access to which record and why, though not every mechanism uses one. I organize them as Steve’s 25 ways to share a record. The 25 ways give you a comprehensive view across the spectrum of record-sharing capabilities. They aren’t a list of every setting or sub-mechanism that can affect a record, or a field, and the count has grown before: it was 17 when I first made a video about it. Chapter 5 lays out the whole map before Parts 2 and 3 walk through the ways one at a time.

One thing record access assumes: you already have the office. Sharing a record with someone who has no access to the object doesn’t let them in. The record mechanisms only decide which files in the room you can open.

Click to enlarge

Where they meet: the most restrictive wins

Now back to our user with Edit on opportunities.

When the offices and the file cabinets overlap, Salesforce doesn’t add them together. The most restrictive one wins. If the profile or permission set says Edit and the record is shared with you as Read Only, you get Read. And it works the other way too: if the record is shared with you as Read/Write but your profile and permission sets only give you Read on the object, you get Read. It’s not additive. Being generous in one layer doesn’t make up for the other.

Salesforce’s own sharing guide uses almost exactly this example. Users with object permissions to read and edit opportunities, in an org where the organization-wide default is Read-Only, “can read all opportunity records, but can’t edit any unless they own the record or are granted other permissions” (Platform Sharing Architecture (opens in a new tab), checked 2026-11-01).

That’s our user. Her permission set opened the office for editing. The organization-wide default left that opportunity’s cabinet open for reading only. She gets the more restrictive of the two.

Click to enlarge

The one exception: View All and Modify All

There’s one place where the office does open the cabinets. On each object, the View All Records and Modify All Records permissions, which many people still call View All and Modify All, give access to every record of that object, whatever the sharing says. In Salesforce’s words, they “ignore sharing rules and settings.” This is the one time a structural permission overrides a restrictive sharing model. Above those sit the View All Data and Modify All Data permissions, which open every record of every object in the org.

Notice what they open: the records, not the fields. Salesforce is clear that View All Data, Modify All Data, View All Records and Modify All Records “don’t override field-level security.” Users still need field permissions to see each field, or a separate object permission, View All Fields, which lets them see every field on that object “regardless of assigned field permissions” while still respecting sharing (“View All” and “Modify All” Permissions Overview (opens in a new tab) and Object Permissions (opens in a new tab), Salesforce Help, both checked 2026-11-01). So the cabinets and the fields are still two different locks, even here.

Salesforce calls the per-object permissions “often preferable alternatives” to View All Data and Modify All Data, and I agree: if someone really needs every record of one object, give them that one object, not the whole org. But treat both like the master key to the building. A View All granted to make a sharing problem go away has quietly unlocked every cabinet of that object for that user, and that’s exactly the kind of door module 1 warned about. If you’re granting it, it should be a design decision you can explain, not a fix.

Why keep the three apart

I teach these as three layers because, in a real org, every access question is really a question about one of them.

When someone can’t see a record, or can see one they shouldn’t, ask in order. Did they get in, and how? What office are they in: do they have the object and the field? And which cabinets are open to them: how is this record shared with them, or why isn’t it? Most confusing access problems become simple once you know which layer you’re in. And when you design, the same order keeps you honest: lock the front door, give each person only the offices they need, and then open only the cabinets they need.

That last part matters more every year. The users coming through the door now include integration users and agents, and each one is placed in the same building, with the same three layers. Part 3 of this course has a chapter on what agents can see.

What an architect decides here

• Which layer a requirement belongs to: getting in, the object and field, or the record.
• How locked the cabinets start (the organization-wide default) for each object, before any sharing is added.
• Where a user’s object access and record access must both line up for them to do their job, remembering the most restrictive wins.
• Whether anyone truly needs View All or Modify All on an object, and never View All Data or Modify All Data as a shortcut.

Explore

• Platform Sharing Architecture (opens in a new tab), Salesforce Architects (checked 2026-11-01)
• Object Permissions (opens in a new tab) and “View All” and “Modify All” Permissions Overview (opens in a new tab), Salesforce Help (checked 2026-11-01)