Roles

Roles define what employees can do in CXone Mpower. First, you create one or more roles and associate specific permissions with it. Then you assign the roles to employees so they have access to the information they need and can do the work they need to do. You can assign an employee both primary and secondary roles.

CXone Mpower comes with up to four out-of-the-box (OOTB) roles: Agent, Manager, Administrator, and Evaluator (if your organization uses CXone Mpower Quality Management). These roles can be edited by employees with permission to do so.

The Change History tab for a role contains a history of modifications to that role. Because the history table can become so large, you can use search and filter tools to limit the table's contents based on certain text or based on a specific time period.

Primary vs Secondary Roles

Primary Role: The main role assigned to a user, which determines their default permissions, access levels, and interface view when they log in. It’s what the system references first when evaluating what the user can do.

Secondary Role: A supporting role that adds additional permissions or access beyond what the primary role provides. It doesn’t override the primary role but supplements it. For example, allowing a supervisor with a primary Manager role to also perform limited Evaluator tasks.

Key details about primary and secondary roles:

• Every employee must be assigned a primary role. If your tenant is enabled for CXone MpowerDigital Experience, only the primary role assigned to an employee is synced to the Digital Experience portal.
• Employees can have one primary role and up to 10 secondary roles, for a total of 11 roles. This makes it easier for you to assign only the specific permissions an employee needs (the "least privilege" principle). Using role-based access control (RBAC), CXone Mpower considers the net permissions from all of the employee's assigned roles when determining whether to grant access to features and privileges.
• Secondary roles don't impact the CXone MpowerACDapplication. Users can only access ACD features allowed by their primary role.

• In a role's details, the Assigned Users tab shows users who have the role as either a primary or secondary role. It includes both active and inactive employees.

  When you assign a role to an employee from the Assigned Users tab, it becomes the employee's new primary role. Secondary roles can only be assigned from the employee account.

Key Facts About Roles

Role Naming

• Role names must be unique and no more than 50 characters in length. Role names are not case sensitive (that is, admin and Admin are the same). You can't use any of these special characters in a role name:

  / \ + ! ? < > # & , % "

• You can't reuse a role name that has ever been used before, even if the role has been deactivated.

Role Statuses

• Roles exist in one of three statuses: active, inactive, and draft.
• From a functional standpoint, draft and inactive roles share the same characteristics. However, the difference in status name can help you understand which roles are still being developed (draft) and which are not currently in use (inactive).
• You can't assign inactive or draft roles to active employees.
• You can't deactivate a role that's assigned to active employees.
• You can deactivate a role that's assigned only to inactive employees.

Employees & Roles

• Roles can be assigned to no employees, one employee, or any number of employees.
• You can assign inactive employees to roles. For example, if you create employee accounts for new hires but don't activate the accounts until the hire actually finishes orientation, you can assign the employee to a role when you set up the account. If your tenant is enabled for Digital Experience, and you need to configure additional permissions in the Digital Experience portal, you cannot do so until after the employee activates the account.
• You cannot reactivate an employee who is assigned to an inactive role without first reassigning the employee to an active role.
• You cannot change your own role.

Role Permissions

• When you create a new role, there are no default permissions associated with that role. To save time, you can copy an existing role and use it as the basis for a new role.
• Some permissions are dependent on others, and these dependencies may be reflected in the user interface when you click a permission to select it. For example, if you click an Edit permission, both Edit and View may show as selected since you must be able to view something in order to edit it. Permission dependencies may vary from one CXone Mpower application to another.
• Details about the specific permissions and privileges you can include in roles are included in the permissions topic for each CXone Mpower application.
• Some Digital Experience permissions are managed in the portal specific to that application.
• The following types of data are not limited by a role's permissions:
  • Data download reports
  • Direct data access reports
  • APIs