Power BI Row-Level Security (RLS): Enterprise Guide

Power BI Row-Level Security (RLS) Enterprise Guide (2026)

Row-Level Security (RLS) is the authorization layer in Power BI that restricts which rows a user sees in a report or dataset. Done well, RLS scales to Fortune 500 with thousands of users, dozens of authorization patterns, and integrates with Microsoft Entra ID, Microsoft Fabric, and Microsoft Copilot.

This is the working enterprise RLS guide EPC Group uses for Fortune 500 Power BI deployments — pattern selection, dynamic vs static RLS, performance tuning, multi-tenancy, and integration with Object-Level Security (OLS) and sensitivity labels.

EPC Group has implemented Power BI RLS for Fortune 500 healthcare, financial services, government, manufacturing, and technology since the Power BI GA wave (2015).

TL;DR — RLS Architecture Decision Matrix

Pattern	Use Case
Static RLS	Hard-coded role membership, low scale
Dynamic RLS via USERPRINCIPALNAME()	Identity-driven authorization (most common)
Dynamic RLS via USEROBJECTID()	Microsoft Entra Object ID anchored
Path-based RLS (Org Hierarchy)	Manager sees own + all reports
Group-based RLS (Microsoft Entra)	Authorization tied to Microsoft Entra group
Multi-tenant RLS	SaaS scenarios with one model serving many customers

Combine with Object-Level Security (OLS) when columns must be hidden, and sensitivity labels for Microsoft Copilot grounding control.

Pattern 1: Static RLS

-- Role: "Northwest Region"
-- Filter on Sales table
[region] = "Northwest"

Use case: Small number of static authorization scopes that never change.

Limitation: Hard to maintain, doesn't scale beyond ~10 roles.

Pattern 2: Dynamic RLS via USERPRINCIPALNAME()

-- Role: "Sales Rep"
-- Filter on Sales table
[sales_rep_email] = USERPRINCIPALNAME()

Use case: Each user sees their own data. Most common pattern.

-- Role: "Department Lead"
-- Filter on Sales table via department mapping
[department_id] IN
    LOOKUPVALUE(
        Departments[department_id],
        Departments[lead_email], USERPRINCIPALNAME()
    )

Use case: Manager sees their department(s).

Pattern 3: Dynamic RLS via USEROBJECTID()

-- Role: "Project Member"
-- Filter on Project table via Microsoft Entra Object ID
[project_id] IN
    SELECTCOLUMNS(
        FILTER(
            ProjectMembership,
            ProjectMembership[user_oid] = USEROBJECTID()
        ),
        "project_id", ProjectMembership[project_id]
    )

Use case: Anchored on Microsoft Entra ID Object ID rather than UPN. More resilient to email/UPN changes during organizational moves.

Pattern 4: Path-Based RLS (Organizational Hierarchy)

-- Role: "Manager Hierarchy"
-- See own data + all subordinates
PATHCONTAINS(Employees[manager_path], LOOKUPVALUE(
    Employees[employee_id],
    Employees[email], USERPRINCIPALNAME()
))

Use case: Hierarchical authorization where manager sees own + entire reporting chain.

Implementation: Pre-compute org hierarchy manager_path column using PATH() function during ETL, then PATHCONTAINS() at query time.

Pattern 5: Group-Based RLS (Microsoft Entra Groups)

Best practice for enterprise scale — authorization tied to Microsoft Entra group membership rather than per-user mappings.

-- Role: "Region Group Member"
[region_id] IN
    LOOKUPVALUE(
        RegionGroupMapping[region_id],
        RegionGroupMapping[entra_group_oid], <user's group OIDs>
    )

Pattern: Power BI semantic model has a RegionGroupMapping table that maps Microsoft Entra group OIDs to data scopes. Application code (or refresh-time prep) snapshots user-to-group mapping.

Advantage: Authorization changes via Microsoft Entra group membership flow automatically. No per-user model update.

Pattern 6: Multi-Tenant RLS (SaaS Scenarios)

For software vendors embedding Power BI for multi-customer SaaS:

-- Role: "Tenant Filter"
[customer_id] = USERPRINCIPALNAME()  -- typically configured via JWT claim

Multi-tenant pattern requires:

• Single semantic model serves all tenants
• Customer ID is filterable column on every fact table
• Embed token provided via service principal with effective_identity claim
• Power BI Premium or PPU capacity

Combining RLS with Object-Level Security (OLS)

OLS hides specific columns or tables from specific users. Useful when:

• Column-level visibility differs by role (e.g., Salary visible to HR only)
• Table is sensitive but other tables in the model are general-access
• Compliance requires column masking

-- Role: "Standard User" — OLS rule
-- Hides Salary column
TABULAR EDITOR: select Salary column → Object Level Security → Standard User → None

OLS is configured via Tabular Editor or XMLA endpoint, not Power BI Desktop UI.

Combining RLS with Sensitivity Labels

Microsoft Purview sensitivity labels on Power BI:

• Apply at semantic model level
• Enforce encryption and access policies
• Block Microsoft Copilot grounding for Restricted-tier
• Enforce DLP policies on report export

RLS + sensitivity label = layered authorization (RLS limits rows, label enforces encryption + Copilot grounding control).

Performance Tuning

RLS Performance Considerations

RLS adds query overhead. Common patterns and impact:

Pattern	Query Overhead
Static RLS	Negligible
Dynamic via USERPRINCIPALNAME() with LOOKUPVALUE	Low
Dynamic via USEROBJECTID() with SELECTCOLUMNS/FILTER	Low-Medium
Path-based with PATHCONTAINS	Medium
Group-based with multi-table join	Medium-High
Multi-tenant with effective_identity	Low (Power BI optimizes)

Optimization Patterns

• Pre-compute mapping tables during ETL rather than computing at query time
• Index mapping table columns in DirectQuery scenarios
• Aggregations for common queries (Power BI Premium feature)
• Composite models to mix Import and DirectQuery
• Reduce table cardinality in mapping tables
• Test with Performance Analyzer in Power BI Desktop before production

DirectQuery Considerations

DirectQuery RLS pushes filters down to the underlying source. Critical:

• Source must respect RLS (SQL Server, Microsoft Fabric Warehouse, Azure SQL handle this natively)
• Indexes on RLS predicate columns
• Source query plan optimization for parameterized predicates

DirectLake Considerations (Microsoft Fabric)

DirectLake mode in Microsoft Fabric reads Parquet/Delta from OneLake without import. RLS works natively. Performance is typically 60-80% faster than Import for typical workloads.

Microsoft Fabric Integration

OneLake Security

Microsoft Fabric OneLake supports:

• Workspace-level role-based access control
• Lakehouse / Warehouse-level access control
• Row-level security at warehouse level (T-SQL CREATE SECURITY POLICY)
• Column-level security at warehouse level
• Sensitivity label enforcement

Power BI semantic models on Microsoft Fabric inherit Fabric warehouse RLS, which can complement (or in some cases replace) Power BI RLS.

Microsoft Copilot for Power BI

Power BI Copilot respects:

• RLS (Copilot answers limited to user's row scope)
• OLS (Copilot can't reference hidden columns)
• Sensitivity labels (Copilot blocks Restricted-tier grounding)

This is a critical differentiator — Power BI Copilot is the only major BI Copilot that natively respects RLS/OLS without custom configuration.

Frequently Asked Questions

Should we use RLS or build separate reports per role?

RLS, almost always. Separate reports per role create maintenance burden and inconsistency. RLS scales to thousands of users with one report. The exception is when authorization is so different per role that data semantics differ (in which case, consider separate semantic models).

Static or dynamic RLS?

Dynamic, almost always. Static doesn't scale and requires manual updates per personnel change. Dynamic via USERPRINCIPALNAME() or USEROBJECTID() with mapping tables is the EPC Group standard.

How do we handle external users (B2B guests)?

Microsoft Entra B2B guest users can authenticate to Power BI. RLS works for B2B guests via USERPRINCIPALNAME() — but the UPN format differs (guest_user_email#EXT#@hosttenant.onmicrosoft.com). Mapping tables must accommodate this.

How does RLS work with embedded Power BI?

Embedded Power BI (Power BI Embedded for ISVs, embedded for organization) uses the embed token to assert user identity. App owns data scenario uses effective_identity to assert RLS roles per user. User owns data scenario uses the user's actual identity.

Can RLS be bypassed?

Power BI workspace owners and Premium capacity admins can bypass RLS via Tabular Editor or by editing the model. Mitigation: Microsoft Purview audit log captures admin actions, role-based admin separation, and PIM (Privileged Identity Management) for elevation.

How do we test RLS?

• Power BI Desktop "View as" → select role → run report
• Power BI Service "Test as another user" → enter UPN → run report
• Automated testing via Power BI REST API + service principal

Who delivers Power BI RLS engagements?

EPC Group senior architects with Power BI experience since the Project Crescent beta (2010-2013). Errin O'Connor was on the original Microsoft Power BI beta team and is a 4-time Microsoft Press author including a Power BI book.

Next Steps

Schedule a 30-minute Power BI RLS discovery call at /schedule or call (888) 381-9725. Senior architects (not sales) take discovery calls.

Related reading: Power BI Premium Pricing Licensing Guide, Healthcare Analytics Power BI HIPAA Enterprise Guide, Government Analytics Power BI FedRAMP Enterprise Guide, and Microsoft Fabric Quickstart Assessment.