Column-level security

Being able to control who can see specific dimensions and measures is very important for both creating a good user experience and for compliance purposes.

I think the solution for text dimensions, where you can dynamically mask the value works well.

This does, however, not work as well for number dimensions and measures, as you are not able to write (redacted) in a number dimension/measure. You could replace the actual value with null, but this would give the impression, that Holistics is not working if somebody tries to run it.

The best solution, in this case, would be, if there was an option to hide fields based on user attributes. This would make it much easier for people who don’t have access to all fields, as they will not be presented with the option to see the field.


We have some datasets, where we have several models built on the same source table. We do this for our order models, where we have a model (primary model) for columns that everybody can access, and then a separate model with additional logic only for our finance department (secondary model).

The benefit of this structure is that we can reuse the logic in the main table for finance while keeping finance logic hidden for the rest of the business.

The downside to this approach is, that if you use Bigquery like us, then we cannot use the partition filter on the secondary model, which increases our BigQuery cost for large source tables.

I think this is something that should be prioritized as it makes being compliant a lot easier.

Hi Martin, my apologies for the delayed response.

This is Son from the Product Team of Holistics, thanks for sharing your thoughts on this. We understand that there are better solutions than masking the value.

Would you mind sharing more about your use case(s), i.e. Apart from the number dimensions and measures case, is there any reason you would prefer hiding fields to just masking the value?

Besides, the use case you are referring to can be resolved when we roll out what we call the Dynamic model in the next year. This feature allows analysts to define dataset/report that can take user inputs or attributes. Let’s see how it works for your case:

For example, if we only want users with a manager role to see the revenue, at first we will define a is_manager param in the model definition and use it to set the condition for the hidden field property.

Model Order (is_manager: boolean) {  
  measure revenue {
    type: 'number'
    hidden: '${is_manager}'

Then in the dataset exploration, we set the viewing permission with the is_manager param and user Attribute pii_access:

As a result, when a manager (with pii_access = true) views a dashboard, s/he will see the full data. When a non-manager views, s/he won’t see the column revenue.

Please be kindly noted that this feature is still in the research phase so the final solution might be different. We are gathering feedback to make sure what we build covers all users’ needs.

Should you have any questions about the feature, please let me know.



This is an exciting development!

1 Like

Hi Son
This is a great use of Dynamic models. It would solve my use case :slight_smile:

1 Like