Salesforce Roles vs Profiles vs Permission Sets: What’s the Difference and When to Use Each 

Salesforce roles vs profiles vs permission sets sounds like a simple question until a new hire logs in on day one. Either she can see every account in the company, or she can’t open her own. Both problems reach the admin as the same ticket: “my access is wrong.”

The confusion is understandable. Roles, profiles and permission sets each control a different kind of access, and Salesforce shows them side by side in setup as if they were interchangeable. This guide explains what each one does, how they differ, when to use which, and how to keep access manageable as your org grows.

What Are Salesforce Profiles?

A Salesforce profile is a set of permissions and settings that defines what a user can do in the org. Every user has exactly one profile, usually built around a job function such as Sales Rep, Support Agent or System Administrator.

Profiles work at the object, field and system level. Object permissions decide whether a user can read, create, edit or delete records of an object like Accounts or Opportunities. Field-level security decides which fields they can see or edit. App and tab access controls what appears in their navigation, and system permissions cover broader abilities such as running reports, exporting data or managing users. Take a sales representative. Her profile might let her edit Leads, Accounts and Opportunities, read Products and open the Sales app, while hiding a discount field and blocking data export. None of that says which specific records she can open. That’s a separate question.

What Are Salesforce Roles?

A Salesforce role defines where a user sits in the record-visibility hierarchy. Salesforce describes roles as primarily controlling record-level access, through the role hierarchy and sharing rules. A role doesn’t decide what a user can do with an object, only which records they can reach.

How the role hierarchy works

Roles form a tree. Users higher in the hierarchy can access the same records as the users below them, so a sales manager can see opportunities owned by her reps, and a regional manager can see everything beneath him. For standard objects this upward access is on by default, though it can be switched off for custom objects.

The hierarchy sits on top of your organization-wide defaults, which set the baseline access to each other’s records. If Opportunities are Private, a rep sees only her own. The hierarchy opens access upward, and sharing rules can open it further. Both only add access, never restrict it below the default.

What roles don’t do

Roles do not grant object-level permissions. If the regional manager’s profile and permission sets don’t allow him to read Opportunities, he can’t see them, however high his role sits. The role only widens which records he can reach once he has the object permission.

What Are Salesforce Permission Sets?

A permission set is a collection of settings and permissions that gives users access to specific tools and functions. Where a profile is the baseline, a permission set adds to it without changing the profile.

If a permission is off in someone’s profile but on in an assigned permission set, the user has it. A user can have only one profile but can hold several permission sets, with the number depending on the Salesforce edition.

That changes how you handle exceptions. If two senior support agents need to merge duplicate contacts, you give them one permission set instead of cloning the profile for everyone. Salesforce calls permission sets the recommended way to manage users’ permissions, which is why most orgs keep profiles lean.

Salesforce Roles vs Profiles: Key Differences at a Glance

The difference between a role and a profile in Salesforce is what each controls. A profile controls what a user can do: object, field, app and system permissions. A role controls which records the user can see, based on their place in the hierarchy.

The table below sums up Salesforce roles vs profiles side by side.

A profile answers “what can this person do?” and a role answers “whose records can this person see?”

Salesforce Permission Sets vs Profiles

Profiles and permission sets don’t compete so much as layer. The profile gives everyone in a job function the same foundation: the objects they use daily, the fields they should see, their apps and a few system permissions. Permission sets add whatever extra a person needs, such as a custom object or export rights.

That’s why Salesforce permission sets vs profiles is really a flexibility question. A permission set is granted per person or task, not per job title. A rep who also runs the quarterly forecast review needs one permission set, not a new profile, and you can remove it when the process changes.

One caution: a permission set only adds access. It can’t tighten what the profile already allows, so the profile should be the narrowest sensible version of the job.

Salesforce Roles vs Profiles vs Permission Sets: When to Use Each

Use a profile for the access nearly everyone in a function needs, and a permission set for access only some of them need. A few situations show the split.

A new sales rep joins. Assign the Sales Rep profile and the role matching their team. That gives them the standard tools and puts their records in the right branch of the hierarchy.

A sales manager needs more reporting access. She already has the Sales Manager profile and sits above her reps in the hierarchy. A permission set with the extra reporting permissions covers the gap.

A support agent needs temporary access. If an agent has to approve refunds for two weeks, assign a permission set and remove it afterward. Changing a shared profile would affect everyone on it and is easy to forget to reverse.

An admin juggles different requests. Ask whether a request describes a job function or a task. Functions belong in profiles, tasks in permission sets.

Salesforce Roles vs Profiles and Permission Sets: Real-World Example

Imagine a company with ten sales reps, two sales managers, one regional manager and two administrators.

The reps share a Sales Rep profile with the object and field access needed for leads and opportunities. The managers share a Sales Manager profile with the same access plus reporting abilities, and the administrators hold the System Administrator profile. Roles are designed separately: reps sit under their manager, the managers under the regional manager, and Opportunities are Private. A rep sees her own deals, her manager sees his team’s, and the regional manager sees everything beneath him.

Then come the exceptions. One rep leading a pilot needs a custom Territory Planning object, so she gets a permission set. One manager needs export rights for a quarterly review, so he gets another. Neither touches a profile or a role.

So profiles set what people can do, roles set whose records they see, and permission sets handle the exceptions. If AI agents are also being given access to your data, they deserve the same scrutiny, and our post on Salesforce AI security and permissions for AI agents covers that side.

How Permission Set Groups Simplify Salesforce Access Management

A permission set group bundles several permission sets so you can assign them together. Users assigned the group receive the combined permissions of every permission set inside it. Salesforce suggests building permission sets around specific tasks, then grouping them by job function.

If sales operations analysts need four permission sets, you build a Sales Ops group and assign that one thing. When a permission set changes, the change reaches every group that contains it.

Muting handles exceptions. A muting permission set switches off selected permissions within a group, so you can keep one broad permission set and remove a single capability for one group instead of duplicating it. Muting affects only users assigned to that group, so someone who gets the same permission from a profile, another permission set or another group keeps it. Each group can have just one muting permission set.

Permission set groups organize permission sets and nothing else. They aren’t a substitute for profiles, and they don’t affect roles or record visibility.

Common Salesforce Access Management Mistakes

Most problems with Salesforce roles vs profiles start the same way, and the most common is creating too many profiles. Someone needs one extra permission, an admin clones a profile, and two years later there are forty near-identical ones nobody trusts.

Another is trying to use roles to control object permissions. A role can’t give anyone the right to edit Opportunities, so teams expecting it to end up widening a profile and handing that permission to everyone on it.

Excessive permissions come next. “View All Data” and “Modify All Data” are easy to hand out and hard to take back. Assigning permission sets without reading what’s inside is a quieter version of the same problem.

Ignoring field-level security is the one people spot last: a user who can read Contacts may still see fields holding personal data. And without regular reviews, access only grows, because people change teams and permission sets stay assigned.

Best Practices for Salesforce Roles vs Profiles and Permission Sets

Start with least privilege: give users the minimum access they need, and add to it only when there’s a reason. Salesforce still names this the best practice, with permission sets and permission set groups as the best way to achieve it. Salesforce has also cancelled its earlier plan to retire permissions on profiles, so profiles remain supported, but check Salesforce’s current documentation before building around any long-term direction.

Keep profiles simple, a few broad baselines, and put anything extra in permission sets. Design the role hierarchy around reporting lines and who genuinely needs to see whose records.

Review access on a schedule. A quarterly look at who holds powerful permissions and which permission sets are still assigned catches most problems early, and a Salesforce health check can cover this alongside the rest of your configuration. Document what each profile and permission set is for, and who approves assignments. Test before rolling out, using a sandbox or “Log in as” to see a real user’s view.

Conclusion

Profiles decide what users can do, roles decide which records they can reach, and permission sets add access where the baseline falls short. Permission set groups make those additions easier to manage. Getting Salesforce roles vs profiles right, and knowing where permission sets fit, is what keeps access secure without turning every request into a ticket.

If your access model has grown messy, or you’re planning a clean-up as part of a wider CRM project, Amroar Technologies offers Salesforce consulting services covering configuration, access management and implementation. You can book a 30-minute call to talk through your current setup and what a simpler one could look like.