Managing role permissions
Each role in the system has a permissions page where you can set which objects users have access to, how they can interact with each object, and which general system actions users can take.
Accessing role permissions
Each system user is assigned a role which controls their permissions. These roles can be assigned to multiple users, and will provide them with the same level of access to data. To edit the permissions, you’ll need to open the specific role’s permission page. Start by clicking the settings gear on the top right of any page, then select the Roles page from the topbar to open a list of all the system roles. Click on a role to open its permissions page. To learn how to create roles and assign them to users, check out the following article.
Once you’ve opened a role’s permissions page, you’ll see two sections. On the left is the object permissions where you can set each user’s access level to objects, and choose when the user can read, edit, create or delete records belonging to each object type. You can also set a sharing level to control which records within the object the user will have access to. On the right is the action permissions, where you can choose which system wide actions users can perform, such as imports and exports. These actions also allow you to provide access to system settings. For each role, you can also create a default top bar menu. Each permission option is explained in detail below.
Object permissions
Under the object permissions, you’ll be able to set which objects each role can create, read, edit, or delete, as well as the sharing level for each object.
Object types
You’ll find a list of all the objects in your system under the header Object Name. There are two types of objects you can set permissions for. The first is editable objects, such as Accounts, Deals, and any custom objects, which will all appear in the object studio. You can learn about the object studio here. The second is inner system objects such as Dashboards, Pages, Forms, View Designers, and more. These objects are used by the system to know when to allow access and customization of them. For example, if a user does not have permissions for the Pages object, they will not be able to change the pages of any object.
Permission types
There are five permission types which you can set for each object. The Create, Read, Edit, and Delete types control how the user can interact with the object, while the Sharing level controls which records the user has access to, and is explained below.
- Create: This allows the users to create new records of this object type.
- Read: This allows the users to see the object in their menu, open the object’s views, and see records of this object type.
- Edit: This allows users to change the fields within any of the object’s records.
- Delete: This allows the users to permanently delete records from the system.
If you create a new object, it will automatically have all the object permission types unchecked and the sharing set to only me. This is true for every role except for the admin role, which you can learn more about here.
Setting permissions
Under the Object Name header on the left you’ll find a column with all the objects in your system, alphabetized from A to Z. You can then choose the role settings for each object by selecting or deselecting the blue check on the relevant row. You can also bulk select or deselect any of the permission types for all the objects by hovering to the right of the header name and then clicking the circle that appears. Once you’ve set the permissions, be sure to click Save on the top right of the page.
For example, you may wish to create a Support role and allow them to see existing accounts and create new ones, but not edit or delete any existing accounts. To do so, select the Create and Read permissions for the Accounts object. You can then provide them with the Read option for Deals, so that they can see all the deals but cannot create, edit or delete them. In this way, anyone assigned to the Support role will be able to create new accounts if someone new reaches out, and will be able to find and provide information on deals to existing accounts. However, they won’t be able to change any existing information.
Object sharing permissions
The sharing permissions use a dropdown list and allow you to set which records each role has access to. This is highly recommended when you want to keep information private and only accessible for relevant employees.
To select an option from the sharing permissions, first click on the currently selected option for an object under the Sharing header. This will open a dropdown list, where the currently selected option will have a gray background. You can select one of the displayed sharing permissions and then click Save on the top right of the page. Each option is explained in detail below.
The sharing permissions are based on the ownerid field, which is a built in user lookup field. It can be found in every object and requires you to set a system user as the owner of each record. You can change the name of the field, but the API name, which you can learn about here, will always be ownerid. Use the custom sharing option to share object records without using the ownerid field.
Only Me
By selecting Only Me, users will only see the records where they are set as the owner. This is a great option for objects which contain sensitive information which should only be seen by the owner. For example, you can select this option for the Accounts object of the Account Manager role. In this way, each account manager will only see and access the account records which they are the owner of.
Team Only
The Team Only option is based on the role the current user is set to. It will share any records where the owner of the record is either the current user or has the same role as the current user. This is extremely useful when you’d like to share information between a specific team. For example, you can set the Sales Rep role to see any Deals records where the owner is set as someone from the sales team. In this way, each sales rep will be able to access any of the deals which are relevant to their team.
Business Unit
By using business units, you can keep each branch or section of your organization separate. This is especially helpful when you have multiple branches which do not share all of the same information. For example, your north and south branches may have different assets. To keep these assets separate, you can set the Assets object to share on the Business Unit level. In this way, any asset records where the owner is or has the same business unit as the current owner will be accessible. Any other asset records will not be accessible, and will stay in the hands of the relevant branch.
Everyone
Selecting the Everyone option will allow access to any records in this object, regardless of who the owner is set to. This is great for upper management roles, and is the set option for the Admin role. To learn more about the admin role, click here.
Custom
The custom sharing option allows you to use an object’s fields to set conditions and filter when each record in the object will be displayed. This lets you fully customize the sharing level of records to your business needs. Unlike the rest of the sharing options, it does not use the ownerid field. To learn how to use custom sharing, click here.
Actions
The Actions permissions can be found on the right side of the permissions page, and contain a list of system wide actions. You can select which of these actions the user will be allowed to perform by clicking the circle to their left. For example, by clicking the circle next to Bulk Edit, you’ll allow the current role to bulk edit records. To deselect an option, simply click on the blue check. Make sure to click Save on the top right once you’ve made any changes.
User permissions and access
The Users object sharing settings will control when system users are accessible on a system wide level. In this way, all the system users will not always be visible to other users, as it is completely dependent on the sharing level of the Users object. You can read more about each sharing permission above.
For example, the Support role may have access to users on a Team Only level. This means that they’ll be able to access any system users who share the same role and business unit as them. Any support team members will be able to tag each other and set each other as the owners of tasks, accounts, and more. However, users assigned to the support role will not see any system users who are not assigned to the support role or to the same business unit as them. In this way, they’ll only access and communicate with users who are relevant to them.
User sharing permissions become relevant in any locations throughout your system where you access users. One example of this is the Notes object of a stream. Users who you do not have permission to see will not come up after you type the @ symbol, which you can learn more about here.
Additionally, any users which you don’t have permission to view won’t be displayed as options in lookup fields throughout the system. For example, if your Users settings are set to Team Only, you won’t be able to assign tasks to users who aren’t on your team. This will apply to the owner fields of all system objects, such as accounts, meetings, and more. For this reason, it’s very important to choose the sharing level for the Users object which works best for your organization.
