What is review assist?

Review assist is a calculated recommendation for determinations on access requests for data access. It monitors the final access request determination made by humans (your data stewards), and finds trends. Then, based on those trends, it will recommend for an access request to be approved, temporarily approved, or denied.

When finding trends, it looks across factors that determine access approvals, temporary approvals, or denials:

1. The data product or asset itself; trend tracking is per data product or asset.

2. Metadata about the requestors, such as the groups and attributes they possess.

An AI-generated justification for the decision will accompany the recommendation and pre-populate in the access request response to submit with the access determination. This AI-generated justification is based on the trends across the factors listed, as well as prior human-entered justifications. For temporary approvals, review assist also considers past temporary approvals to determine the recommended duration.

The review assistant provides a risk score to instill confidence and will show a low risk for determinations that align well with the trend. The risk will increase in severity the more differences it detects between the user requesting access and the previous determinations that were made.

• Low: The user has attributes or groups that align well with trends of other determinations and similar users were likely to be granted access. The review assistant is confident in the recommendation.

• Moderate: The user may have some attributes or groups that were within the trends of other determinations, but similar users were both approved and denied. The review assistant is less confident in the recommendation.

• High: The user does not have attributes or groups that were found in the other determinations and the review assistant cannot make a determination based on those trends.

What does review assist do?

Here is an example that considers the factors: the data product and the user metadata.

Past requests for data product: Company data

Denials appear to be strongly correlated with being in the Intern group (and approvals are correlated with not being in the Intern group).

Now we have a new request for data product Company data:

Review assist would recommend to approve this request since Clete is not in the Intern group. So the data steward would see this recommendation, along with an AI-generated justification:

Your request is considered LOW risk because a high percentage of users with similar characteristics have been granted access, and there are no clear reasons to deny this request based on past approval decisions.

These recommendation details help the steward understand why his request should be appropriate to approve. Since they’re based on past data stewards’ similar determinations, the steward can feel confident in their approval decision. Once approved, Clete will automatically be provisioned the data in the data platform and can query it immediately.

The steward can disagree with review assist's recommendation if this is a unique user. They simply need to change the determination and edit the justification.

When can I use review assist?

Review assist will automatically appear on access requests when available. This will be whenever a trend is detected and could require more than 7 human-managed determinations.

If it has enough determinations, but a trend is not clear, it will recommend a temporary approval. This temporary approval will be recommended for a duration matching previous determinations or a reasonable default if no previous determinations are available.

How does review assist work with multiple approvers?

Review assist only takes into account the final determination of an access request. This means that if you have an access request with 3 differing determinations, only the final, most-restrictive determination will be considered by the review assist in future recommendations.

Limitation

Review assist is only available with access requests for data access; it is not available with masking exceptions.

Request forms are reusable and detailed forms that dictate the details data stewards have about the requesters making access requests. Request forms can be attached to

• Data products: When attached to a data product, one request form is used for both data access requests and masking exception requests.

• Assets: When attached to assets, separate request forms can be designated for access requests and masking exception requests.

Request forms can be attached to multiple assets and data products. Request forms dictate the same access request process for any asset or data product that uses them, providing consistent and reliable information from the requesters to the data stewards making determinations.

Request form details

Request forms contain the following content:

• Form details: Details about the request form such as the name and request questions. Request questions are the questions a data consumer must answer, and the answers will be recorded in the access request for the data steward to review.

• Review flow: The review flow configures if the access request requires approval or not, the data stewards who will approve the requests, or the ability for data product owners to select their own data stewards.

  • Review flows can delegate to the data product or asset rather than being tied to the request form itself, if desired. However, tying data stewards to the request form itself allows them to edit the request form questions.

Adding request forms to assets

Request forms are hierarchical, so for example, any attached to the schema will also be used for the tables within that schema. The governance user can also override the hierarchy and apply request forms to specific assets, like tables.

You should have your most restrictive request forms for databases and schemas. If your most restrictive request forms are at the table level, data consumers can easily bypass them by requesting access to the less-restrictive database or schema instead.

Similarly, review flows can be inherited through the hierarchy. However, the request form review flow always takes precedence. This means that if data stewards are assigned in the request forms, the review flows assigned or inherited through the asset hierarchy are Inactive.