Row-Level Security (RLS) in Tabular Models

Row-level security (RLS) restricts data access for given users, ensuring that users only see the rows they are authorized to view. In Azure Analysis Services and Power BI Premium, RLS is defined using DAX filter expressions attached to roles.

Key Concepts

Roles: Container for DAX filter expressions.
Security Filters: DAX expressions applied to tables.
Dynamic RLS: Uses USERPRINCIPALNAME() or USERNAME() to filter data based on the current user.
Static RLS: Hard‑coded filter expressions.

Creating a Role with RLS

Follow these steps in Visual Studio (Tabular Model Designer) or Power BI Desktop.

Open the Model.bim file.
Navigate to the Model menu → Roles.
Click New and name the role (e.g., SalesRegion).
Select a table and define a filter expression.

You can assign multiple filter expressions to different tables within the same role.

Example: Dynamic RLS using USERPRINCIPALNAME()

The following DAX expression restricts rows in the Sales table to the region associated with the logged‑in user.

Sales[Region] = LOOKUPVALUE(
    UserRegion[Region],
    UserRegion[UserPrincipalName],
    USERPRINCIPALNAME()
)

Testing RLS

After publishing, you can test the role by using the View As Roles feature:

Power BI Desktop: Modeling → View As
Azure Analysis Services: Use Role in SQL Server Management Studio.

Best Practices

Practice	Reason
Prefer Dynamic over Static RLS	Reduces maintenance and scales with user base.
Minimize the number of roles	Improves processing time.
Use USERPRINCIPALNAME() for Azure AD users	Ensures accurate user identification.
Document filter logic	Facilitates future updates and audits.

Deploying RLS

After creating roles, deploy the model to the target workspace.

Deploy-TabularModel -Server "asazure://westus2.asazure.io" -Database "SalesModel"