Row-level Permission (As-code)

Coming Soon

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 Permission as-code, you can define permission rules in your dataset definition. There are two main ways to set up permissions:

1. Hard-coded Permission

You can restrict access to specific rows by hard-coding values in your permission rules. For example, to allow access only to orders with status "delivered" or from a specific country:

Dataset ecommerce {
  permission status_access {
    field: ref('order', 'status')
    operator: 'is'
    value: 'delivered' // fixed value
  }
  permission vietnam_access {
    field: ref('order', 'status')
    operator: 'is'
    value: 'Vietnam' // fixed value
  }
}

2. Permission Referencing User Attributes

For more dynamic access control, you can reference user attributes in your permission rules. This allows you to filter data based on properties assigned to each user (such as region, role, or vendor).

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 Dataset as-code

Reference these user attributes in your dataset permission rules:

Dataset ecommerce {
  permission regional_access {
    field: ref('order', 'user_d')
    operator: 'is'
    value: H.current_user.region // user attribute
  }
  permission vendor_access {
    field: ref('product', 'vendor_id')
    operator: 'matches_user_attribute'
    value: 'vendor_id' // user attribute
  }
}

• H.current_user.<attribute> references the current user's attribute value.
• The matches_user_attribute operator checks if the field matches the user's attribute.

Typical Use Case

Suppose you run an international eCommerce 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: ref('order', 'region')
    operator: 'is'
    value: H.current_user.region
  }
}

Now, when a manager logs in, they will only see data for their assigned region—enforced automatically at the dataset level.

Caveats

• 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.
• Development Workspace Limitation: Row-level Permission as-code cannot be tested while in the Development Workspace. Permissions will only take effect after the dataset is published to production.

---

By defining row-level permissions as code, you gain full control, auditability, and flexibility over your data access policies—making your analytics workflow more robust and secure.