How to restrict employee drill-through for certain Metrics

Controlling data visibility is an important part of managing permissions. For example, a tile showing total headcount might be designed to share high-level insights, but drill-through access could reveal individual employee details like names or IDs. In some cases, that level of detail isn’t necessary and may not be appropriate for all audiences.

This article explores ways to keep sensitive information hidden during drill-through, while still allowing users to view aggregated data.

Understanding the Challenge

Drill-through permissions are controlled by column-level access in a Data Access Role (DAR). A user must have access to a column to see it when they drill into a data point.

The complexity arises because:

• Permissions follow a "least restrictive" rule.

If a user has two roles with the same metric (one with column access and one without) the system will grant them column access, allowing drill-through. This can unintentionally expose employee details in tiles that combine metrics (e.g., Headcount) with detailed dimensions i.e. individual employee details.

To address this situation, the goal is to create a security setup where users can view aggregated data in tiles, but they are completely blocked from seeing individual employee type details in drill-throughs for specific metrics.

This can be achieved through one or a combination of the following ways:

Solution 1: Duplicate Metrics & Create a Restrictive Role

This method is ideal for quickly restricting drill-through on specific tiles or storyboards while allowing it elsewhere.

Follow these steps:

1. Duplicate the Metric:

• Identify the metric you need to restrict (e.g., Headcount (EOP)).
• Create a copy of this metric and give it a clear name (e.g., Headcount (EOP) - No Drill-through).

2. Create a New Data Access Role (DAR):

• Create a new DAR and name it.
• Add the new, restricted metric to this role.
• Add all necessary dimensions for filtering (e.g., Division, Location) but do not check any column-level access boxes for employee identifying fields.
• Apply any necessary row-level security rules (e.g., by supervisory org).

3. Apply the Role and Update Tiles:

• Assign this new restrictive DAR to the relevant users. They can keep their original, less restrictive role.
• In the specific tiles or storyboards where drill-through must be blocked, replace the original metric with the new restricted one.
• Result: Users will see data in these specific tiles but will be unable to drill through to see employee details. Their original role will still allow drill-through in other storyboards.
   

Solution 2: Create a New Fact Table

This is a structural solution performed by an One Model Data Engineer which completely removes the possibility of drill-through for an entire dataset. 

Where possible, we strongly encourage Admins to choose option 1 over option 2.
Follow these steps if you would like to control drill-through by the creation of a new fact table:

1. Request a New Table:

• Please submit a config change ticket with One Model support to create a new fact table. This table should include the target metric column along with any dimension columns the customer specifies in advance). 
• This table will be a copy of the source table but will have all drill-through configurations disabled.

2. Rebuild Metrics and Dimensions

• The support team will assist with reconstructing key metrics (e.g. Headcount), leveraging the new table as the foundation.
• The new table will be joined to all required demographic, commute, and attendance dimensions.

3. Update Security:

• Update the users’ Data Access Roles to use the metrics built from the new table instead of the original ones.
• Result: Any metric built from the new table will have no drill-through capabilities, regardless of the user's other permissions. 

Other Considerations

• Contextual Security: For a long-term, scalable solution where access is dynamically granted based on a user's context (e.g., they only see employees in their own supervisory org), implementing contextual security is the recommended path. This requires a configuration change and work with your Data Engineer.
• Application Access Roles (AAR): Drill-through can be enabled or disabled globally, but cannot be applied to specific storyboards or user groups through AARs alone.

Choosing the Right Solution

If you need...                                                                                       Then use this solution:

For assistance implementing these solutions, please contact your system administrator or One Model support.