What is the difference between Salesforce roles and permission sets?

Permission sets expand what a user can do by adding task based permissions across objects, fields, apps, and related settings. Roles determine what a user can see by controlling record and folder access in a hierarchy. In practice, permission sets are used for flexible exceptions, while roles provide structured visibility aligned to data access needs.

How Salesforce roles shape what a user can see

Roles are about record visibility. In Salesforce, they sit in a hierarchy that determines which records a user can access through ownership, sharing, and upward visibility rules. That makes roles the right tool when the question is, “Who should see which accounts, opportunities, cases, or folders?” rather than “What functions can this user perform?”

Because roles are tied to visibility and not task capability, they are usually best used to reflect reporting structure or data access boundaries. A role can widen or narrow what a user sees without changing the user’s underlying object permissions, field permissions, or app access. That distinction matters when organisations confuse “can access the record” with “can work on the record.”

For teams trying to avoid overexposure, the practical question is whether visibility should follow hierarchy, geography, business unit, or another record-sharing model. If the answer is yes, roles are the control that expresses that structure. If the answer is no, overusing roles can create artificial hierarchy changes just to solve a permissions problem, which is usually the wrong layer of control.

How permission sets expand what a user can do

Permission sets add capability. They grant extra object permissions, field permissions, app access, system permissions, and other task-based entitlements without changing the user’s base role. That makes them the preferred mechanism for exceptions, temporary needs, and specialized tasks where you want to avoid changing the user’s role or creating a new profile.

In practice, permission sets are often the cleaner answer when someone needs access to a specific app, a reporting feature, or a limited administrative function. They are additive, so they work well for least-privilege design: start with a narrow baseline and add only the permissions required for the job. The model scales better than proliferating custom roles for every exception.

That flexibility also creates a governance requirement. Permission sets can accumulate over time, so administrators need to know which permissions are bundled together, which users have been granted unusual capabilities, and whether an exception is still needed. A permission set is useful precisely because it is easier to grant than a role change, which also makes it easier to let exceptions linger.

Why the two controls are complementary, not interchangeable

Roles and permission sets answer different questions. Roles decide visibility across records and folders, while permission sets decide whether a user can perform actions on data, objects, and apps. In a well-designed Salesforce environment, roles shape the data access model and permission sets handle functional exceptions, so you do not have to overload one control to solve the other control’s job.

The cleanest mental model is: use roles for “what can I see?” and permission sets for “what can I do?” That separation reduces accidental privilege inflation and makes access reviews easier because reviewers can assess data visibility separately from task authority. It also helps when troubleshooting, because a user who cannot see a record may be missing role-based access even if they have every needed permission set.

For practitioners, the main design risk is mixing these layers. If a team keeps adding permission sets to compensate for poor role design, or keeps reshaping roles to grant task access, the access model becomes harder to explain, harder to audit, and more likely to produce unexpected exposure. Good Salesforce access design keeps hierarchy-based visibility and task-based access clearly separated.

Risk and Threat Considerations

Salesforce access failures usually come from overexposure, not from the control names themselves. Over-broad roles can reveal more records than intended, while over-broad permission sets can allow users to edit, export, or administer data beyond their normal job function. In combination, those mistakes can create both confidentiality exposure and manipulation risk.

Failure mechanism: Misaligned roles expand record visibility, and unchecked permission sets expand functional authority, so a user can either see too much or do too much, especially when exceptions are granted without periodic review.

Impact: The result can be unauthorized access to customer, sales, or support data, unintended changes to records or configuration, and harder incident investigations because access is spread across layered entitlements rather than one obvious grant.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	AC-2 — Account Management	Roles and permission sets govern who gets what access.
	AC-6 — Least Privilege	Permission sets should add only needed task access and not widen baseline rights.
	AC-3 — Access Enforcement	Roles enforce record visibility while permission sets enforce functional access.
Recommendation — Review role assignments and permission-set grants as part of account management. Grant only the minimum permissions needed for each job function. Enforce access decisions at the right layer for visibility and capability.
NIST CSF 2.0	PR.AA-05 — Identity Management, Authentication, and Access Control	Salesforce access must separate user visibility from user capability.
Recommendation — Align access control design with the specific data and task needs.
ISO/IEC 27001:2022	A.5.15 — Access control	The distinction between visibility and capability is a core access-control design issue.
Recommendation — Define and enforce access rules separately for visibility and action rights.

Practitioner Guidance

What to prioritise: Treat role design as your visibility model and permission sets as your exception model. If you cannot explain why a user needs a role change versus a permission set, the access decision is probably not specific enough.

What to verify: Check whether the user’s problem is record visibility, field or object capability, or both. If it is only a task requirement, add a permission set rather than widening role access. If it is a visibility issue, fix the role or sharing model instead of stacking more permissions.

Common mistake: Using permission sets to compensate for a badly designed role hierarchy, or using roles to grant operational capabilities. That shortcut makes review harder and increases the chance of silent over-permissioning.

Practitioner takeaway: The safest Salesforce model is usually a narrow role for record visibility plus targeted permission sets for task access, with exceptions reviewed as exceptions rather than treated as permanent architecture.