Home › Row-level security
How do you make sure everyone only sees their own figures?
With row-level security. You record in the model which rows belong to which user, usually through a table linking sign-in names to departments, regions or customers. The report then stays one report and what you see depends on who is looking. That works better than a copy per group, because copies drift apart within months.
How it works
- A table maps sign-in names to what someone is entitled to: department, region, customer or cost centre.
- That table joins the model through a relationship, so the filter carries through to the facts.
- A role records that a user only sees their own rows.
- The role is attached to a group, not to individual people.
The four mistakes we see most
- A hand-maintained list. It falls behind the moment someone changes role or leaves.
- Permissions per person instead of per group. Unmanageable past about ten.
- Only the fact table filtered. Another route still exposes totals that were not meant for them.
- Never tested. Assumed to work, until someone shares a screenshot with another department’s figures.
Half an hour is enough to know whether we fit
No slide deck and no quote at the end. We walk through your sources, your definitions and your biggest frustration.
Book half an hourFrequently asked questions
How do you make sure everyone only sees their own figures in Power BI?
With row-level security: you record in the model which rows belong to which user, usually through a table linking sign-in names to departments, regions or customers. The report stays one report; what you see depends on who is looking. That beats making a copy per group.
Why not just a separate copy per department?
Because you then have to maintain all of them. After six months they drift, one shows a different number than the other, and nobody knows which is right any more. A model with the rules inside stays one model.
Does it still hold if people download the report?
The rules live in the model in the service, so anyone reading through the service is covered. Someone who gets hold of the source file can work around it, which is why the build file should not be floating about. Permissions on the model and permissions on the workspace are two different things.
Can you test it before it goes live?
Yes, and it belongs in the process. You can view the report as a specific role or user and check what they get. We record those checks so that after every change you can still show that nothing leaked.
How do you keep track of who may see what?
In a table coming out of a source system, not a list someone maintains by hand. HR system, active directory, or wherever account management lives. Manual lists fall behind the moment someone changes role.