Role-Based Access Control in Copilot

Role-based access control, or RBAC, allows you to create Roles (also commonly called permissions profiles or User Groups) with custom permissions. For example, an IT Admin might need to configure 'Single sign-on’ or connect Salesforce to Copilot but the IT Admin doesn't need access to your team's Battlecards. 

This feature is for enterprise Copilot deployments, where access to viewing calls, modifying system configuration, and other actions in Copilot must be tightly controlled based on user profiles. 

Use Cases

Leaders: Prevent different teams across geographies or different sales functions from viewing each other's calls, scores, and performance metrics while allowing leadership to retain an unrestricted view of their team's calls and metrics. Invite new members to their team and manage Battlecards for just their team without being able to modify Copilot Integrations, etc.

IT and Security: Policies around Info-sec can be enforced by restricting actions such as deleting, downloading, or sharing calls outside the organization entirely or for select roles/users. 

Revenue Operations and Enablement: Restrict access to Copilot configuration to specific personas, thereby avoiding unintentional changes to sales resources such as Battlecards, Topics, etc., or keeping changes isolated to individual teams. A ‘grant minimal set of permissions for each user' policy can be followed in Copilot. 

How To Use Role-Based Access Control

Once Clari enables the feature for your org, a 'Role and permissions tab' appears in Workspace Settings that allows the creation of custom roles. 

From Clari Studio > Copilot > Workspace Settings

Then click Roles and Permissions on the left:

Click into a role to set permissions as required: 

Assign roles to existing and new users via the 'Manage users' Tab on the left: 

Granular Admin Controls

Access to Workspace Settings allows control the behavior of features across the organization, rather than just the current user’s preference, such as whether to obtain Recorder consent, state of CRM and Dialer Integrations, etc.

From the Roles and Permissions tab, you can select a user type that has admin access. You can which roles have admin access because they say "Admin" on the role's tile: 

If a role doesn't currently have admin access, and you want to grant admin access, follow the same steps below.

1. Click the type for the user type you want to grant, or edit, Admin Access for.
2. Scroll down until you see "Admin Access."
3. Enable Admin Access for a role, then you can enable various Admin access settings for that particular role.
4. From the dropdown menus next to each feature, you can grant or restrict access to each individual feature configuration tab by assigning one of 3 available access levels:

• No access - The user cannot view or modify any configuration relating to the feature which is entirely restricted.
• Read only - The user can view the current configuration for a feature but cannot modify it.
• Full access - The user can view and modify the feature configuration.

In our example below, this Admin role has Full Access to all features listed:

Note: If a role/user is expected to administer all or even any on of the Workspace Settings, Admin Access Option must be enabled. Only users with Admin Access enabled can access the Workspace Settings page. For most sales roles, like SDRs and AEs, and observer roles, we suggest keeping Admin access turned off.

All Available Permissions 

Role-Based Access Control with an SSO Directory

When users are managed through OKTA, Azure, or any other supported Directory Provider, all user management must only be done from the Directory provider. Roles or managers cannot be set from within Copilot.

How to Assign Roles with SSO

With an SSO Directory, you can assign roles via User Groups. 

All Directory providers support user groups, which are just tags for categorizing users. The user has to be made a member of a particular group in the Directory Tool. The Groups themselves have to be pushed over to the Copilot SCIM application. Here's an example from Okta: 

Your pushed Groups show up in Copilot under the following: Workspace setting > Roles and Permissions > User Groups tab.

You can then map these to Copilot Roles: 

Let's work through an example.  

To map users to two Groups, USA Sales Rep and EU Sales Rep, with different permissions:

1. Create 2 Roles in Copilot, labeled USA Sales Rep and EU Sales Rep.

2. Set the desired permissions for these roles.

3. Create two groups on the Directory provider (these steps are similar for Okta, Azure, and other providers Copilot supports. For detailed info, refer to the respective platform docs). The recommended way to name groups is to mirror the Copilot Role names with an alias indicating the application name (e.g., Copilot would be "copilot-role-name," in small case). 

So let's name these two groups copilot-usa-sales-rep and copilot-europe-sales-rep.

4. Push the 2 Groups to the Copilot app from Okta.

5. In Copilot, go to Workspace setting > Roles and Permissions > User Groups tab and map the Directory provider groups to the correct Copilot roles.

6. On the Directory tool, assign all the USA sales reps to the copilot-usa-sales-reps, similarly assign all Europe sales reps to the copilot-europe-sales-reps group.

And that's it. The users created/managed via the Directory will now have the intended roles.