Power BI Row-Level Security Tutorial

Power BI guide Home / Guides / Power BI

Set up Power BI row-level security roles, test them in Desktop and assign users in the Power BI service.

2026-06-16 9 min read min read Digital Adaption On this page

1. Design the access model
2. Static and dynamic RLS
3. Publish and test

Row-level security is not just a Power BI feature. It is a data ownership decision. Before restricting rows, agree who should see what, which source field controls access, and how exceptions are approved. For broader reporting repair work, see the Power BI consultancy and ERP reporting analytics pages.

Practical answer

Create a role in Power BI Desktop, filter a dimension or security table, test with View As, publish the dataset, then assign users or security groups in Power BI Service.

1 Design the access model

Start by writing the access rule in plain English. For example, sales managers can see their region, depot managers can see their site, and directors can see all regions.

Apply RLS through dimensions where possible. Filtering a clean region, customer or site table is easier to maintain than filtering multiple fact tables separately.

• Identify the user identity used in Power BI Service.
• Choose the dimension that controls row access.
• Decide how all-access users are handled.
• Keep a small test user list for validation.

2 Static and dynamic RLS

Static RLS uses separate roles such as North, South or Finance. It is simple but can become difficult to maintain. Dynamic RLS uses a security table that maps user email addresses to permitted keys.

For SMEs, dynamic RLS is often better once there are more than a handful of users or when users move between regions and sites.

-- Role filter on SecurityUsers table
SecurityUsers[Email] = USERPRINCIPALNAME()

3 Publish and test

Testing in Desktop is necessary but not enough. RLS is enforced for viewers in Power BI Service, and workspace roles can affect what people can see.

After publishing, assign users or Entra ID security groups to the dataset role. Then test with a real viewer account where possible.

1. Use View As in Desktop for each role.
2. Publish to the intended workspace.
3. Assign users or groups under dataset security.
4. Confirm build permissions and workspace roles do not bypass the intended access.
5. Ask a test user to validate the visible rows.

Common mistakes to avoid

Testing only as the report author

Authors and workspace admins may see more than normal viewers. Always test with the intended viewer experience.

Filtering facts instead of dimensions

Fact-table RLS can become duplicated and fragile. A security dimension is usually cleaner.

Ignoring export permissions

RLS restricts rows, but export and build permissions still need governance.

Validation checklist

• Plain-English access rule has been approved.
• Each role is tested with View As.
• A real viewer account has confirmed the result in Power BI Service.
• Security groups are used where ongoing maintenance is expected.
• Dataset, workspace and export permissions have been reviewed.

Need the report to reconcile with ERP?

Digital Adaption helps UK SMEs rebuild trusted Power BI, ERP and operational reporting after migrations, ownership gaps and model drift.

Review reporting trust

FAQ

Does RLS apply to workspace admins?

Workspace admins, members and contributors can have broader access than viewers. Test with a viewer account when validating security.

Can RLS use multiple allowed regions per user?

Yes. Use a security mapping table with one row per user and region, then filter from that table into the model.

Start with a 30-minute data risk call