# Masking Sensitive Fields for Certain Users

**URL:** <https://discuss.google.dev/t/masking-sensitive-fields-for-certain-users/119216>\
**Category:** Technical Tips & Tricks\
**Created:** [June 22, 2022, 9:37pm UTC](https://discuss.google.dev/t/masking-sensitive-fields-for-certain-users/119216 "2022-06-22T21:37:19Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![sam8](https://d3byx8b92xw3lq.cloudfront.net/user_avatar/discuss.google.dev/sam8/32/21646_2.png) [@sam8](https://discuss.google.dev/u/sam8)\
**Post date:** [June 22, 2022, 9:37pm UTC](https://discuss.google.dev/t/masking-sensitive-fields-for-certain-users/119216/1 "2022-06-22T21:37:19Z")

</div>

# The Problem

You have a field that you want only some of your users to be able to see data in. While data access permissions are usually handled at the model level, you don’t want to create a whole new model just to mask this field. You don’t mind if other users know that the field exists, but you do want to make sure that the users never see data for that field.

# The Solutions

This article discusses two possible ways of approaching this problem:

- Use the ability to reference [user attributes](https://docs.looker.com/admin-options/settings/user-attributes) in SQL with [Liquid syntax](https://docs.looker.com/reference/liquid-variables) to mask the content of these fields.
- Use [access grants](https://docs.looker.com/reference/model-params/access_grant) to leverage user attribute values to control which users can view specific content.

The following examples use email addresses to illustrate these solutions.

## User Attributes with Liquid

Referencing user attributes in SQL with Liquid syntax lets you mask the contents of these fields, depending on the user who is querying them.

1. Create a new user attribute called `can_see_email`. Set **User Access** to **View**. This will allow users to see the attribute but not have control over its value. Set the default value to **no** , so you will have to explicitly change the value to **yes** for users and groups that you want to be able to see email addresses. When you’ve finished this step, the settings will look something like this:
2. Now you can create a new dimension that references this user attribute and returns values only when the user attribute is set to **yes**. When the user attribute is set to **no** , return a static string such as “REDACTED”.

```auto
dimension: user_email {
  type: string
  sql:
    {% if _user_attributes['can_see_email'] == 'yes' %}
      ${TABLE}.user_email
    {% else %}
      '[REDACTED]'
    {% endif %} ;;
}

```

**Bonus** : You can take advantage of the fact that Liquid works in the [`label`](https://docs.looker.com/reference/field-params/label-for-field) parameter to let users know the field is redacted for them.

```auto
dimension: user_email {
  type: string
  label: "{% if _user_attributes['can_see_email'] == 'yes' %} User Email
    {% else %} User Email (Redacted due to insufficient permissions)
    {% endif %}"
  sql:
  {% if _user_attributes['can_see_email'] == 'yes' %}
      ${TABLE}.user_email
  {% else %}
      '[REDACTED]'
  {% endif %} ;;
}

```

## Access Grants

Access grants are another way to leverage user attribute values to control which users can view specific Explores, joins, views, or fields. Access grants are defined at the model level with the [`access_grant`](https://docs.looker.com/reference/model-params/access_grant) parameter. As part of the definition, you associate the access grant with a user attribute. You also specify which user attribute values provide access to the access grant.

Once defined, access grants can be applied to [Explores](https://docs.looker.com/reference/explore-params/required_access_grants-for-explore), [joins](https://docs.looker.com/reference/explore-params/required_access_grants-for-join), [views](https://docs.looker.com/reference/view-params/required_access_grants-for-view), or [fields](https://docs.looker.com/reference/field-params/required_access_grants-for-field) with the `required_access_grants` parameter to restrict access to those structures.

For example, you can create an access grant to restrict user access to the `user_email` field:

```auto
access_grant: can_see_email {
    user_attribute: can_see_email
    allowed_values: ["yes"]
  }

```

Then you can apply it to the `user_email` dimension like so:

```auto
  dimension: user_email {
    type: string
    sql: ${TABLE}.user_email;
    required_access_grants: [can_see_email]
  }

```

This will allow only users who have the `can_see_email` user attribute value set to `"yes"` to view the `user_email` field.

**Note:** Keep in mind that access grants are _additive_ when nested at multiple LookML structure levels (Explore, join, view, field). Review the [`access_grant`](https://docs.looker.com/reference/model-params/access_grant#access_grants_at_multiple_levels_are_added_together) documentation page for additional details.