In Power BI Desktop, how do you check what an RLS role sees before publishing?

## Why testing is a named step RLS is the one part of a Power BI model whose failure is silent and expensive: a mis-propagated filter shows *more* data, and nothing on the page says so. Nobody in the report sees an error; the number is simply too big. So verifying a role is not a nicety, it is the acceptance test for the feature. ## Testing in Power BI Desktop Desktop's **View as** renders the whole report as though the selected role's filters were applied. The report re-queries, the visuals shrink to the permitted rows, and a coloured banner tells you which role you are simulating so you cannot forget you are in it. You can select more than one role at once, which is important because **roles are additive**: a user in two roles sees the union of what each role permits, not the intersection. For dynamic RLS the role alone is not enough — the filter depends on the identity, so Desktop lets you supply **Other user** with a UPN. That string becomes what `USERPRINCIPALNAME()` returns while the simulation is active, so the entitlement table is exercised exactly as it will be in production. You must still tick the role as well; supplying a user without the role does nothing, because it is the role that carries the filter. ## Testing in the Power BI Service After publishing, the semantic model's security page lists each role and its members, and lets you view the report as that role. This is worth doing even after a clean Desktop test, because the Service is where the real identity, the real membership and the real refreshed entitlement data come together. Desktop tested the *logic*; the Service tests the *deployment*. ## What to actually test A useful minimum set: 1. **A user with several permitted keys** — confirms the union works and does not silently pick one row. 2. **A user with exactly one key** — confirms the numbers match a hand-calculated figure. Have the expected total ready from the source before you look. 3. **A user absent from the entitlement table** — should see no rows, not all rows. If they see everything, the filter is not propagating. 4. **Every fact table on its own visual** — this is where propagation gaps hide. A second fact table added last sprint, or a table with an inactive relationship, will still show unrestricted totals while the main page looks correct. 5. **A grand total, not just a detail table** — the total is computed from the permitted rows, so comparing it against a known per-user figure is the cheapest leak detector you have. ## What the simulation cannot tell you View as tests the **model's filters**. It knows nothing about the permissions layer above them, and two production failures live there. First, a user with edit rights on the workspace — Admin, Member or Contributor — is not subject to RLS at all, so a perfectly tested role protects nothing if consumers were given the wrong workspace role. Second, membership: Desktop holds no members, so a role that filters correctly may simply have nobody, or the wrong Entra group, assigned to it in the Service. It also cannot tell you that a permission change has been picked up: in an import model the entitlement rows are as of the last refresh, so test after refreshing rather than before. ## Automating the check Beyond manual clicking, the model can be queried under an identity through the XMLA endpoint, which makes it possible to run a small suite of expected-total assertions as part of a deployment pipeline. That is the mature version of the same idea: for a set of known users, the model must return exactly these totals. It is worth mentioning in an interview because it turns a manual, forgettable step into a regression test that survives the next model change.