Profiles vs. Permission Sets vs. Roles: The Ultimate Salesforce Security Guide

💬 In plain words: A Profile is the base uniform every user wears; everyone has exactly one. Permission Sets are extra badges you pin on top for special access. A Permission Set Group is a ready-made bundle of badges for a job. A Role is different: it doesn't change what you can do, only which records you can see, based on where you sit in the company. Modern rule: keep the profile minimal and give access through badges.

If you're new to Salesforce administration, the security model can feel like a foreign language. Profiles, permission sets, permission set groups, roles: it's easy to mix them up. But knowing how user access works is one of the most important skills for keeping company data safe. This post explains each piece, how they fit together, and how to answer the interview questions that come up most.

Key Points Summary

• Every user has exactly one profile, but can have many permission sets and permission set groups.
• Access is additive: a user gets everything granted by their profile plus all their permission sets and groups.
• The only way to take a permission away inside this model is a muting permission set, and it works only inside its own group.
• Roles don't control what users can do. They control which records users can see.
• Salesforce recommends a permission-set-led model: the "Minimum Access - Salesforce" profile plus Permission Set Groups.

1. Profiles: The Mandatory Baseline

A Profile is required for every user, and each user has exactly one. It sets the ground rules:

• Login Policies: Login hours, login IP ranges, and session settings.
• Defaults: Page layout assignments, default record types, and the default app.
• Permissions: Profiles can still hold object permissions (Read, Create, Edit, Delete, View All, Modify All), field-level security, app access, and system permissions. Best practice is to keep these on permission sets instead.

Where Salesforce is heading: Salesforce once planned to remove permissions from profiles in Spring '26, then cancelled that plan in July 2026. Profiles keep their permissions, but Salesforce still recommends a permission-set-led model.

2. Permission Sets: Add-On Access

Admins used to create a custom profile for every job title. That led to "profile bloat": dozens of nearly identical profiles that were painful to manage. Permission Sets fix this. Each one grants a specific capability on top of the profile, and a user can have many. You can even set an expiration date on an assignment for temporary access.

Real-Life Example: Managing Special Access
50 sales reps share the same minimal profile. Five of them need access to a new financial approval app. Instead of cloning a new profile for those five, you assign them a Financial App Access permission set. Their profile stays clean and untouched.

Licensing note: Some permissions need a Permission Set License (PSL) before you can assign them. Assign the license to the user first, then the permission set.

3. Permission Set Groups and Muting

A Permission Set Group (PSG) bundles several permission sets into one persona, like "Sales Rep" or "Lab Supervisor." Instead of assigning 10 permission sets to a new employee, you assign one group. If a group grants one permission too many for a certain team, add a muting permission set to the group to remove that permission, without changing the permission sets inside it.

🧠 Access is a UNION: Profile (1, baseline) + Permission Sets (additive) + PSGs (bundles). Only MUTING subtracts, and only WITHIN its own group.

Metric	Profile	Permission Set	Perm Set Group
Per User	Exactly 1	Many	Many
Effect	Baseline	Additive	Bundle of sets
Subtract?	No	No	Yes (Muting, inside the group only)
Best For	Login policy, defaults	One capability	A user persona

4. Roles: What You See, Not What You Do

Beginners often confuse roles with profiles. Profiles and permission sets control actions (what you can do with an object). A Role controls record visibility (which records you can see).

The Role Hierarchy is a management tree. If a sales rep owns an Account, their sales manager above them in the hierarchy can see that record too, even if the org-wide default is Private. That way, leaders always see their team's work. A user can have at most one role, and a role is optional.

Common Administrator Mistakes:

• Giving Out System Administrator: Never make someone a full admin just because they need one tool. Use a targeted permission set instead.
• Cloning Profiles Blindly: Cloning standard profiles over and over copies old permission clutter. Start with Minimum Access and build up with permission sets.
• Expecting a Role to Grant Edit Access: An executive role doesn't let someone edit Accounts if their profile and permission sets don't grant Edit. Roles only affect which records are visible.

Security Golden Rule: Keep profiles minimal, use permission sets and groups for every real capability, and keep the role hierarchy aligned with how your company actually manages people.

360 Security Summary Card

• Profile: Exactly one per user. Login policies and defaults; keep permissions here to a minimum.
• Permission Set: Many per user. One specific capability each.
• Permission Set Group: Many per user. A bundle of permission sets for a persona, with optional muting.
• Role: At most one per user. Controls record visibility up the management chain.

Core Q&A

Q: How would you design the permission model for a brand-new enterprise org today?

🎯 Say this first: A minimal profile as the base, and all real access through permission sets, bundled into permission set groups by job function.

A: Start every user on the Minimum Access profile, so the profile holds only what it must (login policies, default layouts). Then build access in small, reusable pieces:

• Small Capabilities: One permission set per capability (for example, "Manage Quotes" or "Run Lab Reports").
• Persona Bundles: Combine permission sets into Permission Set Groups per persona ("Sales Rep," "Lab Supervisor").
• Exceptions: Use muting permission sets for "persona minus one permission" cases instead of cloning whole groups.
• Why It Works: Access is additive, easy to audit, and reusable. Onboarding a new user means assigning one group, and the design follows Salesforce's recommended direction.

Follow-ups (Scenario-Based)

Q1: A permission is in a permission set inside a PSG, and it's muted in that PSG. A separate permission set assigned to the same user also grants it. What's the net access?

A1: The user HAS the permission.

• Muting only removes permissions inside its own Permission Set Group.
• It can't remove access that comes from outside that group, like a standalone permission set, another PSG, or the profile.
• Salesforce combines all grants as a UNION. Muting is the only way to subtract, and it works only inside its group.

Q2: In an org with 1,500+ users, how do you keep permissions manageable, for example when business users need to configure a no-code approval app?

A2: Build persona-based PSGs with a clear naming convention (for example, APP_Persona_Capability), so admins can audit assignments easily and the number of profiles stays in single digits.

• For the approval app, business users who configure rules get a dedicated Approval Config Author permission set.
• It grants access only to the custom configuration objects, not to the core transaction data.
• Result: Onboarding a new configuration admin means assigning one PSG, with no profile changes.

Quick FAQ

Q: Can a user have more than one profile?

No. Every user has exactly one profile at a time. If a user needs extra duties, assign permission sets or a permission set group instead of changing or cloning the profile.

Q: Do roles control what users can see or what they can do?

Only what they can see. Roles never grant or remove object permissions like Read, Create, Edit, or Delete. Those come from the profile and permission sets.