# Access to Data Products and Assets

When viewing a data product, you can see details about what you’ll be able to query or unmask if approved:

* The data product’s data sources (tables, views, files) and your **Access Status** for each
* The data product’s columns and if masking is applied

## Understanding access status

There are different statuses based on the type of access you want.

### Data source access

There are three possible access statuses for the data sources in a data product:

1. `Current access`: You already have access to this data source through existing policies or a data product approval.
2. `Access if approved`: You will gain access to this data source should you request access and your request is approved.
3. [`Access prevented`](#access-prevented-status): There are existing required policies on this data source that you do not meet.

{% hint style="info" %}
It is still worth requesting access to a data product even if you have access to *all* the data sources it contains because new data sources may be added later, which you may not have birthright access to. In this case, if approved to the data product, you will gain access to the new data sources as soon as they are added to the data product.
{% endhint %}

#### Access prevented status

It is possible that a data consumer will be blocked from accessing certain data sources, despite being granted access to a data product. This can be the case if data sources are protected by a [guardrail subscription policy](https://documentation.immuta.com/saas/govern/secure-your-data/authoring-policies-in-secure/section-contents/reference-guides/subscription-policies#guardrail-subscription-policy) and the consumer does not meet the criteria defined by that policy.

For example, there may be a rule stating that only members of the group `HR` can ever be eligible to be subscribed to employee data. Because of that rule, there is a [guardrail subscription policy](https://documentation.immuta.com/saas/govern/secure-your-data/authoring-policies-in-secure/section-contents/reference-guides/subscription-policies#prevent-access) created through the Govern app on that data source that states

> Prevent users from subscribing unless user is a member of group `HR` on data sources tagged `employee`.

In this case, even if a consumer was approved access to a data product containing some data sources with employee data, their access will be blocked if they are not part of the group `HR`. This provides global governance with a guarantee that nobody can bypass policies on extremely sensitive data sources.

If that data source is now made part of a data product, the requesting user must be a member of group `HR` to gain access to that particular data source in the data product, even if they are approved to the data product. If the policy changes so the user meets the requirements, or if the user is added to group `HR`, Immuta will update the user’s access and grant access to that data source.

### Column access

There are two masking statuses for columns within the data sources of a data product:

1. `Masked`: The column is currently masked by a data policy, but you can request a masking exception.
2. `—`: The column is not masked, so no exception is needed.

## Provisioning access when approved

If an access request is approved, Immuta automatically provisions access in the supported data platforms:

* **Data access requests**: The user gains query access to the approved data sources in the asset or data product.
* **Masking exception requests**: The user sees unmasked values for the approved columns, while masking continues to apply for all other users.

In both cases, the provisioning is represented as an [understandable and scalable Immuta policy](https://documentation.immuta.com/saas/request/configure/reference-guides/understanding-access-provisioning-and-underlying-policies-in-immuta), combined with any applicable birthright or guardrail policies.

The access statuses in a data product are updated accordingly:

* **Data sources**:
  * `Current access` → **`Current access`**
  * `Access if approved` → **`Current access`**
  * `Access prevented` → **`Access prevented`**
* **Columns**:
  * `Masked` → **`-`** (unmasked for the approved user only)

<i class="fa-paper-plane">:paper-plane:</i> The requesting user and stewards will receive a notification through their configured [notification platform](https://documentation.immuta.com/saas/request/notifications/reference-guides/notifications-reference-guide) that the access was approved or denied. A history of requests and their determinations is also visible on the **Access requests** page in the UI.

## Temporary approvals

For any asset or data product, a data steward can choose to provide a temporary approval to the access request. This provisions access to the user for a set duration of time and then rescinds access through the asset or data product at the end of the set time. If you have temporary access to a data product, your access status will be updated: `Temporarily approved`.

Both data access and masking exception requests can be granted temporarily. When the approval expires, the user's access will be automatically revoked:

* **Data access requests**: Provisioned access to data sources is revoked automatically when the duration expires.
* **Masking exception requests**: Approved columns return to masked automatically when the duration expires.

After expiration, the user can re-request access or exceptions as needed.