(Or restricting user access control at the column level)
Sometimes in a report/dashboard, you want to restrict access control 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.
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.
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
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.
Let's walk through the detailed steps below.
1. Create user_attribute
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, use AML syntax and enter the following:
Also go ahead and Hide the original
customer_email so that it won't appear in the Dataset.
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.