In the Power BI Service, which users bypass RLS on a semantic model, and why?
answer
- roles restrict readers, not editors
- three workspace roles carry edit rights
- your own test account is probably exempt
- Build permission still honours the role
- no role assigned means no data, not all data
basics
~20 sUsers with workspace Admin, Member or Contributor roles hold edit permission on the semantic model, and RLS is not applied to them. Roles restrict read-only consumers — Viewers and app audiences — and a read-only user assigned to no role sees no data.
solid answer
~50 sRLS restricts **read-only** access. In the Power BI Service, workspace **Admin, Member and Contributor** roles all carry edit rights on the semantic model, and those users see the model unfiltered no matter which role they were added to; the same is true of the model's owner. Enforcement applies to **Viewers**, to people consuming a published app, and to anyone connecting with Build permission from Excel or the XMLA endpoint — those paths all go through the roles. A consequence people forget: a read-only user who is a member of **no** role cannot see the model's data at all, which is a safe failure but looks like a broken report. The practical design is to keep consumers out of the workspace entirely — publish an app or grant Viewer — and to keep development in a separate workspace from consumption.
code
text · 10 linesWorkspace role edit model? RLS applied?
----------------------- ----------- ------------
Admin yes no
Member yes no
Contributor yes no
Viewer no yes
App consumer (audience) no yes
Build permission only no yes
Viewer in no role -> no data (error), not full accessgo deeper
Remember that RLS applies to people who only read the report — Viewers and app users — and not to those who can edit the model in the workspace.
Name the exempt workspace roles, explain that enforcement lives in the model so exports and Excel connections are covered too, and know that no role means no data.
Diagnose the common false alarm of testing with an editor account, and design the permission model around it: apps and Viewer for consumers, Build rather than Contributor for self-service, dev separated from consumption.
Own the boundary: decide what may live in an import model at all given that the file is the data, define who may hold Contributor, and set a review cadence for additive role membership.
## The rule Row-level security is a restriction on **reading** a semantic model. Anyone whose permission includes editing that model is, by definition, able to change or remove its roles, so the Power BI Service does not pretend to restrict them: **RLS is not applied to users with edit permission on the model**. In workspace terms that means the **Admin**, **Member** and **Contributor** roles, plus the model's owner. Only the **Viewer** workspace role, app consumers, and people with Build permission on a shared model are subject to roles. This single fact explains most "RLS isn't working" tickets. The developer tests with their own account, which is a workspace Member, sees everything, and starts rewriting DAX that was never wrong. ## What is enforced, and everywhere When the user *is* subject to RLS, the restriction is on the model, not the report, so it holds on every path out of it: report visuals and their totals, drillthrough and tooltips, Export data, paginated reports over the same model, Analyze in Excel, and any tool connecting through the XMLA endpoint with Build permission. That uniformity is the reason RLS belongs in the model rather than in report-level filters, which a determined user can remove from the filter pane. ## The no-role case A read-only user with access to a model that has roles defined, but who is a member of **none** of them, does not fall back to full access — they cannot see the data and the report surfaces an error or empty visuals. Fail-closed is the right default, but it means onboarding is a real step: adding people to the workspace or the app is not enough, they must also land in a role. Assign an Entra security group to the role rather than individuals so joiners inherit access from identity management. The reverse also matters: roles are **additive**. Someone added temporarily to a broad role keeps the union of everything their roles permit, so periodic review of role membership is part of operating RLS. ## Designing around the bypass The practical consequences are organisational rather than technical: - **Consumers should never have edit rights.** Distribute through an app with audiences, or grant Viewer on the workspace. If someone needs to build their own reports on the model, grant **Build** on the model rather than Contributor on the workspace — Build honours RLS, Contributor does not. - **Separate development from consumption.** A workspace where developers legitimately hold Member rights should not be the workspace consumers read from; promote the model into a consumption workspace where nobody has edit rights. - **The .pbix is the whole dataset.** In an import model the data is physically in the file. Anyone able to download it holds every row, regardless of roles. Where that is unacceptable, DirectQuery with source-enforced security is the only real answer, because RLS is a query-time filter, not encryption. ## Other enforcement boundaries worth knowing - **Live connections to an external Analysis Services model** enforce that model's roles at the source; the report does not define its own. - **Embedded, app-owns-data scenarios** pass an effective identity — user name and roles — in the embed token, so the enforcement is real but the identity comes from your application, not from the viewer's Entra sign-in. Getting that token generation wrong is an authorisation bug in your app, not in Power BI. - **Publish to web** produces an anonymous public page and is not available for a report over a model with RLS, since there is no identity to filter by. ## What to say in an interview The strong answer names the exempt roles precisely, states that Viewer and app consumers are the enforced population, mentions that Build permission still honours roles, and closes with the design implication: RLS is only as good as the workspace permission model around it, so reviewing who holds Contributor is part of reviewing the security of the report.
- A colleague needs to build their own reports on the model but must stay restricted. What do you grant?Build permission on the semantic model, not Contributor on the workspace. Build lets them connect from Desktop, Excel or the XMLA endpoint and create their own content, and every one of those paths goes through their RLS role. Contributor would give edit rights on the model itself, which exempts them from RLS entirely and defeats the requirement.
- Does RLS protect the data if someone downloads the .pbix file?No. An import model physically contains every row; roles are a query-time filter, not encryption. Anyone who can download the file holds the full dataset. If that is unacceptable, prevent download through workspace permissions and settings, or move to DirectQuery with security enforced at the source so the sensitive rows never enter the model in the first place.
- Why does a Viewer who belongs to no role see an error instead of all the data?Because the enforcement fails closed: with roles defined on the model, a read-only user must be matched to one to obtain any rows. It is the safe direction — a missed onboarding is reported as a broken report rather than silently exposing everything — but it makes role assignment a required onboarding step, best handled by putting an Entra security group in the role.
saying these in an interview costs you the question
- Testing RLS with a workspace Member account
- Assuming Contributor access is safely restricted
- Thinking a user in no role falls back to full access
- Believing RLS protects an exported or downloaded file
- Expecting report-level filters to substitute for roles