---
title: "Govern a customer dataset with policy tags, views and Time Travel"
description: "Find out how to protect a customer table that holds personal data with policy tags, IAM groups, a governed view and Time Travel"
url: https://docs.ovhcloud.com/it/guides/public-cloud/data-platform/tutorials-customer-data-governance
lang: en
lastUpdated: 2026-10-20
---
> For AI agents: the complete documentation index is available at https://docs.ovhcloud.com/it/llms.txt, the full documentation bundle is available at https://docs.ovhcloud.com/it/llms-full.txt.

# Govern a customer dataset with policy tags, views and Time Travel

## Objective

This guide walks you through protecting a customer table that holds personal data: you classify its columns with [policy tags](https://docs.ovhcloud.com/it/guides/public-cloud/data-platform/lakehouse-manager-policy-tags.md), restrict each team with [IAM groups](https://docs.ovhcloud.com/it/guides/public-cloud/data-platform/iam-groups.md) and CEL conditions, publish a [view](https://docs.ovhcloud.com/it/guides/public-cloud/data-platform/lakehouse-manager-views.md) that gives analysts a coarser version of the data, and undo a destructive mistake with [Time Travel](https://docs.ovhcloud.com/it/guides/public-cloud/data-platform/lakehouse-manager-time-travel.md).

By the end you will have a customer table classified column by column, three teams with access matched to their needs, a governed view for analysts, and a tested way to restore the table after an accidental deletion.

## Requirements

To follow this guide you need:

- a Data Platform project. This guide uses a project named `customer-governance`.
- an administrator account on this project.
- a second, non-administrator account for a test user: another person's account, or a second address of your own, for example `user+governance-test@example.com`.
- the customer file:

| **Type**                            | **Name**                                                                                                                                                             |
| ----------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Customers, 5,000 fictitious records | <a className="rp-link" href="/images/public-cloud/data-platform/getting-further/customer-data-governance/resources/customers.parquet" download>customers.parquet</a> |

**Note:** **About the data:** `customers.parquet` is derived from [Nemotron-Personas-USA](https://huggingface.co/datasets/nvidia/Nemotron-Personas-USA), by NVIDIA, licensed under [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/). It keeps a sample of 5,000 adult records; names are extracted from the `persona` field, and emails, phone numbers and SSNs are synthetic (domain `example.com`, numbers 555-0100 to 555-0199, SSN area 000).

We recommend reading the [policy tags](https://docs.ovhcloud.com/it/guides/public-cloud/data-platform/lakehouse-manager-policy-tags.md) and [CEL conditions](https://docs.ovhcloud.com/it/guides/public-cloud/data-platform/lakehouse-manager-policy-tags-cel-conditions.md) guides first. This guide assumes you are comfortable with the main components of Data Platform.

## What you will build

| Stage                          | Component                                                                                                                                                                                                                        | Result                                                  |
| ------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------- |
| 1. Load the customers          | [Connectors](https://docs.ovhcloud.com/it/guides/public-cloud/data-platform/connectors-sources-upload-files.md), [Lakehouse Manager](https://docs.ovhcloud.com/it/guides/public-cloud/data-platform/lakehouse-manager-tables.md) | Table `crm.customers`, 5,000 rows                       |
| 2. Classify the columns        | [Policy Tags](https://docs.ovhcloud.com/it/guides/public-cloud/data-platform/lakehouse-manager-policy-tags.md)                                                                                                                   | Every column has a sensitivity level                    |
| 3. Define the access rules     | [Identity Access Manager](https://docs.ovhcloud.com/it/guides/public-cloud/data-platform/iam-roles-conditions.md)                                                                                                                | Three roles, three groups, three CEL conditions         |
| 4. Check the rules             | [Explorer](https://docs.ovhcloud.com/it/guides/public-cloud/data-platform/lakehouse-manager-explorer.md), test user                                                                                                              | Each group reads only what it should                    |
| 5. Publish a view for analysts | [Views](https://docs.ovhcloud.com/it/guides/public-cloud/data-platform/lakehouse-manager-views.md), CEL conditions                                                                                                               | Age bands and 3-digit ZIP codes instead of exact values |
| 6. Undo a mistake              | [SQL action](https://docs.ovhcloud.com/it/guides/public-cloud/data-platform/dpe-actions-sql.md), [Time Travel](https://docs.ovhcloud.com/it/guides/public-cloud/data-platform/lakehouse-manager-time-travel.md)                  | 591 deleted customers restored                          |

Three groups access the table `crm.customers` at different levels: _Analysts_ see only the `low` columns, _Customer Support_ the `low` and `medium` columns, and _Data Stewards_ every column. The governed view `customer_profiles`, built on the same table, gives Analysts a coarser version of the age and ZIP code.

## Instructions

### Step 1: Loading the customers

#### Creating the source

1. Go to **Connectors** > **Sources** > **New Source** and click **File Upload** at the bottom of the window.

2. Rename the source `customers`.

3. Drop `customers.parquet` in the _Files_ area, then click **Create**.

#### Checking the types

Go to **Connectors** > **Analyzer** and open `customers.parquet` in the source `customers`. The [metadata extraction](https://docs.ovhcloud.com/it/guides/public-cloud/data-platform/connectors-analyzer-extract-metadata.md) starts on its own. Check two columns:

- `zipcode` must be **String**: ZIP codes such as `02760` would lose their leading zero as numbers.
- `age` is **Double**, which works for the age bands of step 5.

#### Creating the dataset and the table

A dedicated dataset keeps the rules of this guide away from the rest of the project: the policy tag you set on it in step 2 applies to every table it contains.

1. Go to **Lakehouse Manager** > **Datasets** > **New Dataset**, name it `crm` and click **Create**.

2. Go to **Tables**, click the arrow next to **New table** and select **Create from a Connectors source**.

3. Select `customers.parquet` from the source `customers` and click **Next**.

4. Name the table `customers`, select the dataset `crm`, keep the 3 automatic options turned on and click **Create**.

   When the load ends, the table `customers` shows **16** attributes and **5k** rows.

### Step 2: Classifying the columns

The access rules of step 3 check the [policy tag](https://docs.ovhcloud.com/it/guides/public-cloud/data-platform/lakehouse-manager-policy-tags.md) of each column to decide who can read it.

#### Reviewing the sensitivity tag

Go to **Lakehouse Manager** > **Policy Tags** and click `sensitivity`. The project provides this key with three values, which this guide uses as follows:

| Value    | Meaning                                                                     |
| -------- | --------------------------------------------------------------------------- |
| `low`    | Business data, readable by everyone                                         |
| `medium` | Identifies or reaches a person, alone or combined                           |
| `high`   | Special category data, government identifier, free text that leaks identity |

#### Tagging the dataset

Tag the dataset `low`: every column without a tag of its own inherits it.

Go to **Datasets**, open `crm`, then the _Policy Tags_ tab, click **+ Add policy tag**, select the key `sensitivity`, then the value `low`. Changes are saved automatically.

#### Tagging the columns

Go to **Tables**, open `customers`, then the _Policy Tags_ tab. In _Column-level policy tags_, click **+ Add policy tag** on each column below, then select `sensitivity` and its value:

| Sensitivity | Columns                                                                                        | What to do                          |
| ----------- | ---------------------------------------------------------------------------------------------- | ----------------------------------- |
| `medium`    | `age`, `sex`, `marital_status`, `city`, `zipcode`, `first_name`, `last_name`, `email`, `phone` | Add `sensitivity: medium`           |
| `high`      | `ssn`, `cultural_background`, `persona`                                                        | Add `sensitivity: high`             |
| `low`       | `uuid`, `state`, `occupation`, `education_level`                                               | Nothing: inherited from the dataset |

Tags apply immediately, without rebuilding the table.

### Step 3: Defining the access rules

Access combines two kinds of [roles](https://docs.ovhcloud.com/it/guides/public-cloud/data-platform/iam-roles-conditions.md), both created in the **project** IAM:

- a **base role** lets users open the interface and run queries, without access to data;
- a **data role** gives access to data through _Advanced Data Access Control_, limited by a CEL condition set on each group.

#### Creating the roles

Create the three roles below one by one: go to **Identity Access Manager** > **Roles** > **New role**, add each permission with **Add permission**, then click **Create**.

| Role                    | Service                      | Resource | Action              |
| ----------------------- | ---------------------------- | -------- | ------------------- |
| `Lakehouse Explorer`    | Data Manager                 | `*`      | Read                |
|                         | Data Manager                 | explorer | Run, History        |
|                         | Query Builder Legacy         | `*`      | Read                |
|                         | Analytics Manager            | `*`      | Read                |
|                         | Analytics Manager            | Query    | Run, History, Write |
| `Customer Data Reader`  | Advanced Data Access Control | `*`      | Read                |
| `Customer Data Steward` | Advanced Data Access Control | `*`      | Read, Write, Delete |

`Lakehouse Explorer` has no Advanced Data Access Control permission: on its own, it gives no access to data.

#### Creating the groups

Each group binds a data role to a CEL condition:

| Group            | Data role               | Columns readable           |
| ---------------- | ----------------------- | -------------------------- |
| Analysts         | `Customer Data Reader`  | `low`                      |
| Customer Support | `Customer Data Reader`  | `low` and `medium`         |
| Data Stewards    | `Customer Data Steward` | `low`, `medium` and `high` |

The access check walks down dataset, table, then attribute, and each level must pass. In the conditions below, the first two lines let every group through `crm` and `customers`. The third decides which column levels the group reads. The fourth line is for the view of [step 5](#step-5-publishing-a-view-for-analysts). A view cannot carry a policy tag yet, so the access check sees the view and its columns as untagged resources: without this line, every view is denied, even one built only from `low` columns. This line does not open other resources: the tables of `crm` inherit `low` from the dataset, and an untagged dataset is still refused.

**Note:** **Note:** CEL compares strings exactly: `"low"` does not match `"Low"`.

**Analysts**:

```text
Service == "adac" && (
  (PolicyTags.sensitivity == "low" && Resource == "dataset")
  || (PolicyTags.sensitivity == "low" && Resource == "table")
  || (PolicyTags.sensitivity == "low" && Resource == "attribute")
  || (!has(PolicyTags.sensitivity) && Resource != "dataset")
)
```

**Customer Support**:

```text
Service == "adac" && (
  (PolicyTags.sensitivity == "low" && Resource == "dataset")
  || (PolicyTags.sensitivity == "low" && Resource == "table")
  || (PolicyTags.sensitivity in ["low", "medium"] && Resource == "attribute")
  || (!has(PolicyTags.sensitivity) && Resource != "dataset")
)
```

**Data Stewards**:

```text
Service == "adac" && (
  (PolicyTags.sensitivity == "low" && Resource == "dataset")
  || (PolicyTags.sensitivity == "low" && Resource == "table")
  || (PolicyTags.sensitivity in ["low", "medium", "high"] && Resource == "attribute")
  || (!has(PolicyTags.sensitivity) && Resource != "dataset")
)
```

For each group:

1. Go to **Groups** > **New group** and name the group.

2. In _Roles & Conditions_, click **+ Add** and select its data role.

3. Click the condition link next to the role, paste the group's condition from above and click **Confirm**.

4. Click **Create**.

### Step 4: Checking the rules with a test user

Administrators are not restricted by policy tags, so run the checks with the test user. Change the test user's groups with the administrator account, and run the queries as the test user in **Lakehouse Manager** > **Explorer**, in SQL mode.

#### Creating the test user

1. In the organisation IAM, invite the test user's address and add them to the group **Viewers**.

2. In the project IAM, go to **Users** > **+ New User** and add the same address as a _Team Member_.

3. On the user's page, add the role `Lakehouse Explorer` only and the group **Analysts**, then click **Save**.

4. Accept the invitation and log in as the test user in a private browser window.

**Warning:** **Do not give the test user the default role `DM & AM Editor`.** It includes Advanced Data Access Control / Read without condition and reads every column whatever its tags.

**Note:** **Note:** A change of group or role takes effect within about 30 seconds, without logging out: reload the test user's page before running the query again.

#### Checking the Analysts group

With the test user, run:

| Query                                               | Result  |
| --------------------------------------------------- | ------- |
| `SELECT uuid, state, occupation FROM crm.customers` | Success |
| `SELECT zipcode FROM crm.customers`                 | Error   |
| `SELECT * FROM crm.customers`                       | Error   |

![The Explorer returning Access Denied: Cannot select from columns [zipcode] to the Analyst](https://docs.ovhcloud.com/images/public-cloud/data-platform/getting-further/customer-data-governance/picts/25-analyst-zipcode-error.png)
A policy tag denies access rather than masking values: one denied column makes the whole query fail.

#### Checking the Customer Support group

With the administrator account, go to **Identity Access Manager** > **Users** and open the test user. In _Groups_, click the bin icon on the **Analysts** row, then click **+ Add**, select **Customer Support** and click **Save**.

**Note:** **Note:** Always remove the previous group. Rights add up: a user in **Data Stewards** and **Analysts** reads every column.

With the test user, run:

| Query                                                                    | Result  |
| ------------------------------------------------------------------------ | ------- |
| `SELECT first_name, last_name, email, phone, zipcode FROM crm.customers` | Success |
| `SELECT ssn FROM crm.customers`                                          | Error   |
| `SELECT persona FROM crm.customers`                                      | Error   |

#### Checking the Data Stewards group

With the administrator account, replace **Customer Support** with **Data Stewards** in the same way. With the test user, run:

| Query                                                              | Result  |
| ------------------------------------------------------------------ | ------- |
| `SELECT * FROM crm.customers`                                      | Success |
| `SELECT first_name, last_name, persona FROM crm.customers LIMIT 5` | Success |

The `persona` text opens with the customer's full name and often quotes their age: that is why it is tagged `high`.

### Step 5: Publishing a view for analysts

Analysts cannot read the age or the ZIP code. The [view](https://docs.ovhcloud.com/it/guides/public-cloud/data-platform/lakehouse-manager-views.md) `customer_profiles` gives them an age band and the first three digits of the ZIP code instead.

#### Creating the view

1. With the administrator account, go to **Lakehouse Manager** > **Views** > **New view**.

2. Name the view `customer_profiles`, select the target dataset `crm` and paste this SQL definition:

   ```sql
   SELECT
       uuid,
       state,
       substr(zipcode, 1, 3) AS zip3,
       CASE
           WHEN age < 25 THEN '18-24'
           WHEN age < 35 THEN '25-34'
           WHEN age < 45 THEN '35-44'
           WHEN age < 55 THEN '45-54'
           WHEN age < 65 THEN '55-64'
           ELSE '65+'
       END AS age_band,
       occupation,
       education_level
   FROM customers
   ```

3. Click **Create**. The view shows the status **Valid**.

#### Checking the view

The test user is in **Data Stewards**. Run these queries as the test user, then move the test user back to **Customer Support**, then to **Analysts**, and run the queries again each time:

| Query                                 | Analysts | Customer Support | Data Stewards |
| ------------------------------------- | -------- | ---------------- | ------------- |
| `SELECT * FROM crm.customer_profiles` | Success  | Success          | Success       |
| `SELECT zipcode FROM crm.customers`   | Error    | Success          | Success       |

**Warning:** A view can expose any column of its source table: anyone who can create a view in `crm` decides what analysts read. Keep view creation for data stewards. `Lakehouse Explorer` cannot create views.

### Step 6: Undoing a mistake with Time Travel

Every change to a Lakehouse Manager table creates a snapshot, and [Time Travel](https://docs.ovhcloud.com/it/guides/public-cloud/data-platform/lakehouse-manager-time-travel.md) rolls the table back to any snapshot still kept.

#### Making the mistake

1. With the administrator account, run this count in the Explorer. It returns 5,000 customers, 591 in California.

   ```sql
   SELECT count(*) AS customers, count_if(state = 'CA') AS california FROM crm.customers
   ```

2. Go to **Data Processing Engine** > **Actions** > **New action**, create a _SQL Action_ and name it `Delete California customers`.

3. In the _Tables_ panel, click `customers` in `crm` to copy its full name, in the form `catalog.schema.table`, for example `"db_mv0m4qnl_crm"."crm".customers`. A [SQL action](https://docs.ovhcloud.com/it/guides/public-cloud/data-platform/dpe-actions-sql.md) needs this full name.

4. Type this query, replacing `<catalog>.crm.customers` with the full name you copied, then click **Validate**:

   ```sql
   DELETE FROM <catalog>.crm.customers WHERE state = 'CA'
   ```

   The dry run announces **591 rows would be deleted**.

5. Click **Create**, then **Run** the action. Repeat the count: it now returns 4,409 customers, none in California.

#### Restoring the table

1. Go to **Lakehouse Manager** > **Tables**, open `customers`, then the _Time Travel_ tab. The latest snapshot is **Data deleted**, on top of two **Data inserted** snapshots.

2. Check a snapshot before restoring it, with its ID from the _Snapshot ID_ column:

   ```sql
   SELECT count(*) AS customers, count_if(state = 'CA') AS california
   FROM customers FOR VERSION AS OF <snapshot ID>
   ```

   The most recent **Data inserted** snapshot holds 5,000 customers. The oldest one is empty: it records the table creation, before the load.

3. Click the rollback icon (↻) on the most recent **Data inserted** snapshot, then **Rollback to snapshot**.

   A **Data rollbacked** line appears on top of the history; the **Data deleted** snapshot stays in it. Repeat the count: it returns 5,000 customers again, 591 in California.

## Good to know

- **Policy tags deny, they do not mask.** A query that includes a denied column fails as a whole. To give coarser data to a team, publish a view.
- **The default role `DM & AM Editor` bypasses policy tags.** It includes Advanced Data Access Control / Read without condition. Give data consumers a custom base role without any Advanced Data Access Control permission.
- **You cannot add yourself to a group.** The IAM prevents users from granting themselves rights.
- **Rights add up.** A user in several groups, or with several roles, gets access as soon as one of them allows it.
- **Check a snapshot before rolling back to it.** The oldest snapshot of a table can be empty: it records the table creation, before any data was loaded.
- **Validation shows the impact of a change.** In a SQL action, **Validate** runs the query as a dry run and gives the number of rows affected, before anything changes.
- **Time Travel has a time limit.** Snapshots are kept 14 days by default, between 7 and 28 days depending on the dataset or table setting. After that, a mistake can no longer be undone this way.

## What you have built

You have a customer table classified column by column, three teams with access matched to their needs, a governed view that gives analysts coarser data, and a way to undo a destructive mistake. The same pattern applies to any table that holds personal data: classify, define roles, test with a non-administrator, and keep Time Travel within reach.

To go deeper, see the [policy tags testing guide](https://docs.ovhcloud.com/it/guides/public-cloud/data-platform/lakehouse-manager-policy-tags-testing.md), the [team access example with groups](https://docs.ovhcloud.com/it/guides/public-cloud/data-platform/lakehouse-manager-policy-tags-groups-example.md) and the [Time Travel retention settings](https://docs.ovhcloud.com/it/guides/public-cloud/data-platform/lakehouse-manager-time-travel.md#managing-snapshot-retention).

## Go further

For training or technical assistance implementing our solutions, contact your sales representative or visit our [Professional Services](https://www.ovhcloud.com/it/professional-services/) page to request a quote and have your project analysed by our experts.

Ask questions, give your feedback and interact directly with the team building the Data Platform on the dedicated [Discord channel](https://discord.gg/ovhcloud).

If you need support with your OVHcloud services, create a request in our [Help Centre](https://help.ovhcloud.com/csm?id=csm_get_help).

Join our [community of users](https://community.ovhcloud.com/).
