Skip to main content
Profiles, Roles, and Permissions

This article will walk you through profiles, roles, and permissions which determine the hierarchy and access users have within the tool.

Andrew Tzikas avatar
Written by Andrew Tzikas
Updated over a week ago

In Salesforce, there are a few different functions that feed into permissions and access. The key features are Profiles, Roles, and Permissions.

Profiles: are required for each user in the system. Every user account will have a corresponding role. This is the foundation of how users can navigate their Salesforce Accounts. The difference between a System Administrator, a Standard User, and a Read-Only User, are all defined at the Profile level. Salesforce has out of the box Profiles, like the three just mentioned, but you also have the ability to create custom Profiles if needed. Typically, we see the standard user profile being used for the majority of Accounts within Salesforce environments. If you want to bake in permissions to objects, apps, record types, tabs, page layouts, etc., you would do this at the Profile level.

Roles: in Salesforce are determined at the User level and are typically used for hierarchy purposes which define what a particular user can see on a record-by-record basis. Roles are optional for users in Salesforce, but we highly recommend them. Roles can be customized to fit your organizational structure. From CEO to SDR, you can choose the naming convention of each role, define direct reports, and thereby limit access for users. If, for example, you only want managers to see their direct report's information, or to be able to make updates to their records, you would define this at the role level.

Permission Sets: this is an extra layer on top of the foundation of Profiles which allows you to create separated permission sets and assign to individual users or certain groups of users. For example, if you have a Custom Object, like Onboarding Cycles, that you only want a subset of users to have access to, you can create a permission set to grant them access and assign the Permission Set to the individual users. Another example of a Permission Set is to edit Reports and Dashboards. This ability is not native to any of the Profiles, so a permission set is required to allow users to take actions like this.

Permission Set Groups: you can bundle individual permission sets into groups to assign to users in bulk. Swantide users a Standard User Permission Set Group to group the majority of permission sets needed for users to interact with records, edit personal reports, and more in an efficient way.

Did this answer your question?