The Salesforce Security Model: Profiles, Permission Sets, Roles
By the end of this lesson, you'll be able to:
- Explain what a Profile controls, in plain terms
- Explain how a Permission Set differs from a Profile
- Explain what a Role Hierarchy affects that Profiles and Permission Sets do not
Prerequisites: "Relationships, Conceptually: Lookup vs Master-Detail"
Why this belongs in a programming course
You might be wondering why a security-model lesson shows up before you've written a single trigger. The answer: everything Apex does happens as some user, and Salesforce's security rules apply to Apex code just as much as to a person clicking around — Module "Apex Security" spends an entire module on with sharing, field-level security, and CRUD checks, none of which make sense without knowing what a Profile or Permission Set even is. This lesson is that foundation.
Profile: your one baseline
Every Salesforce user has exactly one Profile. It's the baseline: which objects you can see at all, which fields, whether you can create/edit/delete records, which apps and tabs are visible. Think of it as your job title's default toolkit — a "Sales Rep" profile and a "Support Agent" profile would reasonably see very different things.
Permission Sets: stackable extras
A Permission Set grants additional permissions on top of a user's Profile — and a user can have as many Permission Sets as needed. This is the modern, flexible way to say "this one Support Agent also needs temporary access to Billing records" without having to create an entirely new Profile just for that one exception.
Role Hierarchy: who can see whose records
Profiles and Permission Sets control object and field access. Neither controls "can Sarah see the specific Account record that John owns?" — that's what the Role Hierarchy and sharing rules govern. In general, someone higher up the role hierarchy (a manager) can see records owned by people below them (their reports) — mirroring an org chart.
Putting it together
Profile -> What CAN this user do at all? (baseline, one per user)
Permission Set -> What EXTRA can this user do? (stackable, many per user)
Role Hierarchy -> WHOSE records can this user see? (org-chart-based visibility)All three together answer: what a specific user, in a specific role, is allowed to see and do — and this exact framing is what with sharing (Module "Apex Security") respects or bypasses in Apex code.
Exercise
A Healthcare organization has a 'Nurse' profile that normally can't edit billing records, but one specific nurse temporarily needs to fix a billing error. What's the right tool: change her Profile, or something else? Explain.
Show hint
Think about whether this is a permanent, role-wide change or a temporary, individual one.
The Salesforce Security Model: Profiles, Permission Sets, Roles Quiz
My Notes
Log in to keep private notes on this lesson.
Questions about this lesson
No questions yet — be the first to ask.
Log in to ask a question about this lesson.
Summary
Profiles set a user's baseline permissions (one per user), Permission Sets add extra permissions on top (as many as needed, stackable), and the Role Hierarchy controls which records a user can see based on who reports to whom — three different, complementary layers, and you'll need this vocabulary before Module "Apex Security" makes any sense.