Row-level security (RLS) is how you build one report that shows each person only the rows they are allowed to see. The area manager for the South West opens the sales report and sees the South West. The finance director opens the same report and sees everything. Same file, same link, same charts, different data.
The reason it matters commercially is timing. Designing RLS in from the start adds a modest amount of work. Adding it to a finished model, after reports have been built and shared, is a rebuild of the security layer and often of the model underneath it. It is one of the few genuinely expensive things to change late, which is why it belongs in your first conversation with whoever is building your reporting, even if the answer is that you do not need it.
Do you actually need row-level security?
| Situation | Do you need RLS? | The alternative |
|---|---|---|
| Everyone in the business can see everything | No | One report, no filtering, keep it simple |
| Managers should see only their own branch or region | Yes | Separate reports per region, which multiplies maintenance |
| Salespeople shouldn't see each other's commission | Yes | This is the classic case, and it's a real one |
| External clients viewing their own data in your report | Yes, and carefully | Getting this wrong is a data breach, not a bug |
| Board sees all, department heads see their function | Yes | Usually the simplest RLS design there is |
| You just want to hide a confusing page from most people | No | That's report design, not security |
| Sensitive HR data mixed with general reporting | Consider separating | Sometimes a separate model is safer than clever filtering |
The last two rows matter. RLS gets proposed for problems it does not solve. If the goal is to stop people being confused by detail they do not need, that is a design decision about what belongs on which page. Security is for things people must not see, not things they need not see, and conflating the two produces models that are complicated for no protective benefit.
How does it actually work?
You do not need the technical detail to buy it well, but the shape helps.
The model holds a rule that says, in effect, "show rows where the region matches the region of the person who is logged in". Power BI knows who opened the report, because they signed in with their work account. It applies the rule before any chart is drawn, so every total, every chart and every export reflects only that person's rows.
Two things follow from that, and both matter to a buyer.
First, the filtering happens in the model, not in the report. Someone cannot get around it by exporting the data, opening it in Excel, or connecting to the model with another tool. This is the important difference between real security and merely hiding a page, and it is why "just hide the tab" is not an answer when the data genuinely matters.
Second, it depends on a reliable mapping between people and the data they own. Somewhere there must be a list saying this email address maps to this region. Maintaining that list is the ongoing work, and it is usually where RLS goes wrong: not in the technology, but because nobody updated the list when someone changed role.
What makes it expensive to add later?
Three things, in increasing order of pain.
The model may not contain the column you need to filter on. If your sales data has a branch code but your report was built without ever bringing the branch table in, the security rule has nothing to attach to. That is a modelling change, not a settings change.
Existing reports may already show totals that will change. When a report that has been showing company-wide figures for a year suddenly shows regional ones, every screenshot in every old email disagrees with the live report. That needs communicating rather than just deploying.
And the mapping list has to be built and agreed from scratch, usually by someone in HR or operations who has other work on. This is the part that takes calendar time rather than build time.
None of that is catastrophic. It is just several days of work and one awkward set of conversations, in place of an hour of design at the start. Whenever I run a health check on an estate that has grown organically, "security was never designed in" is one of the more common findings, and it is always cheaper to have known about it earlier.
What does good RLS design look like?
Keep the number of rules small. One rule that filters on region, driven by a table mapping people to regions, is maintainable. Fifteen overlapping rules with exceptions are not, and after a year nobody can say with confidence who sees what.
Drive it from data, not from a hard-coded list. If the rule says "these four email addresses see everything", it will be wrong within months. If it reads from a table someone maintains, it stays right, because updating a table is a normal business task.
Make the roles match how the business actually works. If your business has regions, secure by region. If it works by account manager, secure by account manager. Attempting to build a security model more sophisticated than the organisation chart creates permanent maintenance.
Test it with real accounts before go-live. Not by trusting the preview, but by asking an actual regional manager to open it and confirm they see their region and nothing else. This is the step that gets skipped under deadline pressure, and it is the one that catches the mistakes that matter.
Write down who is meant to see what. In a year, when someone asks whether a particular person should be able to see a particular figure, the model can tell you what happens but not what was intended. Only documentation can do that, and it belongs in your project handover.
What does it cost?
Designed in from the start on a model that already has the right structure, RLS is usually a small part of a build rather than a line item you would notice. Added afterwards, budget for the model change, the retesting of every existing report, and the time to build the person-to-data mapping. On an established estate that can be several days.
The variable that moves it most is whether your data already contains a clean way to identify who owns what. If every sale has a valid branch code and every branch has a manager on record, it is straightforward. If branch is sometimes blank, sometimes spelled two ways, and sometimes belongs to a manager who left, then the security work is really data quality work, and that is a different job with a different cost. If that sounds familiar, the data quality symptoms are worth reading first.
Where RLS goes wrong
Nobody owns the mapping. Someone changes region, the list is not updated, and they either lose access to their own numbers or keep seeing their old region's. This is the most common failure by a distance, and it is organisational rather than technical.
It is assumed rather than checked. Everyone believes the security is on because it was specified. Nobody has verified it since go-live. Check it periodically, especially after any change to the model.
It is used to hide something that should not be in the model at all. If a dataset contains information most people must never see under any circumstances, sometimes the right answer is a separate model with separate access rather than one model with clever filtering. Fewer moving parts, less to get wrong.
Blank means visible. A common and quiet failure: rows where the filtering column is empty may fall outside every rule, and depending on how the rule is written, that can mean nobody sees them or everybody does. Both are wrong and neither is obvious. Worth explicitly testing.
Common questions
What is row-level security in Power BI?
It is a rule stored in the data model that limits which rows of data each person can see, based on who they are when they sign in. One report can then serve people who are each entitled to a different slice of the data, without building separate copies for each of them.
Is row-level security secure enough for client data?
The mechanism itself is sound: it filters in the model, so it applies to exports and to other tools connecting to the model, not just to the visible report. Whether your implementation is safe enough for external clients depends on how carefully it was designed, tested and documented. For client-facing data I would expect explicit testing per client and a written record of who can see what.
Can people get around it by exporting to Excel?
No. Because the filtering happens in the model before any data reaches the report, an export contains only the rows that person was allowed to see. This is the practical difference between row-level security and hiding a report page, which is easily bypassed.
Does RLS slow reports down?
A well-designed rule has a small effect that most users will never notice. Complicated rules, particularly ones involving many overlapping conditions, can noticeably slow things down. If a report is slow and has elaborate security, that is worth checking, though it is rarely the main cause. The usual culprits are in why your Power BI report is slow.
Can I add row-level security to an existing report?
Yes, but expect it to be a proper piece of work rather than a setting. The model may need changing to include the column you filter on, every existing report needs retesting because totals will change, and you need a maintained list mapping people to their data. Days rather than hours on an established estate.
Who should maintain the list of who sees what?
Someone in the business, not the person who built the report. It changes when people change roles, which is an HR or operations event rather than a technical one. If the only person who can update it is an external consultant, you have created a dependency you will resent within a year.