Contents
Role-Based Access Control for Advisors
Pulse Advisors support role-based access control (RBAC). You can use RBAC to control which users can access specific components—for example, you can use RBAC to configure access to the Advisors administration module for a specific subset of managers.
Advisors applications use Configuration Server business attributes, which means that the Advisors applications can take advantage of Genesys Roles for controlling access at a detailed level to Advisors' business objects and metrics.
RBAC is enforced primarily by visibility in the interface. What a user sees is determined by the Roles which have been assigned. If the user is not assigned a Role that grants him or her access to a piece of functionality, that functionality is not displayed to that user.
There are three important concepts associated with RBAC:
- Permissions
- Permissions protect access to a whole object; if you have access permissions, you see the entire object.
- Roles
- Roles protect properties of an object by hiding or disabling those properties to which you want to restrict access. Roles are intended to work with permissions to more finely control what a user can access.
- Privileges
- Privileges determine what tasks or functions a user can execute on objects to which he or she has access. You assign privileges to Roles to further refine access to objects and object functionality.
What are RBAC permissions?
Elementary permissions protect access to a whole object. Permissions applied to an object apply equally to all properties of the object – if you have access permissions, you see the entire object.
Object permissions determine which users have access to a certain object or to what objects a given user has access. This is done through the use of access groups or on an individual user basis. Objects include the following:
- Contact Center Advisor and Workforce Advisor
- Metrics
- Operating Units
- Reporting Regions
- Geographic Regions
- Contact Centers
- Application Groups
- Frontline Advisor
- Metrics
- Levels of the Frontline Advisor hierarchy (that is, the folders and agent groups)
What are RBAC roles?
The major component of RBAC is a Role. If it is important in your enterprise to control users’ access to information (metrics, hierarchy levels, and business objects), you configure Users and Roles – including the assignment of permissions and privileges to each Role – before any of those users log in for the first time. Each time you have a new user in your enterprise, you assign that person to Roles in a Genesys configuration interface, such as Genesys Administrator.
Roles define what facilities are provided to users to review and manipulate various types of data. These include which property controls are available for items permitted by object permissions, what modules are visible, and access control for entities not represented by configuration objects. A Role is assigned to a User, and that User is then able to do only what that Role permits. One User can be assigned multiple Roles, and one Role can be assigned to multiple Users. A Role may also be assigned to an Access Group, and Users in that Access Group are then able to do what the Role permits.
Different Roles can have different access and allowed functionality for the same objects. In essence, Roles resolve both problems associated with using only permissions – users can access and work with only those parts of the object to which they are allowed.
Roles can also be used to protect access to entities that are not configured as configuration objects, such as logs. In general, when determining the accessibility to an object by a user, the user session cannot retrieve objects if they are not among those objects to which the user has access (as defined by object-access permissions). For data that is available in the session, Role privileges refine what can be done with the data.
Assigning Roles to Users and Access Groups
Roles can be assigned to either Users or Access Groups.
Once a Role is assigned to an Access Group, all Users in the Access Group are assigned that Role. The Access Groups and/or Users must have Read access to the Role to be able to access the Role.
The figure shows an example of Advisors Role configuration.
New Users
By default, new users are not assigned any default Roles. They must be assigned Roles by a system administrator or by an existing user with appropriate permissions.
Default Roles Created by Migration
Module access is determined by the Roles associated with a user’s profile. An optional check box on the Advisors migration utility, which is provided in the software distribution package, creates the module access schema. The figure, Migration Wizard, shows the optional Module access check box.
The utility creates default Roles in the Configuration Server, with each one representing access to a particular module. Each Role has a limited set of privileges associated with it. The default Roles are:
- AdvisorsAdmin – allows access to the Advisors administration module for Frontline Advisor, Contact Center Advisor, and Workforce Advisor users, to whom you have assigned that Role.
- AdvisorsFAUser
- AdvisorsFAAgent
- AdvisorsCCAdvUser
- AdvisorsWAUser
- AdvisorsAlertMgmtUser
You can change the preceding Role names post-migration.
Further Reading on Roles
Additional sources of information on Role-based access, privileges and permissions are:
- Genesys Security Deployment Guide
- Genesys Administrator Extension Deployment Guide
- Framework Configuration Manager Help
- Genesys Administrator Extension Help
What are RBAC privileges?
Roles consist of a set of role privileges (Read, Change, Execute, and so on). Privileges determine what tasks or functions a user can execute on objects to which he or she has access. You must define Advisors Role privileges in a Genesys configuration interface, such as Genesys Administrator or GAX.
By default, Role privileges are not assigned to any Role, so you must explicitly assign privileges to Roles. Role privileges range from general to very specific tasks. An authorized user, typically a system administrator, bundles these tasks into Roles. The Roles are then assigned to Users. As a result, each User can perform only those tasks for which they have privileges.
Functionality permissions, or privileges, determine what tasks or functions a user can execute on objects to which he or she has access. If a privilege is present in a Role, then any user who is assigned that Role has access to the functionality controlled by that privilege.
Where do I configure roles, permissions, and privileges?
Roles, and related configuration, are stored in the Genesys Configuration Server.
Typically, you configure RBAC in the following order:
- Add Roles.
- Add tasks to Roles.
- Assign Access Groups to Business Attribute instances.
- Assign Users to Roles.
Use a Genesys configuration interface, such as Genesys Administrator, to add Users to a Role. Add users with one of the following methods:
- indirectly, as a member of an Access Group
- directly, as a member of a role
You also use a Genesys configuration interface to import Advisors privileges into a Role, or to assign Role-based permissions to Persons or Access Groups.
Each Advisors privilege name uses the following general structure:
[application name].[module name].[task grouping].[privilege name]
Ensure you copy the exact privilege with no leading or trailing spaces. Some privileges work as single entries; some require a group of privileges to ensure full access as you expect. For the list of privileges for each Advisors component, see the CCAdv/WA Access Privileges and FA Access Privileges pages.
Am I limited to a specific number of users, access groups, or roles?
There is no limit on:
- the number of Roles that can be present in the Configuration Server
- the number of Access Groups or Users that can be present in the Configuration Server
- the number of Roles supported by Advisors
- the number of Access Groups that are supported by Advisors
Roles, and the privileges associated with Roles, are cumulative. A single User or Access Group can be assigned multiple Roles. In such cases, the user will have the combined set of privileges granted by each Role. In other words, the user is granted any privilege that is granted by at least one of the assigned Roles. This ensures that the user is able to perform the tasks of all Roles in which they participate.
Each user can also belong to multiple Access Groups, with different permissions coming from each group. In such scenarios, the user’s permissions are a union of the permissions of all the Access Groups to which he or she belongs, unless access is specifically denied for one group, which takes precedence (see the following scenarios).
Advisors applications follow the principle of least privilege. The following scenarios show how this union should work:
- User A is part of Access Groups X and Y.
- Group X does not have any defined access to a metric.
- Group Y has explicit access granted to the metric.
- In this case, user A is granted access to the metric.
- User A is part of Access Groups X and Y.
- Group X is explicitly denied access to a metric.
- Group Y is explicitly given access to the same metric.
- In this case, user A is denied access to the metric.
- User A is part of Access Groups X and Y.
- Group X is explicitly denied access to a metric.
- Group Y does not have any defined access to the same metric.
- In this case, user A will be denied access to the metric.
- User A is part of Access Groups X and Y.
- Neither group has defined access to the metric.
- In this case, user A will be denied access to the metric.
Can I control access to metrics?
Metrics are handled differently than other Advisors business objects. You must add the Advisors metrics in Genesys Configuration Server before you can assign the necessary permissions to Users or Access Groups (you use permissions to control access to metrics (see What are RBAC permissions?, above)).
Metrics for Contact Center Advisor, Workforce Advisor, and Frontline Advisor are stored under the Advisors Metrics business attribute; a folder structure segments the metrics for each application and for each object. The following figure shows an example of the folder structure for Advisors metrics. The folder structure shown below is mandatory. The business attributes must be created in the “Default Tenant” chosen during Advisors installation. Click the figure to enlarge it.
Each application’s metrics are created under the appropriate folder, and are subdivided by the object types with which they are associated.
To avoid confusion over similarly-named metrics, and because Configuration Server does not allow duplicated names for attribute values, the names of the metrics use a namespace and are case-sensitive. The format of the namespace is:
[Application].[ObjectType].[Channel].[Name]
The values for each characteristic of the namespace are described in the following table:
| Namespace characteristic | Definition or values |
|---|---|
| Application | FrontlineAdvisor, WorkforceAdvisor, or ContactCenterAdvisor |
| ObjectType | Represents the object type associated with this metric. This could be AgentGroup, Agent, ContactGroup, Application, or Team |
| Channel | Email, WebChat, Voice, All, or AllNonVoice |
| Name | The name of the metric |
For example, FA metrics would have names like:
- FrontlineAdvisor.Agent.Voice.nch
- FrontlineAdvisor.Team.Voice.taht