Four Principles, the Salesforce Way

Module 3 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: What do least privilege, need to know, defense in depth and failing securely look like in a real Salesforce org?

Let me ask you a question I ask every class. A case comes into your complaint system, and it’s owned by a service agent. Who can see that case?

The owner. And everybody above the owner in the hierarchy.

Now, what if the case says the CEO has been harassing me? Does the CEO get to see the case?

Right now, they do.

Grant access using hierarchies sends every record all the way up to the top. And for a standard object like Case, you can’t turn it off: Salesforce’s own words are that the setting “can’t be modified for standard objects”; only for custom objects can you disable it (Controlling Access Using the Role Hierarchy (opens in a new tab), checked 2026-11-01). It doesn’t have to be harassment, either. It can be an HR case that says I got married, or I’m getting divorced, and then the CEO types into global search and finds it. Nobody designed that. It’s what happens when nobody applied the principles.

There are four security principles I want every architect to carry into every design: least privilege, need to know, defense in depth and failing securely. They’re old ideas, much older than Salesforce, and Salesforce’s own exam guide names least privilege, defense in depth and failing securely among the things candidates are likely to need help with. Here’s what each one looks like on the platform.

Least privilege: start from nothing and add

Module 1 made this the mindset of the whole course: grant only the bare minimum, to the fewest people. Here’s what it looks like in Setup.

When you build a new profile, start from the Minimum Access – Salesforce profile and add upward, so you know exactly what you’re adding. If you clone a standard profile instead, you inherit a lot of capabilities, and if they’re not what you want, you’ve just brought in a lot of open doors you haven’t thought about.

The same goes for records. If there’s even one user in your system you need to hide some records from, dial the organization-wide default down to Private and open up from there. It’s easier to open up later than to lock it down later.

Salesforce says the same thing in its own architecture guidance: “Grant the minimum level of access that’s necessary for each user, integration, and automated process to accomplish its purpose. Start with the most restrictive settings—Private organization-wide defaults (OWDs) and minimal permissions—and expand deliberately based on documented business requirements” (Well-Architected: Trust (opens in a new tab), checked 2026-11-01). Notice that it names integrations and automated processes too, not only people.

Need to know: the CEO and the complaint

Least privilege asks how little a person can be given. Need to know asks a sharper question about each piece of data: does this person need to see this?

Back to the CEO. The role hierarchy is a wonderful tool for the normal case: managers see their team’s work. But for confidential records it’s exactly the wrong path, because it always runs upward to whoever sits at the top. So when an org holds confidential data, the first place I look is the top of the hierarchy. Whoever that is gets to see everything owned below them.

To keep a confidential record out of normal visibility, it has to be owned in a branch of the tree that starts at the top of the hierarchy, such as an HR role that isn’t under the CEO, or by a user with no role at all. That’s a fundamental decision, and it has to be made early. For a confidential case object, a confidential patient object, a confidential HR object, you need to ask who the owners will be, which branch they sit in, and what’s at the top of that branch. There are other tools too, such as restriction rules, and Part 3 of this course covers them. But the question comes first: who needs to know?

There’s a second reason not to let everything roll up to one person, and it has nothing to do with complaints. If every record in the company rolls up to the CEO, then the CEO’s login opens the whole company. Their laptop, their phone, their home and their office become the ultimate target: break into that one account, and you’ve gained access to everything. I don’t want any one person’s credentials to be the key to all of the company’s data, however senior they are. Need to know applies at the top of the hierarchy too: give the top what the role needs, not everything by default.

Click to enlarge

Defense in depth: hiding isn’t securing

Defense in depth means no single control carries the whole weight. If one layer is wrong, the next one still protects the data. And on Salesforce, the most common way to get this wrong is to hide something instead of securing it.

Here’s a requirement I’ve met at a client. An account has a sensitive field, and only the assigned rep on that account should see it. Other reps still need to see the account itself. Who can tell me the options?

The first answer is usually a visibility filter: Dynamic Forms, show the field only when the user is the assigned rep. That works on the page. But to show the field at all, you have to give users field-level access to it, even the ones the filter hides it from. And once they have field access, they can add that field to a list view. It shows up in reports, in dashboards, in global search. You can keep it off the screen, but you can’t keep it out of the other ways in. That’s data bleed.

If the field truly has to be locked down, you lock it down: don’t grant the field access at all, and show the value only to the assigned rep through a small component whose code reads it on their behalf, on purpose. That works for display; editing needs its own small component too. It’s more work, and that’s the point: the protection sits in the security layer, not on the page layout.

I learned this one the hard way, while we were building our own system. When I was running a consultancy, we built an employee object to use both for time tracking and for HR. One day during the build, I typed into global search and found myself looking at people’s reviews. They’d been attached to employee records that everyone could see, and an attached file followed its record: if you could see the record, you could see what was attached to it. We quickly split the object: one object for HR, and a separate one that people tracked their time against. Global search and attached files are where data bleed most often shows up.

Then and now. At the time, a file attached to a record was visible by default to everyone who could see the record. The Attachments object did have a Private flag on each attachment, “viewable only by the owner and administrators”, and Salesforce’s documentation described it the same way in 2012 (archived copy, February 2012 (opens in a new tab)). But it was set one file at a time, and nothing in our design set it. The controls have grown since. Today, Salesforce Files attached to records can be set to inherit the record’s sharing (Set File Sharing to Inherit Record Permissions (opens in a new tab)), and a file can be marked Private on Records, so that only its owner sees it on the record (Make a File Private on a Record (opens in a new tab), both checked 2026-11-01). Even then, Salesforce notes that “on private files, file metadata isn’t also private.” Better controls, same lesson: when one object serves two audiences with different needs to know, split it.

Salesforce puts the principle this way: “Design each layer as if the adjacent layers might fail. Remember, Field-level security protects data even when sharing rules are too permissive” (Well-Architected: Trust (opens in a new tab), checked 2026-11-01).

Beyond the exam: code that reads on a user’s behalf. Since Summer ‘26, Apex database operations in code saved at API version 67.0 or later run in user mode by default, enforcing the user’s sharing, object and field permissions. A component that deliberately shows a value the user can’t access must now ask for system mode explicitly, which makes the exception visible in the code. The secure Apex chapter in Part 3 covers it.

Failing securely: when in doubt, the door stays shut

Failing securely means that when something is missing, wrong or broken, the result is less access, not more. The door stays shut.

Salesforce’s core access model is built this way. In its own words, “Core access control is grant-based, which means access is additive, and users need to have it granted at every layer to reach a record” (Well-Architected: Trust (opens in a new tab), checked 2026-11-01). If no one granted it, the user doesn’t have it. A missing permission set fails shut. A Private default with no sharing rule fails shut.

So where do orgs fail open? Almost always in the things we add. An organization-wide default set to Public Read/Write “for now.” A View All granted to make a sharing problem go away. A guest user given more than the public page needs. Code that runs in system mode without anyone deciding it should. Each one is a door left unlocked, and as module 1 said, those doors are no longer invisible, because AI can find them. The architect’s job is to make every one of those a decision someone can explain, not an accident.

Here’s the one I see most. You hit a roadblock. A user needs to get to some records, the proper sharing for them isn’t built yet, and the deadline is today. So someone grants View All Records on the object, and the problem goes away. What you don’t realize are the side effects.

• It’s every record, not the ones they needed. View All Records opens every record of that object, “regardless of sharing settings.” Modify All Records goes further: Salesforce says users can “read, edit, delete, transfer, and approve all records associated with this object” (Object Permissions (opens in a new tab), checked 2026-11-01).
• It can open the parent too. On a detail object in a master-detail relationship, View All Records or Modify All Records needs View All Records on the parent, and Setup turns that on for you when you save. You meant to open one cabinet, and you opened the one above it as well.
• It doesn’t open the fields, and that’s where people get surprised in both directions. It’s easy to assume View All gives you the records and the fields. It doesn’t: these permissions “don’t override field-level security.” But there’s now a separate View All Fields permission, and if someone grants that too, to get past the next roadblock, the user can see every record and every field on that object.

None of that is visible on the screen where the fix was made. The user is happy, the ticket is closed, and the door stays open. The right fix is the one that should have been built: the sharing that grants exactly the records the job needs. If someone really does need every record of an object, that’s a design decision, written down, with an owner, and not a fix made under a deadline.

Prove it: three users

Principles only count if you can prove the model does what you say. My habit, every time I test sharing: three users. One is the administrator. One is a user the record is shared with. One is a user it isn’t shared with.

Set accounts to Private and log in as the second and third users, each in their own browser session. Neither should see the accounts. That’s the null test. Then share one account with the second user. Refresh both: the second user sees it, the third still doesn’t. You’ve proved the positive and the negative. Then look at the account share table and see the row the share created, with its reason. The testing chapter in Part 2 builds on this; for now, remember that a share you’ve only proved for the person who should see it is half tested.

What an architect decides here

• Which profile every new profile starts from, and which organization-wide defaults start Private.
• For each confidential object, who owns its records and what sits at the top of their branch of the role hierarchy, and whether any one login, however senior, would open everything.
• Which sensitive fields must be secured (no field access) rather than hidden on a page, and how those few users will see them.
• Which additions could fail open (public defaults, View All, guest access, system-mode code), and who signs off on each one.
• How the model will be proved, positive and negative, before anyone relies on it.

Explore

• Salesforce Well-Architected: Trust (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)
• Controlling Access Using the Role Hierarchy (opens in a new tab), Salesforce Help (checked 2026-11-01)
• Make a File Private on a Record (opens in a new tab) and Set File Sharing to Inherit Record Permissions (opens in a new tab), Salesforce Help (checked 2026-11-01)
• Attachment (opens in a new tab), Object Reference for the Salesforce Platform, Winter ‘27 (checked 2026-11-01); the same page in February 2012 (opens in a new tab) (Wayback Machine)
• Database Operations Run in User Mode by Default, Not System Mode (opens in a new tab), Salesforce Summer ‘26 release notes (checked 2026-11-01)