# Review Flows

Review flows define the approval process for access requests. When a user requests access to a data product, asset, or column (masking exception), the review flow dictates the data steward who must authorize that request or if it can be approved automatically.

## Configuration modes

When setting up a review flow within a request form, you must dictate how the reviewers (data stewards) are managed. There are two primary modes:

1. **In the request form (centralized)**: The review flow is defined directly within the request form. Every asset, data product, or column that uses this form will follow the same set of reviewers. This is ideal for standardized processes across the organization.
2. **Delegate (decentralized)**: The review flow is managed and set at the individual asset or data product. This allows local owners to configure their own specific reviewers. **This is ideal to provide flexibility for different departments or data types while still using the same underlying request questions.**

{% hint style="warning" %}
When using the delegate mode, stewards configured at the data product or asset level will not have permission to edit the request form's questions.
{% endhint %}

### Inheritance in assets

Review flows are inherited through the hierarchy in assets. However, the request form's defined 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**.

If you want to define review flows at the asset level, you must configure the review flow as **Delegate** in the request form.

## Automatic approval

In cases where data is low-risk or public, you can choose for access requests to be automatically approved. This removes the need for manual intervention by a steward. Additional information must be provided when opting for access requests to have automatic approval:

* **Justification**: You are required to provide a reason why this data should be automatically accessible. 
* **Duration**: A set duration can be provided so that users are granted temporary access to the data but must request access again once their limit is reached. You can set these approvals to **Never expire** (permanent access) or expire **After a set duration** (temporary access).

## Assigning data stewards

If manual review is required, the data stewards are assigned within the review flow. If an access request requires all data stewards' determinations, then for every group, attribute, or permission listed in the review flow, a data steward from that [source](#steward-sources) must make a determination. If a data steward qualifies for multiple sources, their determination will count for each of the sources they have.

See the [Understanding approval logic section](#understanding-approval-logic) to understand how assigning data stewards impacts determinations on access requests.

### Steward sources

You can select reviewers from several categories:

* **User**: A specific individual.
* **Group**: Any member of a specific user group.
* **Attribute**: Users associated with a specific metadata attribute.
* **Global permission**: Users with a global Immuta permission (e.g., `GOVERNANCE`).
* **Domain permission**: Users with a domain-specific permission (e.g., `Manage Data Products`) on the specific domain where the data product resides. See the [section below for details](#dynamic-steward-lookups).
* **Catalog permission**: The specific owner assigned to the asset in the external catalog. See the [section below for details](#dynamic-steward-lookups).

#### Dynamic steward lookups

Even when a review flow is fixed at the request form level, some sources are dynamic. This means the system identifies the specific reviewer based on the asset or data product being requested:

| Source                 | Example              | How it works                                                                                                                                                          | Available objects |
| ---------------------- | -------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------- |
| **Catalog permission** | Asset owner          | The system looks up the specific owner assigned to the asset in the external catalog (only [specific catalogs](#external-catalog-asset-owner-support) are supported). | Assets            |
| **Domain permission**  | Manage Data Products | The system identifies users with the `Manage Data Products` permission on the specific domain where the data product resides.                                         | Data products     |

#### External catalog permission support <a href="#external-catalog-asset-owner-support" id="external-catalog-asset-owner-support"></a>

External catalogs that support the catalog permission source in Immuta review flows are listed below:

* Atlan: [Asset Owner](https://docs.atlan.com/product/capabilities/discovery/how-tos/add-owners)

The catalog **must** be [configured in the Govern app](/saas/configuration/tags/catalogs/configure.md) for the asset owner information to populate.

### Understanding approval logic

Approvals in the Request app are marked based on the source of the data steward, not individuals. If your flow requires all stewards to approve, this means one representative from each assigned source must approve. See the examples below:

{% tabs %}
{% tab title="Single approver" %}
If an access request requires **any data steward's** determination, then once a single data steward makes a determination, it goes into effect.

* If approved:
  * [Access to the data objects will be auto-provisioned](#user-content-fn-1)[^1] in the data platform(s) for the requested data. This is done natively in the data platform, which means the requesting user can query those data objects directly from the data platform. This provisioning is represented as an [understandable and scalable Immuta policy](/saas/request/configure/reference-guides/understanding-access-provisioning-and-underlying-policies-in-immuta.md) that will be combined with any existing policies.
  * For masking exceptions, approved columns will be auto-provisioned with unmasked access in the data platform(s) where the user has access to the data source. This exception to the masking policy is represented as an [understandable and scalable Immuta policy](/saas/request/configure/reference-guides/understanding-masking-exceptions-and-underlying-policies.md) that will be combined with any existing policies.
* If denied, the user will not be granted access to the data.
  {% endtab %}

{% tab title="Multiple approvers" %}
If an access request requires **all data stewards'** determinations, then for every group, attribute, or permission listed in the request form, a data steward from that source must make a determination. If a data steward qualifies for multiple sources, their determination will count for each of the sources they have.

For example, if the request form lists users with the `GOVERNANCE` permission and users with the HR group as data stewards, then one user with the `GOVERNANCE` permission and one user with the HR group must approve to satisfy each of those conditions. A single user may approve for all conditions in a request form if they have the necessary permissions.

Once a determination is made by every source listed in the request form, it goes into effect.

* If approved:
  * [Access to the data objects will be auto-provisioned](#user-content-fn-1)[^1] in the data platform(s) for the data requested. This is done natively in the data platform, which means the requesting user can query those data objects directly from the data platform. This provisioning is represented as an [understandable and scalable Immuta policy](/saas/request/configure/reference-guides/understanding-access-provisioning-and-underlying-policies-in-immuta.md) that will be combined with any existing policies.
  * For masking exceptions, approved columns will be auto-provisioned with unmasked access in the data platform(s) where the user has access to the data source. This exception to the masking policy is represented as an [understandable and scalable Immuta policy](/saas/request/configure/reference-guides/understanding-masking-exceptions-and-underlying-policies.md) that will be combined with any existing policies.
* If denied by even a single data steward, the entire access request is denied and the user will not be granted access to the data.
* If there is a mix of approvals and temporary approvals, the user will be approved access to the data for the shortest time period that any of the data stewards picked.
  {% endtab %}
  {% endtabs %}

## How to apply a review flow

```mermaid
graph LR
    A(Configure) --> B(Attach)
    B --> C(Execute)
```

1. Set up the flow logic within a **request form**.
2. Link the **request form** to a **data product** or **asset**.
3. When a user clicks **request access**, the **review flow** is triggered automatically based on your configuration.

As you build out these flows, consider whether your priority is strict central governance or local flexibility. Which approach best fits your current data architecture?

[^1]: When supported by the [data platform](/saas/configuration/integrations/integrations-overview.md)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://documentation.immuta.com/saas/request/review-access-requests/reference-guides/request-forms/review-flows.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.