Create Access Policies

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.

Create an access policy from a prebuilt template

To create an access policy from an existing policy template, do the following:

Click Admin.
Under People & Permissions, click Access Policies.
Click Templates.
Select an existing template. Currently, Genesys Cloud provides the following access policy templates for you to get started:
- 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.
Modify the domain, entity, and action fields if you’re specifying a different target for the policy.
(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, and condition 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 ABAC section.
- For more information about 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 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

Currently, Genesys Cloud includes the following access policy templates:

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.

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

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.

Create an access policy using the Create Policy feature

To create an access policy from scratch, do the following:

Click Admin.
Under People & Permissions, click Access Policies.
Click Create Policy.
Enter the policy name and description.
Specify the domain, entity, and action fields based on your policy requirements. You can refer 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.