Row-Level Security in Power BI: How to Separate Report Access

In a bank vault, dozens of safe deposit boxes can sit in the same room, yet a client’s key opens only their own box. A Power BI report can work on similar logic: people open the very same page but see different rows of data. This is handled by Power BI row level security (RLS) — a mechanism that restricts access to data depending on the user’s role or account.

What Is Row-Level Security in Power BI?

To answer briefly the question of what RLS in Power BI is, it is a mechanism that determines which rows of the data model are available to a specific user. The report itself can remain a single one: a regional manager will see the sales of their own region, while a director sees the consolidated figures.

Row-level security in Power BI works through Power BI roles and filter rules. They are created in Power BI Desktop, while users or groups are assigned to the corresponding roles in Power BI Service. When a company uses Power BI for business, RLS determines which slice of data each user receives after signing in.

How does RLS work in Power BI? The system identifies the user’s role, applies the corresponding rule and returns only the permitted rows.

Why Business Needs RLS

When a single dashboard is used by directors, managers and separate departments, not everyone needs full access to Power BI reports. Without RLS you have to either create separate versions of the report or open up a wider set of data than a particular user actually needs.

RLS makes it unnecessary to multiply separate versions of one report merely because user permissions differ. The data stays in a single model, and the available slice is determined by the role. Power BI access permissions depend on more than RLS alone. Permissions in the Power BI workspace and access to the report itself are configured separately: RLS does not replace these permission levels. Restricting data access in Power BI matters especially when different departments work with the same report. Sales may need customer and regional metrics, finance needs margins, and management needs the overall picture. Giving everyone identical access in such a situation simply makes no sense.

Example: Regional Managers See Only Their Own Data

The easiest way to show access separation in Power BI is on a regional structure. The company has one sales report, but each person only has access to the part of the data they need:

As a result, the analyst maintains one report, and changing figures or the structure of a visualisation does not require synchronising several copies of it. That is exactly why, during the implementation of business analytics based on Power BI, the access logic is worth thinking through together with the data model and user roles.

How to Set Up RLS in Power BI

To understand how to set up RLS in Power BI, it is enough to go through a few basic steps:

Power BI has several levels of access. Power BI workspace permissions define a user’s rights within the workspace, while Power BI report permissions define access to a specific report. RLS works at the level of the data model, but the result also depends on the user’s role in the workspace. RLS restrictions apply to Viewer, whereas Admin, Member and Contributor have broader access rights.

Static Roles

Static RLS in Power BI uses fixed rules. For the “South” role, for instance, you can define a condition that keeps only the rows of that region, and then assign the relevant users to the role in Power BI Service.

This option is convenient when there are few segments, the rules are stable and easy to maintain. If the access structure changes often, the number of static roles and manual assignments grows quickly.

Dynamic Roles Based on User Data

In Dynamic RLS in Power BI, the rule depends on who exactly opened the report. One common option is the USERPRINCIPALNAME() function, which returns the user identifier (UPN) in Power BI Service, together with a separate mapping table, for example “user → region”.

This is what dynamic row level security in Power BI is built on: there is no need to create a separate role for every region or employee — the required slice is determined by the user’s data.

If you reduce static vs dynamic RLS to the practical difference, it lies in the way access is determined:

If data about access rights is already stored in corporate systems, filtering data by user in Power BI does not have to be maintained manually. In a Data Platform for business, for example, the “user → region” mapping table can be updated together with other corporate reference data.

Common Mistakes When Configuring RLS

Most often RLS produces the wrong result because of the model or permission configuration:

RLS in Power BI vs Data Security in Microsoft Fabric

RLS in Power BI works at the level of the data model and determines which of its rows are available to a user. Microsoft Fabric covers more levels of access: workspaces, individual platform resources and the data itself are controlled separately.

In Fabric, RLS is responsible for filtering rows in the data model. Access to workspaces, individual platform resources and other data levels is configured separately.

How IWIS Sets Up Data Security for Clients

In two companies with the same number of users, the RLS scheme can be completely different. In one, a few stable roles by region are enough; in another, access depends on the position, the department, the client or several conditions at once. That is why the IWIS team first builds an access matrix and only then defines static or dynamic rules for it and verifies them together with workspace permissions.