ABAC for conversations and conversation artifacts overview

AI-generated summary

Genesys Cloud combines Attribute-Based Access Control (ABAC) with Role-Based Access Control (RBAC) and divisions to provide granular access management through Boolean logic evaluation of user, resource, and environmental attributes. The system operates on a default-deny principle where DENY policies override ALLOW policies, and access is granted only when users satisfy ALLOW policy conditions, possess necessary permissions, and do not match any DENY policies. ABAC policies target specific API calls using domain:entity:action syntax and apply to defined user subsets through four core components: Target (the resource and action being performed), Subject (the user, group, or OAuth client to which the policy applies), Effect (ALLOW or DENY determination), and optional Conditions (specific criteria using JSON-formatted attribute comparisons). Authorization requires both ABAC policy evaluation and traditional permission verification using JSON-based conditional logic with Any/OR and All/AND operators. Policies are evaluated sequentially, with DENY policies immediately blocking access regardless of matching ALLOW policies, and access denied by default if a resource has attached policies but the user matches no conditions. Preset Attributes enable static value comparisons through TypedAttribute objects with strict naming conventions supporting only alphanumeric characters, periods, and underscores. Each preset attribute entry contains a key representing the attribute name and a value consisting of a TypedAttribute object with type (specifying the basic data type) and value (providing a string representation) members. Validation prevents conflicts with existing system attributes. Genesys Cloud provides four pre-built policy templates for common use cases: gamification scorecard access control limiting supervisor visibility to agents within three reporting hierarchy levels, IP address-based access restrictions, time-frame-based access control, and role assignment prevention for non-admin users. Only one policy per target-subject combination is permitted; additional conditions must be added to existing policies rather than creating duplicates. ABAC operates alongside existing role-based access controls rather than replacing them, requiring final permission verification before resource access is granted.

Use attribute-based access control (ABAC) to control which users can access individual conversations and its recordings, transcripts, evaluations, and surveys. ABAC works together with roles and divisions to limit exposure of sensitive customer data.

Roles and divisions control what a user can do and which objects they can reach. For conversation data, these controls can be broader than some organizations need. For example, two supervisors in the same division who need access to different customers because of legal entity, client category, or regulatory boundaries.

To address this, Genesys Cloud provides a layered access control model:

Component	What it does
Customer access attributes	Tags on a conversation that identify an access segment, such as a legal entity or client category.
Custom user attributes	Values on a user’s profile that define the segments the user is entitled to.
ABAC policies	Rules that compare a user’s attributes with a conversation’s customer access attributes and allow or deny access to a protected resource.
Search restriction	A search-time filter that returns only the conversations a user is entitled to find.
Roles and divisions	Existing permissions that continue to apply in every case.

How the controls work together

Genesys Cloud evaluates access in layers. A user must pass every layer that applies.

Roles and divisions determine whether the user has the required permission and division access.
ABAC policies determine whether the user can access a protected resource after they request it. Policies are evaluated at the time of access, so they apply to active conversations, historical conversations, and archived data.
Search restriction determines which conversations a user can find in supported search experiences.

In short, search restriction determines what a user can find, and ABAC determines what a user can access.

Assigning a customer access attribute to a conversation does not grant or deny access by itself. Access depends on the permissions and policies configured in your organization.

What ABAC protects

You can create ABAC policies for the following conversation resources. For the specific policy targets, see ABAC policy targets for conversation resources.

Conversations
Recordings, including recording segments, screen recordings, and snippet recordings
Recording annotations, retention, and deletion protection
Transcripts and AI summaries and insights
Quality management evaluations
Surveys

ABAC applies across the user interface, public APIs, and other supported access points for these resources.

How ABAC decisions are applied

Each resource is evaluated separately. Access to a conversation does not automatically grant access to its recordings, transcripts, evaluations, or surveys. Each is evaluated at its own access point, using the Customer Access Attributes of the parent conversation. A user can be allowed to see one artifact type and denied another for the same conversation.
ABAC is evaluated before role and division checks. If the policy allows access, the user’s role, permissions, and divisions are then applied as usual.
Decisions apply to the whole resource. ABAC allows or denies access to a resource. It does not hide individual fields, participant attributes, transcript segments, or other parts of a resource the user is allowed to see.
Policies do not affect routing. ABAC does not change routing, queue selection, skill evaluation, or conversation delivery. An agent can still be offered a conversation, but if a policy denies access, the agent cannot open the protected conversation data.
Denials are identifiable. Access denied by an ABAC policy returns a 403 response with a message that distinguishes it from a denial caused by roles or permissions.

Existing behavior is preserved

If you do not create an ABAC policy for a resource type, access control for that resource does not change.
If a conversation has no customer access attribute, existing role and division permissions continue to apply. Any ABAC policy that applies to the resource is also evaluated. Policies can define explicit behavior for empty or null values for customer access attributes.
Conversations created before you start using customer access attributes are treated as having empty values. If you create a policy that requires a value, those older conversations are denied unless the policy accommodates empty values.
Administrative actions, including user management and attribute assignment, remain governed by roles and divisions. Administrators can manage only the users and configurations within their authorized scope.

Example

An organization tags each conversation with a legal entity and gives each supervisor a custom user attribute that lists the legal entities the supervisor is entitled to. A policy on recording access allows a user to view recordings only when the user’s legal entity values include the conversation’s legal entity.

A supervisor with the Recording > Recording – View permission and the legal entity value GermanWealth opens a conversation tagged GermanWealth. The policy allows access, and the supervisor’s role permissions and divisions then apply as usual. If the conversation is tagged SwissRetail, the policy denies access to its recordings.

What is not covered

ABAC for conversations and their artifacts does not currently apply to external contacts, cases, calling lists, or other platform objects. These entities continue to use existing role-based and division-based controls. For the full list of exclusions, see Scope and limitations of ABAC for conversations.

[NEXT] Was this article helpful?

Get user feedback about articles.