A common confusion with major consequences

Roles and permission sets are two of the most commonly used concepts in Salesforce access management. They are also regularly used interchangeably, both by administrators and by the people who design the access model. That is understandable, since both influence what a user can see and do in Salesforce. But they work fundamentally differently, and that confusion leads in practice to access models that become unmanageable.

In this article we explain the difference, show what a well-designed model looks like, and why this directly impacts your security and compliance.

What are roles in Salesforce?

Roles in Salesforce determine record visibility. They are organized hierarchically: a user higher up in the role hierarchy can see the records of users lower in the hierarchy, unless configured otherwise.

So roles are about data visibility, not about what a user is allowed to do. A sales manager who sits above an account manager in the role hierarchy can see that account manager's opportunities. But whether the sales manager is also allowed to create, edit or delete opportunities is not determined by the role.

Roles are primarily a reporting and visibility mechanism. They are important, but they are not designed to manage access rights.

What are permission sets?

Permission sets determine what a user is allowed to do in Salesforce. Think of: which objects are accessible, which fields are visible, which actions may be performed and which functionality is available.

Permission sets are added on top of a user's base profile. They are additive: every permission set assigned to a user adds rights. Rights can never be revoked through a permission set.

This makes permission sets the primary instrument for access management in a modern Salesforce environment. A well-designed set of permission sets makes it possible to tailor permissions precisely to a function, without having to create a separate profile for every combination.

What are profiles, and how do they relate to permission sets?

Profiles are the foundation of every user account in Salesforce. Every user has exactly one profile, and that profile determines the minimum rights the user has.

In older Salesforce environments, profiles were often used to configure all rights. That led to large numbers of profiles, sometimes dozens or hundreds, that are difficult to manage and document.

The modern approach is different: use as few profiles as possible, configured as lightly as possible, and manage all additional rights through permission sets. This keeps the access model clear, scalable and auditable.

What does a well-designed access model look like?

A healthy access model in Salesforce is built on three principles:

• Least privilege as the default: a user only receives the rights necessary for their function, no more
• Separation of duties: users who create data should not also be able to delete or export that data unless this is explicitly required
• Traceability: every access right is traceable back to a business role and a decision

In practice, that looks like this:

• A limited number of light base profiles, for example one for internal users and one for external users
• A set of well-named permission sets that map to business functions, such as “Account Manager: read access to customer data” or “Finance employee: export rights”
• Permission set groups for functions where multiple permission sets are always used together
• A role hierarchy that maps to the organization's reporting structure, not to its access structure

What goes wrong if this isn't right?

You can recognize an access model that is not in order by the following signals:

• There are dozens or hundreds of profiles that barely differ from one another
• Administrators no longer know which profile or permission set grants which rights
• New employees are assigned an existing profile that “comes closest”, instead of a profile that fits exactly
• When someone changes role, rights are added but never revoked
• There is no documentation of what the individual permission sets contain

Each of these situations is a security risk and a compliance issue. And they all stem from the same cause: an access model that has grown organically rather than being deliberately designed.

How do you start a redesign?

A redesign of your access model does not have to happen all at once. A pragmatic approach:

• Start with an inventory: how many profiles and permission sets exist, and what do they grant access to?
• Identify overlap and redundancy: which profiles are effectively identical or near-identical?
• Define your business roles: which functions exist in your organization, and which Salesforce rights belong to them?
• Design a new model on paper before you change anything in Salesforce
• Migrate in phases: start with new employees and then expand to existing users
• Document every decision: who has which right, based on which business rule?

Conclusion

Roles and permission sets are not synonyms. Each plays its own part in your access model, and only when you deploy them deliberately and correctly does a structure emerge that is manageable, secure and auditable.

The organizations that have set this up well notice the difference immediately: less administrative overhead, fewer exceptions, less stress during audits, and greater confidence in the security of their Salesforce environment. Want to have your current access model reviewed? Schedule a no-obligation conversation