Salesforce security is the topic where I watch confident beginners suddenly go quiet. Profiles, roles, permission sets, org-wide defaults, sharing rules. The words blur together, and it feels like there are five overlapping systems all fighting to control the same thing. There is good news, though. Underneath the jargon sits one clean idea, and once you have it, the whole subject organizes itself. Let me give you that idea first, then fill in the pieces around it.
The one sentence that unlocks everything
Salesforce security answers two completely different questions, and beginners get lost by treating them as one.
Profiles and permission sets control what you CAN DO. Roles and sharing control what you can SEE. Keep those two questions separate in your mind and the entire security model falls into place.
“What can I do” is about abilities. Can I create Accounts? Can I delete Cases? Can I edit this field? Can I run reports? “What can I see” is about which specific records appear for me. Can I see your accounts, or only my own? These are independent. You might have full permission to edit Opportunities, yet only be allowed to see the handful that belong to you. Hold these two questions apart and you are most of the way there.
Profiles: the baseline of what you can do
A profile is the foundation of a user’s permissions. Every user has exactly one profile, and it sets the baseline for what that user is able to do across the org. Which objects they can create or edit, which fields they can see, which apps and tabs appear, and a long list of system settings.
Think of a profile as the standard-issue toolkit handed to a category of employee. A “Sales User” profile, a “Support Agent” profile, a “Read Only” profile. It establishes the default abilities for everyone in that group. Because each user gets only one, the profile is the broad, shared starting point.
Permission sets: targeted add-ons
Here is where older orgs used to go wrong. People would clone a profile every time one person needed one extra ability, and soon they had dozens of nearly identical profiles to maintain. Painful.
A permission set fixes this elegantly. It is a small bundle of additional permissions you grant on top of a profile, to specific users who need them. Crucially, a user can have many permission sets, but only one profile.
So the modern, sane pattern is: keep profiles lean as the baseline, then layer permission sets on for the extras. One sales rep also needs to manage Contracts? Do not build a whole new profile. Give them a “Contract Management” permission set. Five people across three different profiles all need a special export ability? One permission set, assigned to all five. Permission sets only ever add abilities, never take them away, which makes them safe and easy to reason about.
The everyday picture: the profile is the basic uniform everyone in a role wears, and permission sets are the extra badges you pin on individuals who have earned a specific responsibility.
Roles: who can see whose records
Now we switch from “can do” to “can see.” This is where roles and org-wide defaults live, and where beginners most need to slow down.
By default, Salesforce can be quite private. Org-wide defaults (often called OWD) set the baseline visibility for each object. The most restrictive common setting is Private, meaning you can only see records you own. There is also Public Read Only and Public Read/Write, which open records up to everyone. The org-wide default is the floor. It is the most locked-down the records will ever be, and everything else only opens visibility further, never tightens it.
But pure privacy is rarely what a business wants, because managers need to see their team’s records. That is what the role hierarchy provides. Roles arrange users in a tree that usually mirrors the org chart. The key behavior is simple and powerful: people higher in the hierarchy can see the records owned by people below them. A sales manager sees their reps’ opportunities, and the VP above sees the manager’s whole branch, without anyone sharing things by hand.
So the visibility story reads like this: org-wide defaults lock things down to a sensible floor, and then the role hierarchy opens upward access along management lines. (There are also sharing rules for more specific cases, but you can save those for later.)
Walking through a real example
Picture a sales rep named Dana.
- Dana’s profile says she can create and edit Opportunities. That is what she can do.
- A permission set also lets Dana manage Contracts, a responsibility her teammates lack. An extra ability, added on top.
- The org-wide default on Opportunity is Private, so by default Dana sees only her own. That is what she can see.
- Because of the role hierarchy, Dana’s manager can see Dana’s opportunities, even though they belong to Dana.
Notice how cleanly the two questions stayed separate. Her abilities came from profile plus permission sets. Her visibility came from org-wide defaults plus the role hierarchy. Two systems, two jobs, no overlap.
I find it helps to picture a building. The “can do” side is the set of keys you carry, which doors your keycard opens. The “can see” side is which rooms have windows you are allowed to look through. A person might hold a key to edit a room they cannot even see into yet, and that is fine, because keys and windows are simply different things.
Your next step
You now hold the mental model that makes Salesforce security approachable: profiles and permission sets decide what you can do, roles and org-wide defaults decide what you can see. Carry those two questions separately and the rest is detail.
Since security is always applied to your data structure, it helps to be solid on that structure. Revisit The Salesforce Object Model to see what these permissions are protecting, and Standard vs Custom Objects to understand the objects you will be securing. The full path is in Foundations.