Understanding Team-Based Role Permissions

Overview

Teams can be used not only to control which records a user can see but also to determine what users can do with records. Using team-based role permissions, regular users can use a record's Teams field to grant access such as viewing, editing, exporting, importing, and deleting permission to specific users or user groups. In this article, we will walk through several role scenarios that illustrate what to expect when using team-based permissions.

Prerequisites

• Team-based permissions must be enabled by an administrator. For more information on enabling team-based permissions, please refer to the Role Management documentation.
• An administrator must configure roles and users for team-based permissions. Team-based permissions have no effect on users who have not been assigned to roles that are configured with "Owner & Selected Teams" access. For more information, please refer to the Role Management documentation. For information on using team-based permissions on a record, please refer to the User Interface documentation.

Use Cases

The following sections present several use cases that apply to the Accounts module, which we have enabled for team-based permissions for this article. Unless otherwise indicated, each example user only belongs to one role.

Note: In the following examples, the "Owner & Selected Teams" role setting is abbreviated as "O&ST".

Private Teams

Private teams are a convenient way to provide extra access to a single user using team-based permissions. Private teams are automatically created for each user and, by default, include only that user and any managing users up the implicit team membership hierarchy which is controlled by the Reports-To field on the users' profiles. When a user is restricted by the Owner & Selected Teams option on a role, the restriction can be lifted for that user by adding and selecting their private team on the record. Please note that it is possible to add other users to an individual's private team, though this is not recommended or commonly done.

As an example, Jim and Will have identical team and role settings except for their private team memberships.

The account's Assigned To and Teams fields are set as follows:

Expected Behavior

Because Jim's private team is selected for extra access, Jim and Will have different access to the account, despite their otherwise identical team and role configurations.

• Jim can edit and delete the account because his private team is selected and he has O&ST permission to edit and delete.
• Will cannot edit or delete the account because he is not the record owner and none of his teams are selected for extra access.
• Jim and Will can both view the account because they have standard team access via team East and the View column for Accounts has not been set. When a permission is "Not Set", users in the role default to "All" access.

Same Role, Different Teams

Three users with identical roles are trying to access the same account. None of the users are assigned to the account record. Because of their team memberships, these users may have different results when they attempt to view the account.

The account's Assigned To and Teams fields are set as follows:

Expected Behavior

All three users have owner-and-selected-teams role restrictions placed on viewing accounts. None of the users are the account owner for this record, so they must be on a selected team to see it.

• Rick can view the account because his team is selected for extra access.
• Philip cannot view the account because his team is not selected for extra access.
• Linda cannot view the account because she does not belong to any of the account's teams.

Same Team, Different Roles

For this example, Jim and Will are on the same team but have different roles. Only one can delete the account record.

The account's Assigned To and Teams fields are set as follows:

Expected Behavior

Will's access to the Accounts module is more restrictive than Jim's; Will can only delete account records that are assigned to him. Jim, on the other hand, can delete account records that are assigned to him as well as account records where his team is selected for extra access.

• Jim can delete the account because he is on selected team East and has O&ST permission to delete.
• Will cannot delete the account because he is not the owner and his role has owner-only permission to delete accounts.
• Both Jim and Will can view and edit the account because they are both on the selected team and both have O&ST permission to edit accounts.

Extra-Access Not Selected

In this example, Jim and Will's access settings have not changed from the previous use case (Same Team, Different Roles), but the record they want to delete does not have their team selected for extra access.

The account's Assigned To and Teams fields are set as follows:

Expected Behavior

Like before, Jim and Will can both delete account records that are assigned to them, but Jim can also delete account records where his team is selected for extra access. In this example, though, no teams are selected for extra access.

• Jim cannot delete the account because he is not the record owner, and team East is not selected for extra access.
• Will cannot delete the account because he is not the record owner, and his role has owner-only permission to delete.
• Neither Jim nor Will can edit the account since their team is not selected for extra access nor are they the record owner. Their roles only grant the owner and selected teams edit permissions.
• Jim and Will can both view the account because they have standard team access via team East and the View column for Accounts has not been set. When a permission is "Not Set", users in the role default to "All" access.