Row-level security is a filter on the model

The idea

Row-level security (RLS) is a filter on the model that the reader cannot turn off. You write a rule for a table, a true/false expression such as customers[segment] = "business", and for anyone in that role the table keeps only the rows where the rule is true. Everything else is gone before a single measure runs.

The important word is model. RLS is not a slicer hidden on a page and it is not a filter on a visual. It is applied to the data the whole report reads, so a table, a chart, a tooltip and an export all see the same reduced rows.

Why it exists

Harbor & Pine's forty managers open the same report each morning, and each should see only the customers they are responsible for. There are two ways to give them that: build forty reports and keep them in step, or build one and let the model decide what each person may see. The second is the only one that scales, and the only one that changes automatically when a territory moves.

It is also a safety property. If a number in a report is wrong because of a slicer, someone clicked the wrong thing. If a restricted row appears to the wrong person, the report has leaked. Security that depends on readers behaving is not security.

How it works under the hood

Evaluate a rule in four steps.

1. The user signs in. The Service knows their email, which a rule can read with USERPRINCIPALNAME().
2. The user's role applies. Roles are defined in Desktop (Modeling → Manage roles) and people are added to them in the Service (dataset Security).
3. The rule filters its table. A static rule names the values (state in a list). A dynamic rule looks them up from a table, so the logic is written once.
4. The filter flows along the relationships. Filtering customers filters orders and then order_items, exactly as a slicer would. Tables with no relationship to customers are not filtered.

Static and dynamic

A static role is one rule per group: West, Texas, B2B. It is simple and right for a handful of groups. It becomes a chore with twenty, and every quarter someone edits the model.

A dynamic rule asks "who is this person?" and looks up what they may see.

The mapping lives in a table (Territories here) that Sales Ops edits as plain data. The model and the rule never change. Two details matter: compare to USERPRINCIPALNAME(), and think about the person who is not in the table, because for them the rule is false on every row.

Combining rules

Two combinations come up as soon as the report grows. Inside one role, a rule on customers and another on products both apply: a row must pass both, so they narrow each other. Across roles, the opposite holds. A person who belongs to two roles gets the union: a row is visible if either role allows it. A common mistake is to add someone to a broad role "just in case" and quietly cancel the narrow role that was meant to restrict them.

A single rule can also combine tests with &&. The B2B report uses one: customers[segment] = "business" AND the signed-in user is the rep or the manager listed for the customer's state in a Reps table. Business customers only, and only the states that person covers. Writing the lookups into VAR lines keeps a rule like that readable: one line for the user, one for the rep, one for the manager, and a short test in RETURN.

Who RLS applies to

RLS applies to people with the Viewer role in a workspace and to app users. It does not apply to people who can edit the content: Admin, Member and Contributor see all rows, because they can open the model and remove the rule anyway. So a test with your own admin account proves nothing. Use Modeling → View as in Desktop, or Test as role in the Service, to see what a user sees.

What RLS does not do

It does not hide columns (that is object-level security), and it does not make a model safe if a table that should be restricted has no relationship to the table carrying the rule. Check each table's path to the rule before you publish. What it does do is protect the model rather than the report: a Viewer with Build permission who queries the dataset from Excel gets the same filtered rows.

Common misconceptions

"I'll test the rule by opening the report myself"

If you are the owner or an admin, RLS does not apply to you and you will see everything. A rule you never viewed as another user is untested. Use View as with a real role and a real email, and also test someone who matches nothing.

"RLS hides rows in the visual"

It removes them from the model for that user, which is stronger: the rows are not hidden on the page, they do not exist for that person. That is why totals, tooltips and exports all agree with what the person sees, and why a dashboard total can differ between two people.

"One RLS role per region is the standard"

It is the simplest, and it works for three regions. At twenty it is a maintenance burden, and the roles drift from reality. A dynamic rule with a mapping table scales and is easier to audit, because the rule is written once and the data shows who sees what.