Create Access Policies

AI-generated summary

Genesys Cloud provides a comprehensive attribute-based access control (ABAC) system that enables organizations to implement granular permission management through customizable policies and prebuilt templates. The system supports two policy application types: global policies that apply conditions to all API requests, and targeted policies that apply conditions to specific domains, entities, and actions. Policy creation involves defining subject, effect, and condition sections in Policy JSON format, with automatic syntax validation that checks for mandatory fields, valid attributes, data type comparisons, and preset attribute conflicts. Administrators access policy management through Admin > People & Permissions > Access Policies and can create policies from scratch or modify existing templates. Key prebuilt templates include "Cannot Grant New Roles," which prevents non-admin users from granting roles they lack; "Cannot Update Certain User Profile Fields," which restricts user profile modifications to supervisors and administrators; "Access Control for Gamification Scorecard and Insights," which enforces organizational hierarchy-based access where supervisors view direct reports' data, managers of managers access up to three levels deep, and administrators retain full access; "Allow Access from Certain IP Addresses," which enables granular restrictions based on connecting IP addresses or ranges; and "Allow Only During a Time Frame," which restricts access to specific time ranges and days with customizable parameters including optional time zone specification. Policy conditions support multiple attribute types, including "profile.fields" for case-insensitive checks on restricted user profile field modifications and "subject.role.names" for verifying manager role authorization. The system includes preset attributes such as admin.role.names, which can include admin and masterAdmin roles with support for custom admin roles added as comma-separated values. Implementation requires specific authorization permissions (policy: All Permissions, Add, Delete, View) and enabling the Attribute-Based Access Control organization setting. Administrators can test policies before deployment using the Test Policy tab with sample data and enable policies immediately through the Enable Policy toggle or defer activation for later. When both Allowed IP Address and ABAC Global Policies are configured, the IP list configured in the Allowed IP Address feature takes precedence and is evaluated first; Genesys recommends using either feature individually rather than both simultaneously for configuration simplicity. Preset attributes can be edited individually or by section name, with detailed documentation available for supported attributes and restricted fields.

PrerequisitesClick to expand

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:
- Access Control for Gamification Scorecard and Insights
- Allow Access from Certain IP Addresses
- Allow Only During a Time Frame
- Cannot Grant New Roles
- Cannot Update Certain User Profile Fields
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.
Note:
- For more information about fields used in Policy JSON, see the Definitions used in the ABAC section.
- 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.
- For a detailed information about access policy attributes, see Attribute-based access control.
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:

Access Control for Gamification Scorecard and InsightsClick to expand

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 .

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.

Screenshot showing JSON of gamification ABAC policy.

For more details about the parameters and conditions in this policy, see the Attribute-Based Access Control (ABAC) for Gamification article in the Developer Center.

Allow Access from Certain IP AddressesClick to expand

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.

Screenshot showing policy JSON of Allowed IP address policy.

For more details about the parameters and conditions in this policy, see the Attribute-Based Access Control (ABAC) article in the Developer Center.

Impact of the Allowed IP Address feature

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.

Allow Only During a Time FrameClick to expand

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.

Screenshot showing ABAC policy for timeframe restriction.

For more details about the parameters and conditions in this policy, see the Attribute-Based Access Control (ABAC) article in the Developer Center.

Note:

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).

Cannot Grant New Roles templateClick to expand

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.

ABAC Policy editor depicting Cannot Grant New Roles template

This template has the following two conditions:

Condition 1

"subject.role.names": {
"contains_one": "admin.role.names"
}

This condition checks whether the subject has an admin role. If the subject has an admin role, the result is Allow.

Condition 2

"subject.role.names": {
"contains_one": "authorization.grant.role.name"
}

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.

Cannot Update Certain User Profile FieldsClick to expand

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 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.

ABAC Policy editor depicting Cannot Update Certain User Profile Fields template

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.

Condition 1

"profile.fields": {
"contains_none_ignore_case": "restricted.fields.value"

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.

Condition 2

"subject.role.names": {
"contains_one": "manager.role.names"

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.

Shows example data for the Cannot update certain user fields template

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.
Note:
- For more information about fields used in Policy JSON, see the Definitions used in ABAC section.
- For more information about the preset attributes list used in Policy JSON, see Restricted fields value list.
- For a detailed information about access policy attributes, see Attribute-based access control.
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.
To go back to the policies page, click Cancel.

[NEXT] Was this article helpful?

Get user feedback about articles.