Row-level Permission (As-code)
Row-level Permission as-code is an upcoming feature and is not yet available.
If you need to set up Row-level Permission in Holistics, please refer to the current documentation here: Row-level Permission.
Introduction
Row-level Permission allows you to grant filtered access for your users, so each user only sees the data they are permitted to view. For example, if you have a team of salespeople managing different countries, you can ensure each person only sees sales data relevant to their assigned country.
With Row-level Permission, you can easily control and secure data access at a granular level, making sure sensitive information is only visible to the right people.
General Setup
With Row-level Permissions as code, you define permission rules directly in your dataset configuration. These rules can reference user attributes, such as region, role, or vendor assignment. By doing so, you can automatically filter the data each user sees based on their user attributes.
a. Create User Attribute
First, define user attributes in the Holistics UI under User Attributes management. For example, you might create a region or vendor_id attribute:

b. Define Row-level Permission in the Dataset as-code
Reference these user attributes in your dataset permission rules:
Dataset ecommerce {
permission vendor_access {
field: r(product.vendor_id)
operator: 'matches_user_attribute'
value: 'vendor_id' // user attribute
}
}
- The
matches_user_attributeoperator checks if the field matches the user's attribute. - The
valueshould be the name of the user attribute (as a string)
Typical Use Case
Suppose you run an international e-commerce company with regional managers for each country. You want each manager to only see data for their assigned region.
Step 1: Create a user attribute called region and assign the appropriate value to each manager in the User Attributes management screen.
Step 2: In your dataset code, define a permission rule that filters data by the user's region:
Dataset ecommerce {
permission regional_access {
field: r(order.region)
operator: 'matches_user_attribute'
value: 'region'
}
}
Now, when a manager logs in, they will only see data for their assigned region—enforced automatically at the dataset level.
Caveats & Limitations
- No Testing in Development: Row-level Permission as-code can't be tested while in the Development workspace. Permissions will only take effect after the dataset is published to production.
- Admin and Analyst Access: With Row-level Permission as-code, both Admins and Analysts can view and modify row-level permissions directly in the code, regardless of their data source permissions.
- No Code Assistance: There is no code suggestion or validation for user attribute values when writing permission rules. You need to ensure the user attribute names match exactly with those defined in User Attributes management.
- Can't Edit in Reporting: Row-level Permission as-code cannot be edited in the Reporting interface. All changes must be made in the dataset code.
- No UI in Development: There is no UI to view or edit Row-level Permission as-code in the Development workspace. You must define and manage all permission rules directly in the dataset code.