Stop testing RLS at row detail: a pre-review checklist for totals, tooltips, and exports

Start With the Total, Not the Detail Table

RLS is a query-time row filter, not a measure-level permission boundary.

Microsoft's guidance is explicit: RLS filters table rows only. It cannot restrict access to model objects, including tables, columns, or measures.

A DAX expression cannot override RLS, and it cannot detect that RLS is enforced.

In practice, a detail table can show only the territory the viewer is allowed to see. A measure such as Total Revenue still sums the underlying fact table without knowing that the viewer's identity should exclude a segment.

The result is a visual total that does not match the visible rows. That difference can reveal the hidden segment's performance.

The Detail Table Can Be Clean While the Measure Leaks

Most RLS test scripts follow the same sequence: sign in with a restricted account, open the primary dashboard, confirm the detail table returns only authorized rows, and sign off.

That check validates the row filter. It says nothing about the measure layer.

Power BI visual totals are DAX calculations, not sums of the rows currently displayed. A matrix grand total, a card, or a KPI can evaluate a measure in a filter context that differs from the detail rows.

If the measure references an unfiltered summary table, uses ALL or REMOVEFILTERS, or computes a ratio over an all-region denominator, the total can include the restricted segment.

The row-level detail remains clean. The aggregate leaks.

The Leak Vector a Clean Detail Test Won't Catch

Microsoft documents a pattern called partial RLS. A summary model table is deliberately left unfiltered so a ratio measure can use an all-region denominator.

The summary table returns revenue for all regions because it is not constrained by RLS filters.

If the model contains only two regions, a report user can calculate the hidden region's revenue from the all-region total minus the visible region's revenue.

Finance teams adopt similar summary tables for margin, market share, or budget variance ratios without realizing the same mechanism leaks board-level numbers.

The denominator works as intended. The unintended consequence is a disclosure channel.

Three Leak Vectors That Survive a Detail Check

Visual totals and subtotals. A matrix subtotal is calculated by the DAX measure, not by adding the displayed row values. A card at the top of a report uses the same measure in a global context. If the measure contains an all-region calculation or unfiltered summary table, the total can show company-wide revenue while the rows show only Atlantic Canada. Check each card, KPI, matrix total, and subtotal against a manual sum of the visible detail rows. A mismatch is a leak until proven otherwise.

Report tooltips. Tooltip pages are separate report pages that receive the hover context. A tooltip page can contain a card or a summary visual whose measure removes the current filter or reads a summary table. When a reviewer hovers over a visible branch, the tooltip can reveal all-company metrics including the hidden segment. Test every tooltip page under the restricted role, and disable or rebuild any tooltip that exposes aggregate values outside the visible context.

Export files. Power BI export options do not all behave like the filtered visual. Summarized data and data with current layout can include the same totals and subtotals shown in the report, including the RLS leak. Underlying data exports honour row filters but are not always available to report consumers, and they may still include summary tables if those tables are part of the model query. A board pack built from exported totals carries the hidden segment's contribution into Excel, where it is consolidated further.

Testing with the same role as the report consumer matters. Admin test accounts often have no RLS applied or see all roles, which defeats the test. The least-privileged test account should match the exact role and data scope of the intended audience. A finance systems lead should maintain a small matrix of test identities: one per security role, including the most restricted role and one role with overlapping territories. The matrix should be refreshed when roles change, because a new segment mapping can silently reopen a previously closed total.

Tooltips deserve a dedicated test because they are often added late in report development. A developer may create a tooltip page to show margin by product without considering RLS. The tooltip page's measure may use ALL(Region) to show a benchmark, and that benchmark includes the suppressed segment. The tooltip is one hover away from disclosure.

Export testing should include PDF, PowerPoint, and Excel summarized data. PDF and PowerPoint exports render the current report page, including any leaking totals and tooltips. Excel summarized data uses the report query and can include measure totals. A finance pack built by exporting from multiple dashboard pages can inherit the leak and spread it across a workbook.

A Validation Order That Catches the Aggregate Leak

Run this five-minute pattern after the row-level check.

Sign in with the least-privileged test account. Compare each visual total to the manual sum of visible rows.

Hover all report tooltips and watch for hidden-segment measures.

Export summarized data and data with current layout, then verify the exported totals match the visible totals only.

Search the semantic model for ALL, REMOVEFILTERS, and unfiltered summary tables used in measures.

For two-region or two-segment models, test reverse-calculation from the total minus the visible amount.

A Worked Example: The Two-Region Retail Dashboard

A Canadian retail company applies RLS so regional managers see only their province's branch rows. The revenue measure is SUM(Sales[Amount]).

The Ontario manager opens the dashboard. The detail table returns Ontario branch rows summing to $3.1 million.

The top card shows Total Revenue of $4.2 million because a denominator summary table feeds an all-region value into the measure.

The difference of $1.1 million is Quebec revenue, which that manager is not authorized to see.

Because only two regions exist, the manager can calculate Quebec exactly by subtracting Ontario from the total.

The row-level test passed. The visual total did not.

Limitation: Where the Checklist Still Breaks

This checklist is not a substitute for object-level security when the objective is to hide a column or a measure. RLS cannot limit measures or columns, and OLS restricts tables, columns, and metadata rather than measures directly, though a measure that references a restricted column becomes restricted.

The checklist also cannot catch every custom DAX pattern in a large semantic model. High-cardinality test matrices and near-real-time models require automated test harnesses, and a human reviewer must still inspect ALL, REMOVEFILTERS, and unfiltered summary tables before a board pack ships.

A limitation of any manual checklist is that it inspects known vectors, not unknown custom calculations created after the last review.