User Permissions Management

This section controls the permissions for the application users and roles.

The overall structure of permissions is:

• User belongs to a Role

• Role has a Policy

• Permissions are granted to the Policy

Users are assigned to roles, and the roles are granted access to application functionality through the policies. This page describes how to modify each of these pieces.

Application Users

The permissions page lists the Users with access to the application, as well as the Roles and Policies that drive the actions that the user is allowed to access in the application. By default, only the non-admin users are shown, but the toggle will display the ADMIN users.

Users are added to the application through the AWS Console by adding them to the Cognito User Pool from the AWS Console.

In order to give the user Admin privileges to the application, add the user to the omp-admin group in Cognito. This will give the user access to all available functions in the application.

Admin users do not need to have permissions granted through policies defined on this page.

Role Detail

Users and policies can be added to/removed from roles by clicking on the role name. This will bring up the Role Detail screen that will show the role with the list of policies currently associated to the role and another list of the users that are currently in the role.

A role can only have one policy, but the number of users assigned to a role is unlimited.

A user can only belong to one role and will remain in the last role it was assigned to. If a user’s role is changed, in order for changes in role assignments to take effect, the user must log out and log back into the application.

Policy Detail

Policies allow administrators to define fine-grained access for users of the application.

The detail allows the application to restrict non-admin user permissions to be granted down to individual Connect User detail, to be sure they only manipulate the data they are responsible for. There are many choices available when defining policies.

User / Permissions Management

While the Admin user has the ability to use all of the available functionality, non-admin user permissions are defined through their assigned roles and policies. This first section of Policy permissions will allow a non-admin user to make changes to other application Users / Roles / Policies. This section can be hidden, if the policy being defined does not need to include changes to application permissions.

The first section in the Policy Detail allows the policy to make changes to other policies. For example, if an admin user wants to give a Supervisor the ability to add application permissions to the Tech Support group, an admin can add Read / Write permissions on the TechSupportPolicy to the Supervisor policy. When a user that belongs to a role associated with the Supervisor policy logs into the application, they will be able to change permissions on the TechSupportPolicy.

To prevent a user from making changes to a policy, the admin can toggle DENY, which will override any Read / Write / Delete permissions that may be granted from other role assignments.

The permissions granted on Application Users and Roles work in the same manner when granted to a policy.

Application Feature & Resource Permissions

This section turns on and off the menu items available to the user when they log into the application

When the Sync Management, Configuration Set Management, Real Time Metrics, Contact Search, and Historical Metrics are turned off for the SupervisorPolicy, the ExampleSupervisor user logs into the application and is presented with the following menu, based on the policy definitions:

Calendar Management Permissions - (v6.4.0+)

Closures & Holidays

Holidays and Closure permissions have similar behavior.

• Only Admin users can create/delete the resource and associations.

• Granting Read access to a resource will allow the user to view the resource and its related prompts.

  

• Granting Write access will allow the user to modify the resource and view the related prompts.

  

• Prompts are a shared resource which can be shared by multiple closures/prompts.

  • i.e. QueueA and QueueB use the same IsClosed prompt. QueueA user modifies the prompt, which takes effect in QueueB also.

  • For this reason you must explicitly grant Write access to prompts.

• 

Hours of Operations

• Only Admin users can create/delete hours and associations

• You can grant Read access.

  

• You can grant Write access, which allows the user to edit, but NOT associations

  

  

Config Set Permissions

• Only Admin users can create/delete config sets

• You can grant Read access.

  

  

• You can grant Write access, which allows you to edit prompts and attributes. You can also create new languages for an existing prompt

  

  

Connect Resource Permissions

The permissions in this section allow users access to functionality that can view and modify Connect resources.

Currently, the application menus that use these filters are Connect User Management, Real-time Metrics, and Contact Search.

The Connect User permissions can be specified at the individual user level, but more often an application user will need to manage a group of users, so there are many options available to filter the user permissions.

ROUTING_PROFILE will display available Routing Profiles to grant access to users through Routing Profiles.
SECURITY_GROUP will display available Security Groups to grant access to users through Security Groups.
USER_NAME will display controls for each user so access can be granted to manage users individually.
USER_HIERARCHY will show hierarchies based on existing assignments. To add more hierarchy levels, use the drop-downs under each level and click “Add Filter” to add the hierarchy to the results and manage permissions.

Other Connect Resources are managed in a similar manner, with the ability to grant ALL, READ, WRITE, DELETE or to DENY all permissions for each resource.

Connect Action Permissions

This allows access for users of the application to update the Routing Profile in the Connect User Management section. The toggle is either off or on and updates are allowed based on permissions granted or denied on the Connect User Resource.