Controlling user access

From Genesys Documentation
Revision as of 02:33, July 25, 2020 by WikiSysop (talk | contribs) (Text replacement - "\|Platform=([^\|]*)GenesysEngage-onpremises([\|]*)" to "|Platform=$1GenesysEngage-cloud$2")
Jump to: navigation, search
This topic is part of the manual Callback Administrator's Guide for version Current of Callback.

You can limit user access within the Callback UI to what is appropriate for each user's role. This article describes the predefined Access Groups and Callback Roles to which you can assign users and includes information about how to restrict user access to callback information based on your lines of business. If you are migrating Roles and Access Groups from an earlier version of Callback, be sure to read the note related to this activity.

Related documentation:

If you do not configure access and activity restrictions for a user, then that user has full access to everything in the Callback UI. Genesys provides predefined Callback Roles that administrators assign to users. Each Role includes permissions that control what users can see and do in the UI. For example, to perform their duties, it is sufficient for some users to view the list of callback records in the Callback UI, without the ability to modify a callback in any way. Other users might require additional permissions; for example, some users might require access permissions that allow them to create, cancel, and modify callbacks and to view errors associated with callbacks.

Review Platform administration for detailed information about which applications and documentation to use to create or modify Roles and Access Groups or to assign users to these groups.

Migration of Roles

If you have not yet moved to the Roles and Access Group settings described on this page, the original method for configuring Callback access still applies to your setup. In the original configuration, Callback access was granted when the ges or gms section in the Person object's annex included a role option (for example, Administrator).

To move to the new configuration method for granting access, add your user to the correct Callback or custom Access Group and remove the ges or gms section. If you don't remove the ges or gms section, the old configuration applies and the Access Group is not taken into consideration.

Callback Roles

Genesys provides the following default Callback Roles:

  • Callback Administrator—Callback Administrators have full access to the Callback UI, which includes the ability to create, cancel, and reschedule callbacks, and to export reports. Users with this Role can also access all of the Developer tab features.
  • Callback Supervisor—Supervisor users have full access to the Callback tab in the UI, which includes the ability to create, cancel, and reschedule callbacks, and to export reports. They cannot access the Developer tab in the UI.
  • Callback Monitor—Monitor users can only view callbacks.
  • Callback Developer—Developer users can view callbacks on the Callback tab and have full access to the Developer tab, which includes the ability to view recent errors, test API keys, and to provision Callback.

If a user is a member of more than one Role, the Role that allows the most access to Callback features takes precedence.

Predefined Access Groups

By default, Genesys defines a list of Access Groups and adds Callback Roles to some of these groups, as described below. Users who are already in these Access Groups are given Callback permissions by default. For example, any user in your Administrators Access Group is automatically granted the Callback Administrator Role.

Important
The Access Group name is prefaced with your company's business name if the Access Group is not Callback-specific. For example, if your business name is ACME, then the Access Group for Administrators is called "ACME Administrators".
Access Group Callback Administrator Role Callback Supervisor Role Callback Monitor Role Callback Developer Role
Administrators      
Supervisors      
Managers      
Callback Developers      

Line of Business segmentation

By default, all users who are part of standard Access Groups and can access the Callback UI will have Read permission for all the virtual queues. To restrict access to queues based on your lines of business, you can create custom Access Groups and enable or disable Read permissions as required.

Any time you provision a virtual queue in Designer's CALLBACK_SETTINGS data table, the Callback service (virtual queue) automatically creates a Script object in Platform Administration > Scripts > Callback. The created Script object has the same name as the virtual queue and is prefixed with the ges_ label. For example, if you create a virtual queue called Sales_VQ, there will be a Script object called ges_Sales_VQ in the Callback directory.

To control access to queues based on your lines of business, you must create Access Groups for your various lines of business and then enable or disable access to the script objects that represent the virtual queues for each group. For a user to access a specific queue, the Access Group to which the user belongs must have the Read permission for the script object that represents that queue. The Read permission is assigned by default to all Access Groups, which means that all Access Groups can access all virtual queues until you change the permissions. To deny access to a virtual queue, navigate to the Script object associated with the queue and remove the Read permission from Access Groups that do not require access to that queue.

For example, if your Tenant has two lines of business called Sales and Service, you could create two Access Groups for Callback: Sales and Service. Then, navigate to each script object representing these queues and add the Access Group with Read permission:

  • In the ges_Sales_VQ Script object, retain the Read access for the Sales team and disable the Read permission for the Service team.
  • In the ges_Service_VQ Script object, retain the Read access for the Service team and remove the Read permission from the Sales team.

To set permissions on groups of virtual queues (instead of one at a time), create subfolders under the Scripts > Callback folder and apply appropriate permissions to the subfolder. Then, move the Script objects representing the various virtual queues into the corresponding subfolder. Any Script object that is in a subfolder will inherit the permissions of that subfolder.

Check the Propagate box to apply the permissions to any object that is in the folder. The permissions apply to any virtual queue that is in the subfolder now and will apply to any new virtual queue that you add to the subfolder in the future.

OLD Setting Permissions to Limit User Access and Actions

On the Genesys Portal, open the Platform Administration application and select Configuration. In the Accounts menu, select Persons - BROKEN LINK - to get the list of configured users.

Open the properties for a Person who will be logging into the Callback application. You are going to add a configuration option that assigns Administrator-level access permissions to this Person object.

OLD

On the Options tab for the selected Person, add an option. Enter ges for the section and roles for the key.

Important
Older deployments might use the gms section name. That continues to be a supported entry.

Enter a value that matches the level of access that you are granting to this Person. In this example, we are assigning Administrator-level access permissions to the Person object.

Valid values for the roles key are:

  • Supervisor
  • Developer
  • Administrator

The Supervisor and Developer roles limit user access to tabs in the Callback UI as well as user activities within the tabs to which they have access. The Administrator role has full access to the Callback UI. Each feature description in this Callback documentation includes information about which roles are required for access.

You can specify more than one value for the roles option. When multiple values are assigned, the value that allows the most access to Callback features takes precedence.

Comments or questions about this documentation? Contact us for support!