Access Policies (Attribute-Based Access Control)

What Are Access Policies?

Access Policies implement Attribute-Based Access Control (ABAC) — a layer of fine-grained permission logic that works alongside RBAC (Roles & Permissions) and Divisions.

Where RBAC answers "does this role have this permission?", ABAC answers "given the attributes of this user, this resource, and this environment — should access be allowed or denied?"

ℹ️ ABAC does not replace Roles or Divisions. It augments them. Authorization requires both ABAC policy evaluation and standard permission checks to pass.

Enable ABAC First

Before any access policies take effect, you must enable the feature at the org level:

Admin → Organization Settings → [toggle] Enable Attribute-Based Access Control

Policies can be created and saved before enabling, but they will not be enforced until the org setting is on.

Core Concepts

The Three Attribute Types

Attribute Type	What It Describes
Subject	The user or entity requesting access (their roles, division, group membership, etc.)
Resource / Object	The thing being accessed (a user profile, a recording, a gamification scorecard, etc.)
Environment	Contextual factors (IP address, time of day, etc.)

Policy Structure

Each policy contains:

Element	Description
Name	Identifier for the policy
Description	Purpose and context
Target	The API calls this policy applies to — written as `domain:entity:action` (e.g., `authorization:grant:add`)
Subject	Who the policy applies to — user, group, client, or all
Effect	`ALLOW` or `DENY`
Conditions	Boolean logic (Any = OR, All = AND) using `TypedAttribute` key-value pairs

Default-Deny Logic

⚠️ DENY overrides ALLOW. If a subject matches both an ALLOW and a DENY policy, access is denied.

Access is granted only when all three are true:

Subject satisfies an ALLOW policy's conditions

Subject has the required traditional permission

Subject does not match any DENY policy

The Three Built-In Policy Types

Genesys Cloud ships three pre-built policy templates covering the most common ABAC use cases:

1. Cannot Grant New Roles

Purpose: Prevents non-admin users from granting roles they do not themselves hold.

Use case: Stops a supervisor from escalating privileges by assigning a role they don't have to another user — even if they technically have the authorization:grant:add permission.

How it works:

Checks if the subject is an admin

Checks if the subject already has the role being granted

If neither condition is true → DENY

2. Cannot Update Certain User Profile Fields

Purpose: Prevents specified profile fields from being modified by regular users — while still allowing supervisors or admins to edit them.

Use case: Lock fields like employee ID, HR data, or contact info so agents cannot self-edit them, but managers can still update them.

How it works:

Uses profile.fields condition — case-insensitive check against a list of restricted field names

If the field being modified is in the restricted list AND the subject does not have a manager-level role → DENY

Restricted field values (configured in policy JSON as preset attributes):

Category	Example Field Values
Name	`name`, `name.firstName`, `name.lastName`
Contact Info	`contactInfo`, `contactInfo.phone_work`, `contactInfo.phone_work_2`
HR Fields	`hr` (entire section)
Images	`images`, `images.profile`
Biography	`biography`
Location	`location`
Relationships	`relationships`

ℹ️ Using a section name (e.g., contactInfo) restricts the entire section — equivalent to contactInfo.*. Add specific sub-fields only when partial restriction is needed.

Full list: Admin → People & Permissions → Access Policies → Templates → Cannot Update Certain User Profile Fields — or see the Genesys Resource Center Restricted fields value list.

3. Access Control for Gamification Scorecard and Insights

Purpose: Limits supervisors to viewing gamification data only for agents within their reporting hierarchy, while admins retain full access.

How it works (hierarchy tiers):

Role	Access Scope
Supervisor	Direct reports only
Manager of managers	Up to 3 levels deep in hierarchy
Admin (designated role)	Full access to all gamification data

Use case: Prevents supervisors from browsing gamification performance data for agents outside their team.

Creating an Access Policy

Option A — From a Template

Admin → People & Permissions → Access Policies

Click Templates

Select the desired template

Modify the domain, entity, and action fields in the target if needed

Edit the subject, effect, and condition sections in the Policy JSON

Optionally toggle Enable Policy to activate immediately

Click Save

Option B — From Scratch

Admin → People & Permissions → Access Policies

Click Create Policy

Write the full Policy JSON manually

Use Validate Syntax tab to check for errors before saving

Policy JSON Syntax

{
  "name": "Policy Name",
  "description": "What this policy does",
  "targets": [
    {
      "domain": "authorization",
      "entity": "grant",
      "action": "add"
    }
  ],
  "subject": {
    "type": "user"
  },
  "effect": "DENY",
  "conditions": {
    "all": [
      {
        "attribute": "subject.role.names",
        "operator": "notContains",
        "value": "Admin"
      }
    ]
  }
}

Condition operators: equals, notEquals, contains, notContains, startsWith, in, notIn

Logical operators:

any → OR (at least one condition must be true)

all → AND (every condition must be true)

These can be nested for complex logic

Validation and Testing

Before deploying a policy:

Click Validate Syntax tab — checks for:
- Missing mandatory fields
- Invalid attributes
- Incorrect data type comparisons
- Preset attribute conflicts

Click Test Policy tab — paste sample subject/resource/environment data and run a simulated evaluation to confirm expected ALLOW/DENY result before enabling

Enabling and Managing Policies

Action	How
Enable a policy	Toggle Enable Policy on the policy detail page
Disable a policy	Toggle off — policy is retained but not enforced
Edit a policy	Admin → Access Policies → select policy → Edit
Delete a policy	Admin → Access Policies → select policy → Delete
View all policies	Admin → Access Policies → table view with status

Permissions Required

Action	Permission
Create / edit / delete policies	Authorization > Policy > Add, Edit, Delete
View policies	Authorization > Policy > View
Enable ABAC org setting	Organization Settings admin access

⚠️ The ABAC feature itself must be enabled in Organization Settings before any policies are enforced, regardless of permissions.

Important Behaviours and Gotchas

DENY always wins — if a user matches both an ALLOW and a DENY policy, they are denied

ABAC + RBAC are additive — a user needs both the RBAC permission AND to satisfy the ABAC ALLOW policy to gain access

Policies apply immediately after enabling — test in non-production if possible

Preset attribute names must use only alphanumeric characters, periods, or underscores — no spaces or special characters

profile.fields condition is case-insensitive — field name matching does not require exact case