Genesys Cloud provides access policy creation capabilities through both custom policies and prebuilt templates to enforce attribute-based access control (ABAC) within organizations. Users must possess specific authorization permissions and enable the ABAC organizational setting to implement access policies. Policies can be created from scratch or adapted from prebuilt templates, including Access Control for Gamification Scorecard and Insights, Allow Access from Certain IP Addresses, Allow Only During a Time Frame, Cannot Grant New Roles, and Cannot Update Certain User Profile Fields.
The platform supports two policy types: Global Policies that apply conditions to all API requests, and Targeted Policies that restrict conditions to specific domains, entities, and actions. Policy configuration requires editing name, description, policy type, and Policy JSON sections containing subject, effect, condition, and preset attributes. Genesys Cloud enforces a constraint that only one policy per target-subject combination can exist; additional conditions for the same combination must be added to the existing policy.
The gamification ABAC policy restricts data visibility based on organizational hierarchy, allowing supervisors to view agent data within their reporting structure, managers of managers to access data up to three levels deep, and administrators to retain full access. The IP address policy enables access control based on connecting IP addresses or ranges, though the Allowed IP Address feature in Organization Settings takes precedence over ABAC policies. The time-frame policy restricts user access during specified time ranges on particular days, supporting use cases such as limiting agent login hours to business hours, with optional timezone specification that defaults to UTC if omitted.
The "Cannot Grant New Roles" template prevents non-administrative users from granting roles they do not possess, while the "Cannot Update Certain User Profile Fields" template prevents unauthorized modifications to defined user profile fields, allowing only supervisors and administrators to make changes. Administrators can customize restricted fields by individual fields, section names, or combinations thereof, and custom admin roles can be added to preset attributes lists as needed.
The platform includes built-in syntax validation to verify mandatory fields, attribute validity, data type comparisons, and preset attribute conflicts. Policies can be enabled immediately upon creation or activated later, and include a Test Policy feature allowing administrators to validate functionality using sample data before deployment. The interface provides navigation options and feedback mechanisms for documentation improvement, with related articles available for attribute-based access control, access policy management, user profile fields, and IP address configuration.
The following permissions:
All permissions under Authorization > policy
The following organization setting:
Ensure that you enabled the Enable Attribute-Based Access Control setting for your organization to enforce the application of access policies on users.
You can create a new access policy from scratch by using the Create Policy option or use an available Genesys Cloud designed prebuilt policy template, edit it, and save it as a policy.
Note: You can have only one policy with the same target and subject combination. If you must create more conditions for the same target-subject combination, add them to the existing policy.
Create an access policy from a prebuilt template
To create an access policy from an existing policy template, do the following:
Click Menu > User Management > Access Policies.
Click Templates.
Select an existing template. Genesys Cloud provides the following access policy templates for you to get started:
Click the policy template based on your requirement. The template details appear.
Edit the policy name and description.
Select the Policy type. You can select one of the following policy types.
Global Policy – if you want to apply the policy conditions on all API requests, select the policy as a global one.
Targeted policy – if you want to apply the policy conditions only on a specific domain, entity, and action, select the policy as a targeted one.
For targeted policies, select the target Domain, Entity, and Action fields.
(Optional) Allow the policy to be enabled immediately by toggling the Enable Policy option. You can also enable a policy later by editing the policy. For more information, see Enable Access Policy.
Modify the subject, effect, condition, and preset attributes sections in the Policy JSON, if necessary, to meet your organizational needs.
For more information about supported user profile fields for the Cannot Update Certain User Profile Fields template, see the List of supported user profile fields article.
To validate the JSON syntax, click Validate Syntax in the Validate Syntax tab. Resolve any syntactical errors, and proceed with saving the policy. In case you don’t validate syntax explicitly, Genesys Cloud automatically validates syntax when you save the policy. The syntax validation step validates the following:
Whether the mandatory fields are available.
The listed attributes are valid for the specified target.
All attribute comparisons are valid for their respective data types.
Any preset attribute names don’t conflict with the ones defined in the system.
Click Save as Policy.
To verify if the policy works as expected, click the Test Policy tab and provide sample data and click Test Policy.
To go back to the policies page, click Cancel.
Sample prebuilt templates
Genesys Cloud includes the following access policy templates:
This policy template is designed to prevent access to gamification data based on their role and position in the company hierarchy.
Note: The gamification ABAC policy is applied to the user profiles in addition to the gamification permissions.
When you enable this policy, it enforces the following restrictions:
Supervisors can only view gamification data for agents within their reporting hierarchy.
Managers of managers can view data up to three levels deep.
Administrators retain full access regardless of hierarchy.
This policy template is designed to allow or deny users’ access to Genesys Cloud based on their connecting IP address or the IP address range. Use this policy to apply granular restrictions in line with your corporate security policies.
You can modify the template parameters in the Policy JSON such as IP address, IP address range, allowed IPs and so on.
You can also limit access to the Genesys Cloud account only to those users who visits from a specific IP address. To enforce the IP address limitation, use the Allowed IP Address feature in Organization Setting.
You can use both Allowed IP Address and ABAC Global Policies, but note that the IP list that is configured in the Allowed IP Address feature takes precedence and it is evaluated first. Therefore, the IP address list configured in ABAC policy must be a subset of the Allowed IP Address list.
Though the Allowed IP Address and ABAC Global Policies feature complements each other, Genesys recommends using one or other of these features for configuration simplicity, but not both.
This policy template is designed to allow or deny users’ access to Genesys Cloud based on a specific time range on specific days. Use this policy to apply granular restrictions in line with your corporate security policies. For example, you can create an allow or deny policy to restrict an agent log in time only during 9.00 am to 5.00 pm.
You can modify the template parameters in the Policy JSON such as day range, time range, and so on.
The template includes time zone information to specify the time zone to use. While it is optional, if the time zone is not included, the time range defaults to UTC. For more information about the day and time formats, see the Attribute Data Types section in the ABAC overview article in the developer center.
When you test the policy, the value you specify in the system.time field is the relative time from the current time in seconds (for example, 3600 = 1 hour from now).
This policy template is designed to prevent non-admin users from granting roles they do not themselves have.
You can modify template parameters in the Policy JSON: the domain, entity, and action fields specify the target, or group of API calls.
If the subject does not have an admin role, the action is allowed only if the subject already has the role that they are trying to grant. authorization.grant.role.name is an attribute, which contains the name of the role that the subject is trying to grant to either themselves or another user. So, for example, if the subject has a supervisor role but not an admin role, the result is Deny, if they attempt to grant an admin role. In this scenario, the admin role is not contained in the list of subject role names.
In this template, the preset attributes for admin.role.names can be a list containing the admin and masterAdmin roles. If you have other custom admin roles in your organization, you can add them to this list, separated by commas.
This policy template is designed to prevent defined user profile fields from being modified, except by supervisors or admins.
Note: This template contains attributes for all the fields displayed in the User Profile page. You cannot restrict a user from updating the fields that are not included in the User Profile page via an access policy, for example, WebRTC settings is not part of the User Profile page.
This template contains an ‘Any’ rule, which means that the policy returns a result of Allow if any of the specified conditions are met. The template has the following two conditions by default.
This condition checks if the user profile field being modified is not included in the restricted.fields.value preset attributes list and ignores case sensitivity in the comparison. If the field being modified is not on the list, then the result of this condition is True. You can edit the preset attributes list either as individual fields or as a section name or a combination of both, according to the needs of your environment. For more information about supported preset attributes, see restricted fields value list.
This condition checks whether the subject has a role that is included on the preset attributes list of manager.role.names. If the subject has any one of these roles, then the action is allowed.
Once the template has been saved as a policy, you can test the policy to confirm it works as expected. In the following example image, the subject has the admin role so the request is allowed, even though the profile field (agent.name) is included in the list of restricted fields.
Create an access policy using the Create Policy feature
To create an access policy from scratch, do the following:
Click Menu > User Management > Access Policies.
Click Create Policy.
Enter the policy name and description.
Select the Policy type. You can select one of the following policy types.
Global Policy – if you want to apply the policy conditions on all API requests, select the policy as a global one.
Targeted policy – if you want to apply the policy conditions only on specific domain, entity, and action, select the policy as a targeted one.
Specify the domain, entity, and action fields based on your policy requirements. You can refer to the prebuilt templates for creating your own policy.
(Optional) Allow the policy to be enabled immediately by toggling the Enable Policy option. You can enable a policy later by editing the policy. For more information, see Enable Access Policy.
Define the subject, effect, and condition sections in the Policy JSON based on your organizational needs.
To validate the JSON syntax, click Validate Syntax in the Validate Syntax tab. Resolve any syntactical errors, and proceed with saving the policy. In case you don’t validate syntax explicitly, Genesys Cloud automatically validates syntax when you save the policy. The syntax validation step validates the following:
Whether the mandatory fields are available.
The listed attributes are valid for the specified target.
All attribute comparisons are valid for their respective data types.
Any preset attribute names don’t conflict with ones defined in the system.
Click Save.
To verify if the policy works as expected, click the Test Policy tab and provide sample data and click Test Policy.