Engage Voice | Roles overview
Roles are permissions templates that you can create and configure within the system. They allow you to choose a set of permissions and aggregate them into a doc under the name of your choice. You can then assign that doc to different system users according to the amount of access you wish to give them.
Roles can limit and grant access to different accounts, users, groups, products, features, and functionalities. Their purpose is to allow you to get as granular as you like with security controls, whether you’re a BPO looking to allow certain clients access to the software while still maintaining the privacy of your other accounts, or a manager of a large call center looking to assign differing levels of security clearance to multiple supervisors.
You can find your Roles page in the sliding tray under the Users product menu option via the left-hand navigation bar.
Please note: You must already have your user(s) properly configured in order to create, edit, or assign Roles.
The Roles hierarchy
Roles access begins at the account level, and permissions are ‘granted’ down from there. Every admin user (including the first admin to join the platform) has access to their own Roles. This set of permissions has already been configured for them by whoever gave them access to the platform. And this set of rights, their own Role, is what they, in turn, will use to grant other users access to the platform as well.
Roles follow a hierarchy similar to that of a typical family structure, where a ‘parent’ Roles sits at the top of the permissions hierarchy. This parent doc can be used to create ‘child’ and ‘sibling’ docs that grant permissions and system access to any users they’re assigned to.
‘Sibling’ docs are exactly what they sound like. You can think of them as any Roles that exist at the same level within the user hierarchy. Let’s say the owner of a parent doc creates three child docs. These three child docs are all siblings to each other, since they’ve been created by the same parent. The system also allows the owner of the parent doc to choose which sibling docs can ‘see’ other sibling docs.
Once the docs are created and configured, they can be assigned to one or more admin users, who can then access the platform according to the permissions granted to them within the docs they’ve been assigned. Please note that one Role can be assigned to one, multiple, or even groups of admin users.
Roles relationships and permissions
As discussed above, Roles can have variations on parent, child, and sibling relationships, and varying levels of permissions within those relationships. Here are a few basic rules to keep in mind:
- Owners of parent docs can view, edit, and delete their child docs
- Owners of parent docs can assign or unassign any user(s) to or from their child docs
- Owners of child docs can create their own child docs and assign them to whomever they wish (let’s call these ‘grandchild’ docs, which makes the original Role a ‘grandparent’ doc)
- Owners of grandparent docs can view — but not manage — their grandchild docs
- When a parent doc is used to create multiple child docs, all the child docs can be considered siblings
- Parent doc owners with multiple child docs can permit or deny the child doc owners the ability to view their sibling docs (whether individually or as a group)
- Roles owners can only grant child docs the same — or fewer — permissions than they themselves currently possess (which means that you cannot at any time grant permissions that you yourself do not already have access to)
Getting granular with permissions
Admin users can get as granular as they like with their security controls within the permissions hierarchy. Since permissions controls are available at nearly every level of the platform, it’s easy to create customized clearance levels for all kinds of users, from those needing basic and simple permissions to those needing varied, complex levels of access to the platform.
Permissions can be controlled at the following levels:
- Accounts
- Agents (down to the individual agent level)
- Inbound, Outbound, and Chat (down to the individual queue and campaign levels)
- Cloud Destinations, Cloud Profiles, TFN/DID Manager, Utilities, and Number Tracking
- IVR and Script Studio (down to the individual IVR and script levels)
- Knowledge Base (down to the individual article level)
- Web Services (down to the individual web service level)
Say an administrator has a few campaigns and queues that they want some, but not all, of their supervisors to access. They also have three remaining supervisors who each need completely different levels of access to the platform.
One way for the administrator to manage this is to perform the following tasks:
1. Create a child doc that does not allow access to those private campaigns and queues
2. Create a second child doc that does permit access to those campaigns and queues
3. Assign the first child doc to the supervisors who should not have access to the private campaigns and queues
4. Assign the second child doc to the supervisors that do need to access those private campaigns and queues
5. Create and assign three individual Roles that permit and deny access at exactly the levels each of the remaining supervisors need
Please note that while Roles may be easy to structure and configure within the admin interface, they do follow a complex set of rules behind the scenes, and they extend into all areas of the platform. This means that if you plan to do any significant restructuring of permissions, it is recommended you first speak with your CSM to ensure you maintain the integrity of your intended permissions structures.
© 1999–2022 RingCentral, Inc. Alle Rechte vorbehalten.