Customer access attributes and custom user attributes 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.

Tag conversations with customer access attributes and define user entitlements with custom user attributes. Attribute-based access control (ABAC) policies compare the two to decide who can access conversation data.

Customer access attributes

A customer access attribute is a field on a conversation that identifies a customer-defined access segment, such as a legal entity or client category. A conversation can have more than one customer access attribute. Each attribute represents a separate access control dimension, for example LegalEntity and ClientCategory.

Each customer access attribute has a single value.
The value is a text string. The default maximum length is 36 characters, and the absolute limit is 100 characters.
Customer access attributes are saved as conversation-level metadata. They are available to ABAC policy evaluation, search restriction, and API enforcement.
To add, edit, or remove customer access attribute values on a conversation, you need the Conversation > Access Attributes – Edit permission.
To view the values, you need the Conversation > Access Attributes – View permission.

Note: Assigning a customer access attribute to a conversation does not grant or restrict access by itself. Access depends on the roles, divisions, and ABAC policies configured in your organization.

Conversations without a customer access attribute

If a conversation has no customer access attribute, existing role-based and division-based permissions continue to apply. Any ABAC policy that applies to the requested resource is also evaluated. Policies can explicitly allow or deny access when a customer access attribute value is null or empty.

Conversations that existed before you started using customer access attributes are treated as having empty values. If you want those conversations to remain accessible after you create a policy, write the policy to allow empty values.

Reporting and analytics

For native Genesys Cloud reporting, analytics, and search experiences, customer access attribute values support the access control and search restriction behavior. Because the values are part of the conversation metadata, other services that process conversation data might make them available. Whether those services filter or enforce access using the values depends on how each service is implemented.

Custom user attributes

A custom user attribute is a field that you define on user profiles to record a user’s entitlements. For example, a LegalEntity attribute might list the legal entities a user is allowed to work with.

To create custom user attributes and assign values to users through the API, performing the following steps:

Create custom attributes for user profiles by using the create schema API.
Assign specific values to users by using the assign custom attribute API.
Use the attributes in ABAC policies for supported policy targets. The policy compares the user’s values with the conversation’s customer access attributes to allow or deny access.

To define and assign custom user attributes to users, you must have the following permissions:

Users > Custom Attributes Schema – Add
Users > Custom Attributes Schema – Edit
Users > Custom Attributes Schema – Delete
Users > Custom Attributes Schema – View
Directory > User – Edit

Administrators can manage only the users and configurations within their authorized scope.

If you save an ABAC policy that references a custom user attribute that is not defined or is specified incorrectly, Genesys Cloud returns an error that describes the problem.

How policies compare the two

An ABAC policy compares a user’s custom user attribute values with a conversation’s customer access attribute values. The following examples are illustrative.

Policy condition	User’s attribute values	Conversation’s Customer Access Attribute	Result
The user’s values contain at least one value that matches the conversation	SwissBanking, GermanWealth	GermanWealth	Allow
The user’s values contain at least one value that matches the conversation	SwissBanking, GermanWealth	SwissRetail	No match, so this policy does not allow access
Legal entity matches and client category matches	LegalEntity = 001, ClientCategory = Wealth	LegalEntity = 001, ClientCategory = Wealth	Allow
Legal entity matches and client category matches	LegalEntity = 001, ClientCategory = Wealth	LegalEntity = 001, ClientCategory = Retail	The client category does not match, so this policy does not allow access

Policies can combine conditions with AND and OR logic. Search restriction is different. It uses exact matching and does not evaluate these policy expressions. For more information, see .

Non-user clients

OAuth clients that use the client credentials grant do not carry a user or custom user attributes. If an ABAC policy that references user attributes applies to an OAuth client, the unavailable attributes are evaluated as empty values. You can exclude OAuth clients from the policy and govern them with a separate client-specific policy or with their existing roles and divisions.

[NEXT] Was this article helpful?

Get user feedback about articles.