Skip to main content

Attribute-based access control for recordings, transcripts, evaluations, and surveys

Use attribute-based access control (ABAC) policies to control access to recordings, transcripts, AI summaries and insights, quality evaluations, and surveys associated with a conversation. Base these policies on the customer access attribute so that access can follow who the customer is and what the conversation is about, rather than only the divisions that the conversation touched.

Role-based access control (RBAC) with divisions grants a user access to a conversation if the user has a role bound to any division that an object in that conversation passed through, such as a queue, flow, or participant. For organizations with multiple lines of business or regions, this access can be broader than intended.

ABAC adds a layer of access control that Genesys Cloud evaluates before RBAC:

  1. Genesys Cloud evaluates the applicable ABAC policy against the customer access attribute on the conversation.
  2. If the policy denies access, the user cannot access the data, regardless of their roles.
  3. If the policy authorizes access, Genesys Cloud applies the existing RBAC checks, including permissions, permission conditions, and divisions.

ABAC does not replace RBAC. A user must be authorized by both. ABAC policies also apply to the APIs that govern access to the supported recording, speech and text analytics, and quality management artifacts.

Note: If your organization has no ABAC policies for these targets, access control does not change. ABAC policies take effect only after you create them.

Policy targets

Each artifact type is a separate target, so you can apply different policies to each one. For example, you can base recording and transcript access on the customer’s profile and evaluation and survey access on the agent’s profile.

Targets use the domain:entity:action format.

How access works

When access attribute filtering takes effect

When your organization configures its first conversation access attribute, access-attribute filtering for quality evaluations and surveys can take up to 30 minutes to apply across all servers. This is a one-time delay when your organization first adopts conversation access attributes and requires no action.

During this period, some users may still see evaluations or surveys that access-attribute filtering would otherwise hide, depending on which server handles the request. Role-based permissions and division access continue to apply normally.

After the initial period, access-attribute filtering applies to all of your organization’s evaluations and surveys, including existing ones. Subsequent changes to conversation access attributes are not subject to this initial delay.

Organizations that already use conversation access attributes and organizations that never configure them are unaffected.

What ABAC does not control

The following are not restricted by these ABAC policies, and their behavior does not change.

Existing conversations

Conversations created before you set up the Customer Access Attribute have an empty value. ABAC treats an empty value as null. To keep access to older conversations unchanged, write policies that authorize access when the attribute is null or empty. 

Troubleshooting

When ABAC denies a request, the API returns a 403 error with an ABAC-specific message. This helps distinguish an ABAC denial from an RBAC permission denial.