Row-Level Security

Row-level security restricts which rows a person sees in the same report or dataset, based on who they are. Tableau’s documentation states the purpose directly: “filter data based on the user that is requesting it” — a regional manager opens the company sales dashboard and sees their region. Product descriptions here follow the Tableau and Microsoft Learn documentation, checked in September 2026.

The mechanism is straightforward. What matters is where the rule is enforced, because that decides how many people can accidentally remove it.

Four places the rule can live

Where	How it works	How it fails
In the report, by hand	The author lists which people see which values	Stale the day someone changes role; unmanageable past a handful of names
In a calculated field	A rule derives the viewer’s entitlement — Tableau describes creating “a calculated field that automates the process of mapping users to data values”	Still per-report. The documentation attaches a condition: “Permissions must be secured to prevent users from seeing unfiltered data”
In a central policy	Enforced once for everything that reads through it — a data policy on a virtual connection, or a shared semantic model with roles	Only as good as its exclusivity: it protects nothing reached by another path
In the database	The source itself refuses rows the user may not see	Least flexible for BI-specific slicing, and requires the BI tool to pass the real user identity through rather than a service account

The pattern down that column is the thing to take away. The first two make every author a security boundary; the last two make the platform one. Tableau’s own argument for central policies is exactly this — they avoid “the same risk of exposing information if an author neglects to properly secure permissions.”

Who it applies to, and what it does not cover

Before the enforcement point, check whom the rule binds, because the answer is narrower than most people assume. Power BI’s documentation draws the line at permission level: RLS “only restricts data access for users with Viewer permissions. It doesn’t apply to workspace Admin, Member, or Contributor roles,” since those can edit the model — and therefore “if you want RLS to apply to people in a workspace, you can only assign them the Viewer role.” A workspace where everyone is a Contributor so that anyone can fix a report has no row-level security in effect.

Two boundaries around the mechanism itself. It does hold across clients: “even if Viewers are given Build permissions to the semantic model, RLS still applies,” including through Analyze in Excel. But it filters rows and nothing else — “if a user has access to a particular row of data, they can see all the columns of data for that row” — so a sensitive column needs object-level security, not a row rule. Names and specifics differ by product; the question to carry to any of them is which permission levels the rule skips.

The characteristic failure is silent

Picture the most ordinary accident in enterprise BI. Someone duplicates a working report to build a variant, the filter that enforced the rule does not survive the copy or is deliberately removed during development, and the copy is published. Every row is now visible to everyone who can open it.

Nothing about that reports an error. The dashboard renders, the numbers are correct, and the only signal is that they are larger than the viewer should see — which most viewers cannot judge. Compare that with a broken pipeline, which announces itself. Row-level security is in the small class of controls whose failure looks like normal operation, and that is the reason to prefer enforcement the platform performs over a step each author must remember.

Enumerate the paths, not the reports

A rule enforced in one report protects that report. The question worth asking is how many ways the underlying data can be reached.

• Another report on the same source. Built by someone who did not know a rule existed.
• An export. A download or subscription delivers rows outside the tool, where no filter applies afterwards.
• A direct connection. A notebook or SQL client reaching the warehouse table, which is why database-level enforcement is the only one that covers this path.
• A copy. An extract or a derived table carries the rows and leaves the rule behind.

That list also explains why row-level security in the BI layer and least privilege in the platform are not alternatives. The report filter shapes what a permitted reader sees; platform permissions decide who can reach the data at all, including by the paths above.

Verifying it

Two habits catch most problems, and neither is expensive.

• Test as a member of each role, not as an administrator. Where the rule does not apply to elevated accounts — Power BI documents that it “only restricts data access for users with Viewer permissions” — a check performed with one confirms nothing about what a regional user sees. Most tools offer a view-as capability; use it, and keep a low-privilege test account for the cases it cannot simulate.
• Assert the row counts. A test that checks a known role sees exactly the expected number of rows turns a security property into something a pipeline can verify after every change, rather than something someone remembers to eyeball.

One cost is worth planning for. Filtering by viewer means results are less shareable between users, so caching and pre-aggregation help less than they would otherwise — a report that is fast when everyone sees the same rows can be noticeably slower when everyone sees different ones. Central enforcement with a small number of roles is usually the better trade than a rule that varies per person.

How this fits with models, refresh, capacity, and content ownership in an enterprise BI platform is worked through in The Dashboard Is Slow and Nobody Owns It.

References: Tableau Help, Overview of Row-Level Security Options in Tableau; Microsoft Learn, What is Power BI Premium?; Microsoft Learn, Row-level security (RLS) with Power BI.