Row level security (RLS)

Row-Level Security (RLS) is a Power BI feature that restricts data access at the row level. Instead of creating separate reports for each user or department, you can build a single report and define rules that control which rows of data each user can see.

There are two approaches to implementing RLS:

Static RLS

You manually define filter rules for each role. For example, you create a role called “Sales Europe” that filters a Region column to only show “Europe.” Each role has hardcoded DAX filter expressions. This approach works well when you have a small, fixed number of groups.

Dynamic RLS

Instead of hardcoding values, dynamic RLS uses the USERPRINCIPALNAME() DAX function to identify who is viewing the report and automatically filters data based on a mapping table. This is the recommended approach when you have many users with varying access levels, as it scales without needing to create additional roles.

When to use which? Use Static RLS when you have a handful of clearly defined groups (e.g., 3–5 regional teams). Use Dynamic RLS when each user needs individualized access or when your user base changes frequently — this avoids constant role maintenance.

Lets work with a sample. Let’s say we have a report with time registrations, and we have 40 people working there. Each employee belongs to a department/group. We want to make sure the sales manager can see everything from the sales employees. Finance manager everything from finance, and management should be able to see everything. We also want the sales and finance employees to only see their own data. The table looks like this:

Prerequisites

Before you start configuring RLS, make sure you have the following in place:

Power BI Desktop installed (latest version recommended)
A Power BI Pro or Premium Per User (PPU) license for publishing and sharing
A data model loaded into Power BI Desktop with the tables you want to secure
For Dynamic RLS: a user-mapping table in your data source that contains user email addresses (UPNs) mapped to the data they should access
Admin or Member permissions in the Power BI workspace where you’ll publish

Important: UPN format — The USERPRINCIPALNAME() function returns the user’s email address as registered in Azure Active Directory (e.g., john@company.com). Make sure your mapping table uses the same email format.

Static RLS — Step-by-Step Configuration

Static RLS lets you create named roles, each with hardcoded DAX filter expressions. Follow these steps in Power BI Desktop.

Open the Role Manager

Open your Power BI Desktop file (.pbix) with your data model.
Go to the Modeling tab in the ribbon.
Click Manage Roles.

Create a New Role

In the Manage Roles dialog, click New to create a new role.
Give the role a descriptive name, for example “Sales Europe” or “Finance Team.”

Add a DAX Filter Expression

Select the table you want to filter (e.g., StaffGroups). And press the New Rule button.
In the Table filter enter an expression. For example:

This expression means that anyone assigned to this RLS role (Finance Team) will only see rows where the Group column equals “Finance.”

Click the checkmark to validate the expression, then click Save.

Create Additional Roles

Repeat the process for each group. For example:

“Sales Team” with filter: [Group] = “Sales”
“Finance team” with filter: [Group] = “Finance”
“Management team” with no filter (sees all data)

Tip: Multiple table filters — You can add DAX filters on multiple tables within a single role. The filters are combined with AND logic — a user must satisfy all filters to see a row.

Dynamic RLS with UserPrincipalName

Dynamic RLS eliminates the need for multiple roles by using a user-mapping table and the USERPRINCIPALNAME() function to automatically filter data per user.

Prepare the User-Mapping Table

Your data source needs a table that maps each user’s email (UPN) to the data dimension they’re allowed to see. In our sample table we have prepared for this because we also have an email address in the mapping:

This table can live in your SQL database, Excel file, SharePoint list, or any supported data source. Import it into your Power BI model.

One user, multiple regions? If a user needs access to multiple regions, simply add multiple rows for that user. For example, anna@company.com could have two rows — one for Europe and one for Americas.

Create the Relationship

In Power BI Desktop, go to the Model view.
Create a relationship between the StaffDepartments table and your fact/dimension table. For example, connect StaffDepartments[Group] to DimRegion[Group] (or directly to your Sales[Group] column).
Set the relationship direction so that the UserAccess table filters the data table. In most cases, set the cross-filter direction to Single (from UserAccess to the data table).

Create the Dynamic Role

Go to Modeling → Manage Roles.
Create a new role called “Dynamic RLS” (or any name you prefer).
Select the StaffDepartments table.
Enter the following DAX filter expression:

[Email] = USERPRINCIPALNAME()

This expression filters the StaffDepartments table to only the row(s) matching the current user’s email address. Because of the relationship you created in step 4.2, this filter propagates to the data tables — the user only sees data for their assigned region(s).

Validate and save the role.

How It Works at Runtime

When a user opens the report in DataTako:

DataTako passes the users email address to the Power BI report (UPN).
The DAX expression [Email] = USERPRINCIPALNAME() filters the StaffDepartments table to their row(s).
The relationship propagates this filter to the connected data tables.
The user only sees the data they’re authorized to view.

No extra roles needed — Unlike static RLS, you only need one role. Adding a new user is as simple as adding a row to the StaffDepartments table — no Power BI Desktop changes required.

DAX Function Reference for RLS

Here are the most commonly used DAX functions when configuring RLS:

Function	Description / Example
USERPRINCIPALNAME()	Returns the UPN (email) of the current user, e.g. user@company.com
USERNAME()	Returns DOMAIN\username format (legacy, not recommended for cloud)
LOOKUPVALUE()	Looks up a value from another table, useful for mapping UPN to data filters
CONTAINS()	Checks if a table contains a specific value
PATHCONTAINS()	Useful for hierarchical security models

Configuring RLS in Datatako

The Datatako platform provides additional capabilities for managing and embedding Power BI reports with RLS. This section covers how to configure RLS within the Datatako platform.

Embedding with Effective Identity

When Datatako embeds a Power BI report for a user, it passes the user’s identity (their UPN / email address) as the “effective identity” to the Power BI Embedded API. This means the RLS rules you configured in Power BI Desktop are automatically enforced — each user sees only their authorized data.

Setting Up RLS in Datatako

Follow these steps to enable RLS for an embedded report in Datatako:

Navigate to the report configuration in the Datatako admin pane (make sure the report has at least one RLS role configured (can be one role for Dynamic RLS or roles for static RLS).
Scroll all the way to the bottom to the access control section. Click on the ‘RLS roles’ button and add a role. In the RLS role name field, enter a role exactly as it is defined in the report.

That’s it!

DataTako always passes the email address as UPN to the report. So you can always use dynamic RLS, or pass a static role such as ‘Finance Team’ for static RLS assignment. You can pass multiple roles for a single user or user group. So if someone needs to have access to the finance and sales data, you can add two roles ‘Finance team’ and ‘Sales team’.

How Datatako passes identity to Power BI

Behind the scenes, when a user accesses an embedded report through Datatako:

Datatako authenticates the user and determines their UPN (email address).
The embed token is generated with an EffectiveIdentity parameter that includes the user’s UPN and the relevant RLS role(s).
Power BI evaluates the DAX filter expression using this identity, filtering the data accordingly.
The user sees the report with only their authorized data rows.

No changes needed in Power BI — If you’ve already configured RLS in Power BI Desktop (static or dynamic), you don’t need to modify your .pbix file. Datatako handles the identity passing through the embedding layer.

Troubleshooting & Best Practices

Common Issues

User sees all data (RLS not applied)

The user may have Admin or Member role in the workspace. These roles bypass RLS.
The user has not been added to any RLS role in dataset security.
The relationship direction may be incorrect — make sure the security table filters the data table, not the other way around.

User sees no data

The user’s UPN doesn’t match any row in the mapping table. Check for typos, case differences, or domain mismatches.
The DAX expression might have a syntax error. Re-open Manage Roles and validate.
The relationship between the mapping table and data table may be inactive or misconfigured.

Best Practices

Use dynamic RLS whenever possible — it scales better and requires less maintenance.
Always use USERPRINCIPALNAME() instead of USERNAME() for cloud-based deployments.
Use Azure AD security groups when assigning roles in Power BI Service.
Keep your mapping table in a centralized, easily maintainable data source (e.g., SQL database or SharePoint list).
Regularly audit your mapping table to remove departed users and add new ones.
Document your RLS configuration for your team, including which tables are filtered and what the DAX expressions do.
Consider performance: RLS filters are applied at query time. For very large datasets, ensure your mapping table has proper indexing.