Row-Level Security

Row-level security restricts which rows a person sees in a report or dataset according to their identity and entitlements. A regional manager, for example, can use the company sales dashboard while seeing only their region. Tableau and Power BI provide several enforcement options, whose access boundaries matter as much as the filtering rule.

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	Requires a trustworthy user or tenant context through a supported connector: delegated identity or a trusted application session context. The database and integration determine the available policies.

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

Power BI semantic-model RLS applies to workspace Viewers, including Viewers with Build permission and those using Analyze in Excel. Workspace Admins, Members, and Contributors can edit the model and are not restricted by its RLS. Giving every reader Contributor access therefore defeats that model-level restriction. Review effective permissions as well as role definitions.

RLS restricts rows, so use object-level security when permitted rows contain columns the reader must not see. Database RLS also needs a trustworthy identity context. SQL Server’s documented middle-tier pattern uses a shared application database account and SESSION_CONTEXT for the current user. The application must authenticate that user, control the context and account, and handle pooled connections correctly. Confirm connector support; a stored service credential alone does not identify the viewer.

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 returned rows can include data the viewer is not entitled to see, even when the count or total looks plausible. Successful rendering therefore needs a separate entitlement check. A row-level security failure can look 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 afterward.
• 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 permitted and forbidden rows. Compare expected keys with actual keys for each test identity. Expected {A1, A2} and returned {A1, B1} both have two rows, but B1 is unauthorized. Keep counts as a supplementary signal and test for both missing allowed rows and present forbidden rows. Include unmapped identities, multiple-role membership, and cross-tenant or cross-region cases; use actual low-privilege accounts for access paths that view-as cannot simulate.

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
• Row-Level Security — SQL Server