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

Search restriction uses an attribute called Restriction Source Attribute (RSA). The RSA is the organization-level setting that identifies which custom user attribute holds the values a user is allowed to search against. You can set the RSA separately for each item type such as conversation, transcript, evaluation, and work item. If no RSA is set for an item type, search for that item type works without any restriction.

When a user searches for a conversation, search restriction limits the conversations that users can find in a search by comparing the values on each user’s profile with the customer access attributes on conversations. Restricted conversations are removed before results are returned. Search restriction applies to the interactions view, conversation search, content search, and quality management evaluation search and query.

When a user runs a search on restricted artifacts such as conversations, Genesys Cloud performs the following:

Identifies the custom user attribute that is configured as the RSA.
Reads the user’s values from that attribute.
Adds a restriction to the search query so that only matching conversations can be retrieved.

Because the restriction is applied when the query is built, unauthorized conversations are not retrieved and filtered afterward. Restricted conversations do not appear in results, result counts, sorting, or relevance ranking. Changes to a user’s values apply to that user’s next search.

Matching is exact, and a conversation is returned only if the user has every customer access attribute value on that conversation. For example, a user whose attribute contains GermanWealth and SwissBanking can find a conversation tagged GermanWealth. The same user cannot find a conversation tagged GermanWealth and SensHigh, because the user does not have SensHigh. Extra values on the user’s profile do not affect the result.

Conversations that have no customer access attribute are also returned, so that existing searches continue to work. A user whose attribute contains All is not restricted by customer access attribute values and can find all conversations. The value All is not case-sensitive. A user who has no values in the attribute can find only conversations that have no customer access attribute.

Search does not combine separate values with AND logic. To restrict search on a combination of attributes, represent the combination as a single value, such as LegalEntity:001|ClientCategory:Wealth, and use that same value in the user’s attribute and on the conversation. Use the same delimiter, order, and casing in both places.

Search restriction works together with existing role and division permissions. It does not grant access that a user’s roles and divisions do not already allow. It is also separate from ABAC policies, which control access to a conversation after it is requested.

Search restriction applies to searches made by signed-in users. Requests made with client credentials do not use the RSA. Their search access is governed by the OAuth client’s permissions and divisions. Aggregate views, such as Performance views and survey aggregate reporting, are not restricted.

You can create, read, update, and delete the RSA through the API. In the API, the RSA is called the default search criteria. For more information, see the Authorization section in API Explorer for the requests (/api/v2/authorization/customattributes/itemtypes/{itemType}). To create or update the RSA, specify the schema name and attribute name of the custom user attribute. The attribute must be a string or a list of strings. To manage the RSA, you need the following permissions: Authorization > Default Search Criteria – Add, View, and Delete.

Search experiences that are restricted

Search restriction applies to the following in-scope experiences:

Interactions view and conversation search, where users search or filter interactions by metadata such as date, queue, user, ANI/DNIS, media type, wrap-up, division, external contact, or conversation ID. Unauthorized interactions are not returned as blank, partial, or masked rows.
Content search and transcript search, where users search transcripts by word or phrase.
Quality management evaluation search and query.

Search experiences that are not listed above continue to use their existing access controls for users. Aggregate performance views and survey aggregate reporting are not subject to search restriction.

How matching works

Search restriction uses exact matching with Contains All logic.

Exact match – values are compared as exact strings. Partial, fuzzy, similar, and derived matches are not supported. For example, GermanWealth does not match German, Wealth, or GermanWealthManagement.
Contains All – if a conversation has more than one customer access attribute value, the conversation is returned only when the user’s RSA values include every one of them. The user can hold additional values that the conversation does not require.

Special cases

Situation	Behavior
The user has the value ALL in the RSA attribute.	The user is not restricted by customer access attribute values. Existing permissions and division access still apply.
The conversation has no customer access attribute.	The conversation is returned by default, subject to existing permissions and division access. No special RSA value is needed.

Note: Search restriction adds Customer Access Attribute scoping to existing controls. It does not replace roles and divisions.

Examples

Exact MatchClick to expand

Sarah’s RSA values are GermanWealth and SwissBanking.

Conversation	Customer access attribute values	Returned?	Reason
1001	GermanWealth	Yes	Matches one of Sarah’s values.
1002	SwissBanking	Yes	Matches one of Sarah’s values.
1003	GermanRetail	No	Does not match any of Sarah’s values.
1004	GermanWealth, SwissBanking	Yes	Sarah has every value the conversation requires.

Multiple values on a conversationClick to expand

Sarah’s RSA values are 001 and 033.

Conversation	Customer Access Attribute values	Returned?	Reason
2001	001	Yes	Matches.
2002	033	Yes	Matches.
2003	044	No	No match.
2004	044, 001	No	Sarah does not have 044, so not every required value is present.

Model compound entitlements as a single valueClick to expand

Search restriction does not evaluate AND or OR conditions across separate Customer Access Attributes. If you want a user to find conversations only when more than one condition is true, represent the combination as one value, and use the same value in both the user’s RSA attribute and the conversation’s Customer Access Attribute.

For example, to let Sarah find conversations where the legal entity is Germany and the client category is Wealth, give Sarah the RSA value Germany_Wealth and tag conversations with Germany_Wealth.

Conversation	Customer Access Attribute values	Returned for Sarah (Germany_Wealth)?	Reason
4001	Germany_Wealth	Yes	Exact match.
4002	Germany_Retail	No	Exact match fails.
4003	Switzerland_Wealth	No	Exact match fails.
4004	Germany, Wealth (two separate values)	No	Separate values do not match the combined value.

If you model search with separate dimensions but write an ABAC policy that requires both to match, a user might find a conversation in search that the policy later denies, or the reverse. To keep results consistent, treat the RSA as your search authorization model and make sure the ABAC policy uses the same segments.

Search restriction compared with ABAC policies

	Search restriction	ABAC policy
What it controls	Which conversations a user can find	Whether a user can access a protected resource
When it is applied	When the search query is built	When the resource is requested
How it evaluates	Exact match against RSA values	Policy conditions, including AND and OR logic

The two work together. A user can be allowed to find a conversation and still be denied access to its recording by an ABAC policy.

Considerations

Search restriction applies to requests made in the context of a user. OAuth clients that use the client credentials grant do not carry a user or custom user attributes, so the RSA is not used for them. Their search access continues to follow the client’s permissions and divisions.
If your organization has not configured an RSA, search behavior does not change.

[NEXT] Was this article helpful?

Get user feedback about articles.