Power BI Row-Level Security: How to Design, Implement and Govern RLS in 2026

Key Takeaways

• RLS applies DAX filters to a semantic model, so each user sees only the rows their role allows.
• It binds workspace Viewers only, while Admins, Members and Contributors bypass it, even inside the same report.
• Dynamic RLS with USERPRINCIPALNAME and a mapping table scales to thousands of users, because one role serves everyone.
• Roles are additive, so a user in two roles sees the union of both filters.
• RLS secures rows; pair it with object-level security when whole columns or tables are sensitive.
• Govern the mapping table like financial data: a named owner, change control and quarterly recertification.

When a Regional Report Shows Another Region’s Revenue

Picture the Monday sales review. When the East regional manager opens the quarterly revenue report, she sees East numbers only, exactly as designed. Down the hall, though, a new analyst opens the same report and sees every region, including the West pipeline that leadership had not yet shared.

Nothing in the DAX was wrong. The analyst had been added to the workspace as a Member to fix a broken visual, but Members are not filtered by row-level security. The report looked secure because it worked for the people it was tested with.

That gap between “RLS is on” and “the right people see the right rows” is what this guide closes. It covers what RLS does, how to choose a design, and how to build, test and govern roles across an enterprise.

Updated November 2026 to reflect current Microsoft Learn guidance on Direct Lake, B2B guest users and Microsoft Entra ID naming.

What Is Power BI Row Level Security?

Power BI row level security is a filter that decides which rows of a semantic model each user can read. You define it once in the model, and it applies to every report, dashboard and app built on that model. The user never sees a filter pane for it, so they cannot switch it off.

The design has three parts. A role is a named container, such as a Regional Sales role. A rule is a DAX expression on a table that returns true or false for each row, so only rows that return true stay visible. Members are the users or groups assigned to the role in the Power BI service, which in practice means Microsoft Entra ID security groups.

For example, a role called “East Sales” carries the rule [Region] = "East" on the Region table. When an East sales rep opens the revenue report, every visual, total and drill-through is calculated over East rows only. The fact table is filtered too, because the Region filter flows through the model’s relationships.

According to Microsoft’s row-level security documentation, RLS works on Import and DirectQuery models. Live connections to Analysis Services work differently, since security is defined in the source model, not in Power BI.

What RLS Protects and What It Leaves Open

RLS is precise about rows but silent about almost everything else. Knowing its limits up front saves a painful audit finding later.

• It protects: rows in the semantic model, for users in the Viewer workspace role or users who receive the content through an app or a share.
• Columns and tables stay visible. Hiding them is the job of object-level security (OLS).
• Opening a workspace or report is a separate check. Workspace roles and item permissions decide that.
• Admins, Members and Contributors are never filtered. They see all rows by design, because they can edit the model.
• Service principals fall outside it. A service principal cannot be an RLS member, so RLS is not applied when it is the final effective identity.

In other words, RLS is one layer in a stack. The next section shows where it sits in that stack and which layer answers which question.

Where RLS Sits in the Power BI and Fabric Security Model

Think of Power BI security as a set of doors, each answering a different question. Workspace roles decide who gets into the building. Item permissions then decide which rooms they can enter, while RLS decides which papers on the desk they can read.

The confusion starts when teams expect one layer to do another layer’s job. A team might lock rows with RLS, then give a contractor the Contributor role so they can publish fixes. That contractor now sees everything, because the workspace role sits above the row filter.

Reading the Layers in Order

When you read the table from top to bottom, the order of checks becomes clear. A user who fails the workspace check never reaches the row filter, while a user who holds an editing role skips it entirely. Microsoft’s Fabric permission model describes the same layering for every Fabric item.

Column protection, however, works differently. Object-level security secures specific tables or columns from report viewers, so a salary column can disappear for most users while rows stay filtered by region. Many enterprise models need both. Both live in model roles, but keep each user’s RLS and OLS in the same role, because combining them across different roles raises an error at query time.

The Viewer-Only Rule: Why Admins, Members and Contributors See Everything

This single rule causes more data exposure than any DAX mistake. Microsoft states it plainly: RLS roles apply to members assigned the Viewer role in the workspace. Admins, Members and Contributors are not filtered, because they can edit the model and could remove the rule anyway.

The rule also cuts the other way. A Viewer who holds Build permission on the semantic model is still filtered, and that includes queries from Analyze in Excel. So you can let business analysts build their own reports on a secured model without handing them every row.

The practical fix is structural. Keep report consumers in the Viewer role or give them access through an app. Then keep editing roles for the small team that maintains the model. When someone needs to “just fix one visual,” give them a development workspace instead of a Member seat in production.

Static, Dynamic and Source-Level RLS: The Options Compared

There are four ways to filter rows for Power BI users, and the real difference is who maintains the access list. Static RLS keeps it inside role definitions, so every change touches the model. Dynamic RLS moves it into a table, CUSTOMDATA hands it to the embedding application, and source-level RLS leaves it in the database.

A short example shows the difference. Say a company has five regions. Static RLS then needs five roles, one per region, each with a fixed value. Dynamic RLS instead needs one role and a mapping table that pairs each user’s email with a region. When the company opens a sixth region, static RLS needs a model change, while dynamic RLS needs one new row.

When the Database Should Hold the Rules

SQL Server and Azure SQL have supported row-level security since SQL Server 2016, using CREATE SECURITY POLICY with inline table-valued predicate functions. When those policies already exist, a DirectQuery model with single sign-on can pass the user’s identity through and let the database filter. For the Fabric side of that pattern, see our guide to warehouse-level security with T-SQL.

For a semantic model that serves many reports, though, dynamic RLS is usually the cleaner home. It keeps access logic next to the business model, so it travels with the model through deployment. It also works the same way in Import, DirectQuery and Direct Lake.

Decision Framework: Choosing a Power BI Row Level Security Design

The shape of your access rules decides the right RLS design, while company size matters far less. For example, a firm with 10,000 users and five fixed regions can live happily with static roles. A 300-person distributor with territories that change monthly needs dynamic RLS from day one.

Start by writing down who should see what in plain English, then match each sentence to a row below. Most enterprises then settle on dynamic RLS as the base, plus one or two special cases layered on top.

Breaking a Tie Between Two Designs

When two rows seem to apply, choose the one with the simpler upkeep. A rule that the business can maintain through data changes will stay correct longer than one that needs a developer for every update. The decision tree below also shows the same logic as a set of yes-or-no questions.

Worked Example: Regional Sales Access for 400 Users

Consider a sales organization with 400 report users across four regions: East, West, Central and South. Most reps cover one region, while a few cover two, and regional directors see their own region plus a national summary built elsewhere. Even so, the team wants one semantic model and one role.

The design is a mapping table called UserRegion, with one row per user per region. A user who covers two regions simply gets two rows. A user with no row, on the other hand, sees nothing, which is the safe default.

The Regional Sales role carries two rules. First, it filters the Region dimension to the regions listed for the signed-in user. Then a second rule hides other people’s rows in the mapping table itself, so nobody can browse who has access to what.

-- Role: Regional Sales
-- Rule 1, on the Region dimension table
Region[Region]
    IN CALCULATETABLE (
        VALUES ( UserRegion[Region] ),
        UserRegion[UserEmail] = USERPRINCIPALNAME ()
    )

-- Rule 2, on the UserRegion mapping table
UserRegion[UserEmail] = USERPRINCIPALNAME ()

Here is what each user sees once the role is assigned to the sales security group:

Two rows in that table matter most, because they mark the edges of the design. Mia, who has no mapping row, sees an empty report instead of everything, so a missing entry fails safe. The workspace Member, by contrast, sees all regions, so editing roles must stay with the model team.

Licensing and Effort Drivers

Licensing follows who views the content rather than how RLS is designed. As of November 2026, Microsoft lists Power BI Pro at $14.00 and Premium Per User at $24.00 per user per month, paid yearly. Under the Fabric licensing rules, free-license users can view content when the workspace sits on F64 or larger capacity, or a P capacity. In app-owns-data embedding, end users need no Power BI license at all.

For a deeper look at those trade-offs, our comparison of Power BI Premium vs Pro walks through the numbers. Capacity planning also has its own guide on Microsoft Fabric capacity.

Effort is harder to predict than licensing, so we avoid quoting hours without seeing the model. Instead, these five drivers decide whether an RLS project is a week of work or a quarter:

How to Set Up Static RLS in Power BI Desktop

Static RLS is the right place to learn the mechanics, even if you end up with a dynamic design. The steps below build one role per region and then publish it to the service.

1. Open Manage roles. In Power BI Desktop, go to the Modeling tab and select Manage roles.
2. Create a role. Name it after the audience, such as “East Sales,” so the role list reads like an access policy.
3. Add a filter. Select the Region table and enter a DAX rule such as [Region] = "East". Then switch to the DAX editor when a rule goes beyond simple equality.
4. Validate in Desktop. Use View as on the Modeling tab, pick the role, and confirm every page shows East data only.
5. Publish. Publish the report to a workspace, and the role definitions travel with the semantic model since they are part of it.
6. Add members. In the service, open the semantic model’s Security page and add Microsoft Entra ID security groups to each role. Microsoft recommends security groups over individual users, since membership is then managed in Entra ID.
7. Test as role. On the same Security page, use Test as role to check the published result before you share the report.

A note on naming: Azure Active Directory is now Microsoft Entra ID, and older guides use the old name for the same groups. Role members can be security groups, distribution groups or mail-enabled groups, but you cannot add groups created inside Power BI.

Object-Level Security Setup

Object-level security is configured in the same model roles, so it fits naturally after your first static role. Microsoft documents two routes, TMDL view inside the authoring tool or the external Tabular Editor, and the TMDL route needs no extra software.

1. Open TMDL view. Start a new script tab in your authoring environment.
2. Write a createOrReplace script. Define the role and set metadataPermission: none on the table or column to hide. Use read to keep an object visible.
3. Preview, then apply. Preview shows the model changes before Apply writes the role definition.
4. Publish and assign members. Publish the model, open its Security page in the service and add groups to the role.

createOrReplace

    role CategoriesOLS
        modelPermission: read

        tablePermission Customers
            columnPermission Address
                metadataPermission: none

For a Viewer in that role, the Address column simply does not exist, as if it had never been modeled. Two caveats from Microsoft apply here as well. OLS binds Viewers only, like RLS, and models with OLS do not support Quick insights, smart narrative visuals or the Excel Data Types gallery.

Static roles become hard to maintain once the list of regions or users starts to move. That is the point where most teams switch to the dynamic pattern in the next section.

How to Implement Dynamic RLS with USERPRINCIPALNAME

Dynamic RLS replaces many roles with one rule that asks a simple question: who is signed in, and what are they allowed to see? The USERPRINCIPALNAME function returns the signed-in user’s UPN, usually their work email, and a mapping table turns that identity into a set of rows.

The steps below follow the worked example above, so they assume an Import or Direct Lake model with a star schema.

1. Build the mapping table. Create a UserRegion table with UserEmail and Region columns, one row per user per region. Source it from a governed system rather than a spreadsheet on someone’s desktop.
2. Load it into the model. Keep it as a separate table, then hide it from report view.
3. Filter the dimension table. Add the rule on the Region dimension using USERPRINCIPALNAME, as shown in the code above. The filter then flows to sales facts through the active relationship.
4. Protect the mapping table. Add a second rule on UserRegion so each user sees only their own rows.
5. Keep relationships single-direction. RLS uses single-direction filtering by default, even if a relationship is set to both directions. Turn on “Apply security filter in both directions” only when a design truly needs it.
6. Publish and assign a group. Add one Entra security group, such as “Sales Report Users,” as the role’s member.

Why the Rule Fails Closed

The rule is also written to fail closed. If a user’s email is missing from UserRegion, the inner table is empty, so no region passes and the report shows nothing. Microsoft’s RLS guidance makes the same point about static values. Each rule should test for every expected value, so a typo returns no rows instead of all rows.

A fail-open rule, though, is easy to write by accident. A condition such as “everyone except Worker sees all rows” means a misspelled value like “Wrker” exposes the whole table. Write the positive case, never the exception.

Manager Hierarchies with PATH Functions

Managers often need to see their own team and every level below it, so the rule must follow the reporting chain. Building a role for each manager does not scale, but DAX parent-child functions handle the chain neatly. Store each employee’s ID and manager ID in an Employee table, then build the path as a calculated column.

-- Calculated column on Employee
Path = PATH ( Employee[EmployeeID], Employee[ManagerID] )

-- RLS rule on Employee
VAR CurrentUserID =
    MAXX (
        FILTER ( ALL ( Employee ), Employee[Email] = USERPRINCIPALNAME () ),
        Employee[EmployeeID]
    )
RETURN
    NOT ISBLANK ( CurrentUserID )
        && PATHCONTAINS ( Employee[Path], CurrentUserID )

The rule keeps every employee whose path contains the signed-in manager’s ID, which means the manager and everyone beneath them. The ISBLANK check keeps the rule fail-closed for anyone missing from the Employee table. When the company reorganizes, the HR feed updates the ManagerID column and access follows on the next refresh.

Users With More Than One Entitlement

Roles in Power BI are additive, so combining roles only ever widens access. A user who belongs to two roles sees the union of both filters, never the intersection. So a rep in “East Sales” and “Partner Channel” sees East rows plus every partner row, which is rarely what the business intended.

Microsoft’s guidance is to design one role that grants everything a user needs. Model a multi-region user as several rows in the mapping table, as Raj has in the worked example, rather than as membership in several roles. The access list then lives in one place, and an auditor can read it as data.

For a tool-level view of the same ideas, Tabular Editor also publishes a guide to row-level security in Power BI semantic models.

RLS in Fabric, Direct Lake and Embedded Scenarios

RLS behaves the same on paper across Power BI and Microsoft Fabric, but each platform pattern adds one twist worth knowing before go-live. Direct Lake can change where queries run, embedding changes who the user is, and guest accounts change what the user’s name looks like. Each one can quietly break a rule that passed every test in Desktop.

Direct Lake and DirectQuery Fallback

Direct Lake semantic models read Delta tables in OneLake directly, and they also support RLS with the same roles and DAX as any other model. The twist, however, is fallback. When a DAX query uses a feature Direct Lake cannot serve, the query falls back to DirectQuery (Direct Lake on SQL only; Direct Lake on OneLake does not fall back). RLS filters still apply, but performance characteristics may change.

Where the row security lives matters. If you define RLS on the SQL analytics endpoint, a Direct Lake on SQL model falls back to DirectQuery to honor it. A Direct Lake on OneLake model does not apply that SQL-based RLS at all, according to the Direct Lake overview. So pick one home for row security per model, and prefer semantic-model RLS, which both Direct Lake modes enforce.

Fallback shows up in the Fabric capacity metrics app, so watch for it there after release. Teams that already track platform health with Azure monitoring tools can add capacity alerts to the same routine. Our guide to Direct Lake semantic models in Power BI covers fallback triggers in more depth.

Power BI Embedded and Service Principals

Embedded analytics changes who the “user” is. In app-owns-data embedding, your application signs in to Power BI with a service principal and generates an embed token for each end user. That token carries an effective identity: a user name, the roles to apply, and optionally a CUSTOMDATA value.

Service principals cannot be RLS members, and RLS is not applied when a service principal is the final effective identity. So the app must always pass an effective identity for a model with RLS. Microsoft’s embedded RLS documentation describes three patterns for software vendors:

• Small to mid-sized vendors: one semantic model and report for all customers, with dynamic RLS filtering each customer’s rows.
• Vendors with a few large customers: a mix of static and dynamic RLS, possibly with OLS for sensitive columns.
• Large vendors with thousands of customers: workspace isolation with service principal profiles, giving each customer its own model, then RLS inside each tenant.

Because the application can pass any value as the effective identity, test unexpected values as carefully as expected ones. Our overview of Power BI Embedded explains the embedding models themselves.

External B2B Guest Users

Sharing a secured report with a partner adds an identity wrinkle. Guests can be RLS members, but Microsoft warns that security groups containing B2B guests may not resolve correctly for RLS. So the recommended workaround is to add guest users directly to the role by email address.

Dynamic rules also need care. For a guest, USERPRINCIPALNAME may return an email-style value or a UPN in the #EXT# format, depending on tenant settings. When the mapping table stores a different format, the guest sees no data. Test with a real guest account, because Test as role uses your own identity and will not reveal the mismatch.

Testing RLS Before and After Release

Testing RLS means proving two things: each person sees their rows, and nobody sees anyone else’s. Teams often test the first but forget the second, which is how leaks reach production.

Power BI gives you two built-in tools. View as in Desktop checks roles during development, and Test as role in the service checks the published model. Both have limits: Test as role does not work for DirectQuery models with single sign-on, and it cannot validate Q&A visuals, Quick insights or Copilot. So the final check always uses real identities.

Run the matrix twice: once before the first release, and again whenever the model, the mapping logic or the workspace roles change. Store the results with the release record so an auditor can see what was tested and when.

Negative tests carry the most weight. A report that shows the right East numbers proves very little if a user with no mapping row also sees East. The no-row persona is the cheapest test you can run and the one that catches the worst failure.

Performance: Why RLS Slows Reports and How to Fix It

RLS adds work to every query, because the engine applies the role’s filters before it computes any visual. On a well-shaped model that cost is small, but on a model with heavy rules on large fact tables, users will notice.

The fixes are mostly about where the filter lands. A rule on a small dimension table filters a few hundred rows and then lets relationships do the rest. A rule on a fact table, or one that walks lookups row by row, repeats that work across millions of rows. Good dimensional design helps here, because a clean star schema gives RLS small tables to filter.

• Put RLS rules on dimension tables rather than fact tables.
• Rely on active relationships, because RLS filters only propagate through them.
• Avoid LOOKUPVALUE in rules when a model relationship can do the job.
• Turn on the bi-directional security filter only when the design needs it.
• Make sure aggregation tables are filtered consistently with the detail tables they summarize.
• Avoid USERELATIONSHIP in measures on RLS models, since Microsoft notes it may cause errors.
• Measure query times with RLS on before release, not after users complain.

If a report is fast for an admin and slow for a Viewer, RLS is the likely cause, because the admin’s queries skip the filter. Compare the two with Performance Analyzer in Desktop, using View as for the Viewer’s role.

Common RLS Mistakes That Leak or Block Data

RLS failures come in two kinds: leaks, where someone sees too much, and blocks, where someone sees nothing. Leaks are worse, but blocks erode trust in the report just as fast. The table below lists the mistakes we see most often and how to fix each one.

Nearly every row in that table is a process failure rather than a DAX failure. That is why the last step of an RLS design is governance, which the next section covers.

Governing RLS Across an Enterprise

An RLS model is only as accurate as its access list, but access lists decay. People join, move and leave every week, so the mapping table needs the same care as any other business-critical data set.

Start with ownership. Every mapping table needs a business owner who decides whether each person should see the data. Usually that is one of the data stewards who own the mapping table for that domain. The BI team owns the rules and the model, while the steward owns the entries as part of wider data governance.

Next, automate the feed. A mapping table that someone edits by hand drifts quickly, because manual edits lag behind joiners, movers and leavers. Load it from Microsoft Entra ID groups or the HR system through a scheduled pipeline. Then apply the same data engineering best practices you use for any governed table: validation, history and alerts on failed loads.

Release Control, Recertification and Audit Evidence

Third, put changes under control. Promote model changes through Power BI deployment pipelines so rules are tested in development before they reach production. Also run the persona test matrix as part of each promotion, and keep editing roles in production to a short, named list.

Fourth, recertify on a schedule. Once a quarter, send each owner the list of who can see their data and ask them to confirm or remove entries. That review catches the leavers and movers that automated feeds miss, and it also gives auditors a signed record.

Finally, keep evidence. Fabric and Power BI activity can be searched in the Microsoft Purview portal audit log, which requires the Audit Logs role. Combined with the release record and recertification sign-offs, that log answers the auditor’s real question: who could see this data, and who approved it? Our Microsoft Purview guide covers the wider governance platform behind that audit log.

Governance also extends to AI features. Copilot in Power BI works over the same semantic models, so the access rules you govern here also shape what its answers can reveal. Our guide to Power BI Copilot covers how to prepare models for that use.

How Kanerika Delivers RLS at Enterprise Scale

Kanerika treats RLS as an access program with a technical core rather than a modeling task. We are a Microsoft Solutions Partner for Data and AI and a Microsoft Fabric Featured Partner. We build RLS in five stages, and each stage hands over a named artifact. That way security, performance and audit needs are settled before the first report ships.

1. Access contract. The business owner signs a plain-English statement of who sees which rows and columns. It becomes the reference every later test is checked against.
2. Entitlement model. We design the mapping table, name its owner (usually the domain’s data steward) and feed it from Microsoft Entra ID groups or the HR system on a schedule.
3. Fail-closed build. Dynamic roles return nothing for unknown users, and OLS hides sensitive columns. The output is a role catalog that maps each role back to a line of the contract.
4. Persona test matrix. One row per persona (Viewer, guest, embedded identity, leaver), each with the rows it must see and the rows it must not. Negative tests count as much as positive ones.
5. Release and recertification pack. Changes move through deployment pipelines, owners recertify the mapping table every quarter, and audit-log exports sit with the sign-offs.

Our Power BI practice is led by Amit Chandak, Kanerika’s Chief Analytics Officer and a Microsoft MVP for Power BI. Teams that want help with the build can explore our Power BI consulting and implementation services. Our data governance services also cover the ownership and recertification side. We also work across Microsoft Fabric and Microsoft Purview when RLS spans the wider platform.

Case in Point: Allen Distribution

Allen Distribution shows the pattern in practice. The US logistics and supply chain company, headquartered in Pennsylvania, had warehouse management (WMS) and HR data spread across on-premises SQL servers. Kanerika centralized that data on Microsoft Fabric with Power BI reporting, and implemented row-level security so data access is role-based.

That mix is what made the access contract matter. Warehouse figures and HR records now sat in one platform, yet the teams reading them had very different needs. Scoping access by role, as the case study records, let operations, inventory and HR plan from shared data while keeping privacy and compliance intact. In our method, a contract like that becomes the persona test matrix: each team’s role is checked against the rows it should see and the HR rows it should not.

The project as a whole improved operational efficiency by 60% and data accuracy by 54%. It also lifted decision-making precision by 42% and grew data-driven decisions by 61%. Those are outcomes of the full platform work rather than of RLS alone. Role-based RLS is what let one shared platform serve operations, inventory and HR, with access scoped by role for privacy and compliance.

If you are weighing outside help, our guide to choosing a Power BI consulting company is a useful checklist. For broader context, see our Power BI overview, our comparison of Microsoft Fabric vs Power BI, and the wider data security practices that RLS supports.

So how should you design, implement and govern Power BI row level security? Design it around a governed mapping table, and implement it with fail-closed dynamic rules tested on real identities. Then govern it with named owners, controlled releases and quarterly recertification.

Frequently Asked Questions