Skip to main content

Column-level Permission

Knowledge Checkpoint

This documentation assumes you are familiar with the following concepts:

Introduction

Sometimes in a report/dashboard, you want to restrict user access at the column level, allow/disallow certain users to see certain columns. In Holistics, we call this Column-level Permission.

Consider some of these real-world use cases:

  • Restrict access based on users: In a department (e.g sales), you want each salesperson to see others' data, but they can only see customer's information on the deals they own.
  • Restrict PII Data Access: For reports with PII (personally identifiable information) data, you want to grant access to selected set of users. Other users can still see report data, but cannot see the PII-related columns.

Column-level Permission for PII

Unlike Row-level Permission, this approach doesn't completely remove the rows for the users, only hiding the columns that the user is not supposed to see.

Use Case

In this post, we'll share with you how to implement the PII access example above where:

  • Managers have full PII access.
  • At staff-level, PII access is granted on a case-by-case basis.

Once set up, whenever a user views the Orders report or dataset, appropriate PII check will take place to determine the user can see the customer information.

High-level Approach

To determine if a user can see PII data, we create a user attribute (e.g pii_access). We create a Managers group with default pii_access turned on. All manager-level users will be added to this group.

In the data model, we create a custom field (e.g customer_email_pii) with logic to check on PII. We use this field as the main email going forward. The custom field's logic will look like (pseudocode):

if $user.pii_access == true
then model.customer_email
else '(redacted)'
end

So when a manager (with pii_access = true) views a dashboard, s/he will see the full data. When a non-manager views, s/he will see the customer email redacted.

Implementation Steps

Let's walk through the detailed steps below.

1. Create user_attribute pii_access

Create a user attribute called pii_access with Number type. 0 will mean no access, and 1 will mean access.

Column-level Permission for PII

2. Create group 'Managers' and add all managers to the group

Create a usergroup 'Managers'. Also set pii_access to 1 for this usergroup.

Add all manager-level users to this group.

Column-level Permission for PII

3. Create custom field with PII-aware logic

Go to your orders model (orders is the model that contains list of transactions), and create a custom field customer_email_pii, select AML and enter the following Holistics Expression:

case(
when:
in(1, H.current_user.pii_access),
then: orders.customer_email,
else: '(redacted)'
)

Create dimension using AML

Also go ahead and Hide the original customer_email so that it will not appear in the Dataset.

4. Profit

Done. Now that when a customer explorers customer_email_pii, or view a chart/dashboard that's generated from this dataset, the system checks and make sure to show customer email only when he has been granted PII Access permission.

Column-level Permission for PII


Let us know what you think about this document :)