Governance and Row-Level Security: Who's Allowed to See the Full Frame

Opening Scene

A photo agency licenses the same event photo to multiple clients, but a strict contract governs exactly which crop each client is allowed to publish — one client gets the full frame, another only a tightly cropped section that excludes a sponsor’s competitor logo standing just out of the intended shot. Row-level security in BI tools works on that same principle: the same underlying dashboard needs to show a different slice of rows to a regional manager than it shows to a company-wide executive, and getting that filtering wrong isn’t a cosmetic issue, it’s a real data exposure risk.

In Plain English

Row-level security restricts which rows of underlying data a given user is allowed to see within a shared report, typically based on their role, region, or department. Power BI implements this through roles defined in the data model, Tableau through user filters and entitlements tied to its data source layer, and Looker through access grants and filters defined directly in LookML, consistent with its governance-first philosophy. All three approaches accomplish a similar outcome, but the mechanics — and the risk of misconfiguration — differ meaningfully across the three platforms.

The Old Way

Before mature row-level security models existed inside BI tools, controlling who saw what data was a much blunter, more error-prone process:

Organizations sometimes built entirely separate reports for each audience just to control data visibility, multiplying maintenance effort and creating real risk of the reports drifting out of sync.
Access control frequently happened at the database or file level rather than inside the report itself, making it hard for report authors to reason about who could ultimately see what.
A misconfigured export or shared link could expose an entire underlying dataset, since the report layer itself had no native mechanism for filtering by viewer.

Native row-level security models, defined once inside the report or its underlying model, are a direct response to how fragile and duplicative that older, report-per-audience approach used to be.

What’s Changing (and Why AI Is the Reason)

Row-level security has become a baseline expectation rather than a premium feature, with all three vendors treating it as core infrastructure for any multi-audience deployment.
This connects directly to the identity and permissions principles covered in this content library’s dedicated access control and data security series, applied here specifically to how a single BI report serves different audiences safely.
AI-assisted natural-language querying raises the stakes on row-level security specifically, since a conversational AI feature that bypasses the same filtering logic as the visual report could inadvertently expose data a user was never meant to see, making airtight row-level security a prerequisite for safely rolling out AI features at all.

The Metaphor, Fully Extended

The Licensed Photo Crop	Row-Level Security Concept
Different clients licensed to see different crops of the same photo	Different users seeing different filtered rows of the same report
A strict contract governing exactly what each client can publish	A security model governing exactly what each user role can view
A misconfigured license accidentally revealing the full, uncropped frame	A misconfigured filter accidentally revealing rows a user shouldn’t see
The agency defining the crop rule once, applied consistently everywhere	The organization defining the access rule once, applied consistently across reports

For Beginners: What to Actually Do

Learn to recognize when a dashboard you’re viewing has row-level security applied, and understand that “you” may see a filtered version of a shared report.
Practice testing a row-level security rule with a test account representing a different role, to confirm the filtering behaves as intended.
Ask where a report’s security rules are actually defined — in the data model, a separate entitlements table, or LookML — before assuming they’re airtight.

For Practitioners and Leaders: The Deeper Layer

Treat row-level security configuration with the same rigor as any other access-control system, including regular audits, not just a one-time setup.
Apply the identity and permissions frameworks from this content library’s dedicated access control and data security series directly to your BI tool’s row-level security design.
Verify explicitly that any AI-assisted querying or conversational feature respects the same row-level security rules as the underlying visual reports before enabling it broadly.

Quick Recap

Row-level security controls which rows of data a given user sees within a shared report, based on role or attribute.
Power BI, Tableau, and Looker each implement it differently — model roles, user filters, and LookML access grants respectively.
Native row-level security replaced a fragile older era of separate reports per audience or file-level access control.
AI-assisted querying features must respect the same row-level security rules as visual reports to avoid new data exposure risks.

Where This Fits in the Series

Article 12 compared AI features across the three platforms. Article 14 looks at switching BI tools: what genuinely gets lost in translation when an organization changes systems.