Column-level Permission

Knowledge Checkpoint

This documentation assumes you are familiar with the following concepts:

• Holistics Expression
• User Attributes

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.

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.

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.

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)'
)

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.