What's the difference between permission sets and role-based access control in a CRM?

An admin needs to give one rep the ability to export data for a special project, but that rep’s role is “Sales Rep” like everyone else on the team. Creating a whole new role just for one person’s temporary exception is how CRMs end up with forty barely-different roles nobody can explain a year later. Permission sets exist so that exception doesn’t require a new role at all.

What is role-based access control, again?

Role-based access control assigns each user one role — Rep, Manager, Admin — and that role determines what they can see and do by default. It’s the right tool for defining the baseline: what every rep should be able to do, what every manager should see beyond that, and so on. The strength of RBAC is exactly its rigidity — one role, one consistent set of permissions, easy to reason about at a glance.

What’s different about a permission set?

A permission set is an additive grant that layers on top of a user’s role rather than replacing it. It doesn’t define a baseline — it says “this specific person or small group also gets this specific extra access,” without disturbing their underlying role or anyone else’s. The rep who needs company-wide export access keeps their normal Sales Rep role and permissions; the export capability is attached as an extra grant on their user record alone.

Why does mixing them up cause problems?

Teams that don’t have permission sets available, or don’t use them, tend to solve every exception by creating a new role — “Sales Rep - Export Access,” “Sales Rep - EU Region” — until the role list is longer than the headcount and nobody can say what any given role actually grants without checking. Teams that overuse permission sets have the opposite problem: baseline access drifts because so much is layered on individually that the role stops meaning much, and a security review turns into checking permissions user by user instead of role by role.

What should you do next?

Audit your current roles for one-off exceptions disguised as new roles — if a role exists for exactly one person, it’s very likely a permission set pretending to be a role. Reserve roles for genuine, repeatable job functions and use permission sets for the individual exceptions, and your access model stays something a new admin can actually understand.