Row-level permission (as-code)

Feature Availability

Row-level permission as-code is not enabled by default. Contact [email protected] to enable this feature for your team.

If you need to set up Row-level permission without this feature, refer to: Row-level permission.

Due to some limitations, review the Caveats & limitations section before getting started.

Introduction

Row-level permission as-code works the same as Row-level permission — each user only sees the data they are permitted to view. The difference is that you define the permission rules directly in your dataset code, rather than through the UI.

This gives you:

• Version control — permission changes are tracked in git alongside your schema
• Consistency — rules stay in sync with your dataset and publish together

General setup

With Row-level permission 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.

Step 1: 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:

Don't forget to set the user attribute value for each user.

Step 2: define row-level permission in the dataset as-code

Now reference that attribute in your dataset to filter what each user sees:

Dataset ecommerce {
  permission vendor_access {
    field: r(product.vendor_id)
    operator: 'matches_user_attribute'
    value: 'vendor_id' // user attribute
  }
}

• The matches_user_attribute operator checks if the field matches the user's attribute.
• The value should be the name of the user attribute (as a string)

Typical use case

Here's how this works end-to-end in a real scenario.

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

Create a user attribute called region and assign the appropriate value to each manager in the User Attributes management screen.

Step 2: define the permission rule

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.