Implementing Row-Level Security (RLS)

What Is Row-Level Security?

Row-level security (RLS) restricts the rows of data that a user can access in a Power BI semantic model.

It is especially useful when a single report serves multiple users who should see different portions of the same dataset.

For example, a national sales report may contain records for every state. RLS can restrict a regional manager to records associated with their assigned region.

Instead of maintaining separate copies of the report for every region, an organization can use an appropriately configured security model.

Static and Dynamic Row-Level Security

Static RLS uses predefined rules to restrict data.

For example, a role may filter a region column so that users assigned to that role can access only Chennai sales records.

Dynamic RLS uses information about the signed-in user, such as their organizational identity, to determine which rows they can access.

Dynamic RLS is useful when many users need different data access without requiring a separate role for every individual.

Creating a Basic RLS Role

Consider a table named Sales containing a column named Region.

To create a simple role in Power BI Desktop:

1. Open the Power BI Desktop report.
2. Select the Modeling tab.
3. Choose Manage roles.
4. Create a new role, such as ChennaiManager.
5. Select the Sales table.
6. Add a filter expression such as:

[Region] = "Chennai"

1. Save the role.

2. Use View as to test the role's behavior.

3. Publish the report and semantic model when ready.

4. Assign authorized users or groups to the role in Power BI Service.

This example assumes the Sales table contains a correctly populated Region column and that the model's relationships allow the filter to affect the relevant visuals.

Understanding Dynamic RLS

Suppose an organization maintains a user-access table named UserRegion with these columns:

A dynamic RLS rule can use the signed-in user's identity to identify their permitted region.

An illustrative filter expression for the UserRegion table is:

[UserEmail] = USERPRINCIPALNAME()

The access table must be connected to the sales data through appropriate model relationships, or the security logic must otherwise be designed to apply the intended restriction.

For this example, the organization must ensure that the user identity values match the identities returned in the Power BI environment.

Testing RLS

Before deploying RLS, test it carefully.

In Power BI Desktop, use View as to check how the report behaves under a selected role.

After publishing, test the relevant users' actual access in Power BI Service.

Check that:

• Users see only their authorized records.
• Totals and calculations respect the security filters.
• Related tables do not expose unintended information.
• Users cannot bypass the intended restrictions through other permission paths.

Workspace Admins, Members, and Contributors have different interactions with RLS than ordinary report viewers. In particular, do not assume that assigning a user to an RLS role will restrict the data that workspace editors can access.

RLS should always be tested in the actual sharing and deployment configuration.