What is Row-Level Security (RLS) in Power BI?

Row-level security (RLS) restricts data access at the row level for specific users of a Power BI semantic model. You define filters inside roles, so a single report shows each person only their own rows. Microsoft's documentation is clear on one limit: RLS applies to workspace Viewers only, not to Admins, Members or Contributors.

How does RLS actually work?

RLS lives in the semantic model, not in the report. Per Microsoft Learn, you define roles and DAX filter expressions in Power BI Desktop under Modeling → Manage Roles — but you cannot assign users there. Membership is managed in the Power BI service, on the semantic model's Security page.

Roles are additive: someone in both a Sales role and a Marketing role sees both sets of rows. Someone in no role at all typically sees nothing — a blank report rather than an error, which is the usual cause of a "my dashboard is empty" ticket.

What does a worked example look like?

Each account manager should see only their own accounts.

1. Add a user-mapping table — one row per person, with their sign-in name and the accounts they own.
2. Relate it to the fact table, following the same one-to-many direction as the rest of your star schema.
3. Create a role called Account manager with the filter [UserEmail] = USERPRINCIPALNAME().
4. Publish, then add the team to that role in the service.

One role definition now filters differently for every user. Microsoft warns that USERPRINCIPALNAME() returns the sign-in identifier, which is not always the person's email address — build the mapping table from the UPN, or half the team sees a blank page.

What does RLS not do?

• It does not hide columns. If a user can see a row, they see every column on it. Restricting columns needs object-level security instead.
• It does not apply to editors. Admin, Member and Contributor workspace roles bypass it. Build permission does not — a Viewer with Build permission using Analyze in Excel is still filtered.
• Testing it is not using it. The Test as role feature evaluates dynamic expressions using your identity, so USERPRINCIPALNAME() returns your own UPN, not the person you are simulating.

Two further traps: Microsoft 365 groups cannot be added to an RLS role, and switching on bi-directional security filtering can noticeably slow queries.

Get RLS wrong and the failure is quiet — nobody reports seeing data they should not. Test it with real accounts before a model goes live. We build governed models as part of our Power BI work, within the wider data practice.

Frequently asked questions

What is row-level security in Power BI?

Row-level security restricts data access at the row level for specific users of a Power BI semantic model. You define filters inside roles, and each role decides which rows its members can see. One report then shows every person a different slice of the same data.

Does row-level security apply to everyone in a workspace?

No. Microsoft's documentation states that RLS only restricts data access for users with Viewer permissions, and does not apply to the workspace Admin, Member or Contributor roles, because those roles carry edit permission on the semantic model.

What is the difference between static and dynamic RLS?

Static RLS hard-codes the filter in the role, such as region equals North. Dynamic RLS uses the USERPRINCIPALNAME() function against a user-mapping table, so one role definition filters differently for every signed-in user. Dynamic is the usual choice beyond a handful of people.

Can row-level security hide columns as well as rows?

No. Microsoft is explicit that if a user has access to a row, they can see every column on that row. Restricting columns or column metadata needs object-level security, which is a separate feature.

---

Easy Insight is a UK consultancy for AI, web, apps and data — senior specialists only, no juniors.