Dynamic RLS + Slicer Role Switching Issue

[PrasadIngare]

Business Requirement

We need to implement dynamic row-level security in Power BI where the logged-in user can switch between different allowed roles using a slicer on the report page:

• SuperUser → should see all data

• CompanyHR → should see only companies assigned to them

• Self (default) → see only their own record

A user may hold multiple roles (e.g., SuperUser + CompanyHR), and the slicer should determine which role is active for the current view.

The actual underlying row-level access permissions come from a RoleMapping table stored in the data model.

This design was chosen because different roles need different views within the same report, and we cannot publish multiple copies of the report.

Data Model Architecture

We are using a star-schema model:

IhubData (Employee dimension table)
├── UserLoaInfo (Fact)
├── UserPersonalInfo (Fact)
└── TimeKey (Fact)

RoleMapping is a separate security table containing:

• Email

• Role (SuperUser, CompanyHR)

• Company_Code

• Employee_ID

There is no “Self” role stored; “Self” is simply the logged-in user's own row.

Relationships:

• IhubData → Fact tables (1-to-many)

• No relationship between RoleMapping and fact tables
  
  

RLS Requirement

We defined RLS on IhubData using logic:

• If role = SuperUser → full access

• If role = CompanyHR → IhubData rows where Company Code ∈ allowed companies

• If role = Self → IhubData row where WorkEmail = USERPRINCIPALNAME()

Role selection is expected to come from a disconnected RoleSelector slicer, so users can switch roles at runtime.

What We Have Concluded So Far

After extensive debugging, it appears that:
Slicer selections are not available to the RLS engine

Slicers operate in visual filter context,
while RLS is evaluated earlier at model security context,before any slicer filters exist.

Therefore:

• RLS logic cannot switch based on slicer choices

• User cannot dynamically change their RLS role via slicer

This prevents implementing a dynamic role-switcher using slicers, even though all underlying RoleMapping logic is valid.

What We Need Clarification From Microsoft

1. Is it expected behavior that slicer selections do NOT reach RLS evaluation context?

2. Is there any supported method to allow a user to switch between multiple allowed RLS roles at runtime?

(e.g., SuperUser vs. CompanyHR)

3. If this is a product limitation, what workaround does Microsoft recommend for providing role-switching capabilities inside a single report?

We want to confirm whether:

• This is expected behavior

• A limitation

• A bug

• Or if there is a supported pattern to achieve our requirement

Related Info:

Slicer Table (Disconnnected)

RoleMapping Table

Final RLS Code (Applied on IhubData)

VAR LoggedUser =
    TRIM( UPPER( USERPRINCIPALNAME() ) )

VAR SelectedRole =
    SELECTEDVALUE( RoleSelector[SlicerRole], "CompanyHR" )

VAR AllowedCompanies =
    SELECTCOLUMNS(
        CALCULATETABLE(
            VALUES( RoleMapping[Company_Code] ),
            TRIM( UPPER( RoleMapping[Email] ) ) = LoggedUser &&
            RoleMapping[Role] = "CompanyHR"
        ),
        "C", TRIM( UPPER( [Company_Code] ) )
    )

VAR RowCompany =
    TRIM( UPPER( FORMAT( IhubData[Company Code], "" ) ) )

VAR RowEmail =
    TRIM( UPPER( IhubData[Work EmailAddress] ) )

RETURN
SWITCH(
    TRUE(),
    SelectedRole = "SuperUser", TRUE(),
    SelectedRole = "CompanyHR", RowCompany IN AllowedCompanies,
    RowEmail = LoggedUser
)

Expected Behavior

• When “SuperUser” is selected → all rows visible (If the user is SuperUser in RoleMapping Table)

• When “CompanyHR” is selected → rows filtered by RoleMapping  (If the user is CompanyHR in RoleMapping Table)

• When nothing selected → default to CompanyHR

Summary

We want users to be able to:

1. Have multiple roles assigned (e.g., SuperUser + CompanyHR)

2. Switch between those roles using a slicer

3. Apply RLS based on the active slicer role

But slicer-based role switching does not work because RLS does not detect the slicer selection.

*** We need Microsoft’s guidance on whether this approach is supported or not, and if not, the recommended method to implement multi-role switching in a single Power BI report.

[v-hashadapu]

Hi @PrasadIngare , Hope you are doing good. I hope the implementation went well and the issue is sorted. Can you please share the insights here, as they will help others.

Thank you.

[v-hashadapu]

HI @PrasadIngare , Hope you're doing okay! May we know if it worked for you, or are you still experiencing difficulties? Let us know — your feedback can really help others in the same situation.

[PrasadIngare]

Hi @v-hashadapu ,
thanks for reaching out.

We haven’t started implementing the suggested approach yet. It will take some time on our end to implement and test it thoroughly.

We’ll share an update as soon as it’s completed.

Thanks for checking in!

[v-hashadapu]

Hi @PrasadIngare , Thanks for sharing the information. Hope it gets success. When it does though, please share the insights here, they will help other users.

[v-hashadapu]

Hi @PrasadIngare , hope you are doing great. May we know if your issue is solved or if you are still experiencing difficulties. Please share the details as it will help the community, especially others with similar issues.

[SavioFerraz]

Hi @PrasadIngare,

You’ve already done excellent analysis, and your conclusions are correct. Let me confirm and clarify this from a Power BI engine perspective, and then outline the supported patterns.

✅ Short answer

Yes, this is expected behavior

No, slicers cannot influence RLS

This is a product limitation, not a bug

There is no supported way to switch RLS roles at runtime using a slicer

1⃣ Why slicers do NOT work with RLS (by design)

Row-Level Security is evaluated:

At model load / query security time

Before any visual filters, slicers, or interactions exist

Slicers:

Operate only in the visual filter context

Are evaluated after RLS has already restricted the dataset

Because of this:

SELECTEDVALUE(RoleSelector[Role]) will always return blank or default inside RLS

RLS cannot “see” slicer selections

RLS logic cannot change dynamically during report interaction

This behavior is documented and intentional.

👉 So your conclusion is correct:

Slicer selections are not available to the RLS engine.

2⃣ Is slicer-based role switching supported?

No.
Power BI does not support runtime role switching inside a single RLS role.

Important constraints:

RLS roles are static

They are evaluated once per user session

Users cannot dynamically elevate or reduce access using report interactions

This is fundamentally a security boundary, not a UX feature.

3⃣ Why this is not considered a bug

Allowing slicers to influence RLS would mean:

Users could potentially bypass security

Security context would change mid-session

Cached query plans would become invalid

For these reasons, Microsoft intentionally keeps:

RLS isolated from report interactions

Slicers out of the security context

So this is a known and enforced design limitation.

4⃣ Supported patterns to achieve similar outcomes
✅ Pattern 1 – One RLS role per user (recommended)

Use dynamic RLS only based on USERPRINCIPALNAME() and RoleMapping:

SuperUsers → see all rows

CompanyHR → restricted rows

Self → own row

Let the most permissive role win, but do NOT allow switching.

This is the most secure and supported approach.

✅ Pattern 2 – Multiple reports (security-safe)

If role-based views differ significantly:

Publish one report

Create multiple App audiences or links

Each audience maps to a different RLS role

This avoids duplicating datasets but keeps security intact.

⚠ Pattern 3 – Pseudo role switching (NOT RLS)

If the requirement is more about viewing different perspectives, not true security:

Apply RLS only once (minimum access)

Use slicers / measures / bookmarks to:

Hide/show visuals

Change aggregations

Switch layouts

⚠ This does not provide real security — only UX filtering.

5⃣ Important recommendation

If data access truly differs (rows must be hidden or visible):
👉 RLS must be fixed and non-switchable

If users just want:

Different summaries

Different scopes

Different views of allowed data

👉 Use slicers and bookmarks on top of a single RLS context

Conceptual illustration
User Login
|
▼
RLS Evaluation (static, once)
|
▼
Allowed Dataset
|
├── Visual filters
├── Slicers
└── Bookmarks

Slicers never flow upward into RLS.

Final confirmation

✔ This is expected behavior
✔ This is a known limitation
✔ This is not a bug
✔ There is no supported slicer-based RLS switching pattern

Your understanding and diagnosis are spot-on.

If this explanation helps, please consider giving a kudos 👍
And if it answers the question clearly, feel free to mark it as the Accepted Answer ✔

[v-hashadapu]

Hi @PrasadIngare , Thank you for reaching out to the Microsoft Community Forum.

@tharunkumarRTK  is correct about Power BI only supporting role switching by using separate datasets or separate reports, each with its own RLS rule and then exposing them through a workspace app with audience groups. That pattern works because each dataset enforces only one security envelope and users can switch views by opening a different report.

In Power BI Service, RLS is evaluated before the report renders and before any slicer filters exist, which means a disconnected slicer cannot influence which rows RLS allows. A slicer can narrow down what RLS already exposed, but it can never broaden access or switch roles. This isn’t a bug or a modeling problem, it’s simply how the engine is designed and Microsoft does not provide a feature that lets a user dynamically change RLS roles inside one dataset.

Because of that, the role selector concept (SuperUser vs CompanyHR vs Self, chosen from a slicer) cannot be implemented with RLS on a single model. Power BI enforces one security scope per user per dataset. If you need users to truly see different secured slices of data, the only supported choices are either the multi-dataset/report approach @tharunkumarRTK  outlined or an embedding/Analysis Services scenario where the application controls the user’s effective identity.

If you want though, you can submit as a feature request in Microsoft Fabric Ideas , the engineering team actively monitors those for real world pain points. With enough upvotes these ideas may be implemented as features.

Thank you @tharunkumarRTK  for your valuable response.

[PrasadIngare]

Hi @v-hashadapu , @tharunkumarRTK 

Thanks for your detailed clarification and for confirming the current limitations of RLS in Power BI.

I completely understand the reasoning behind why role switching cannot be done dynamically within a single dataset, and I agree that the multi-dataset / multi-report approach is the straightforward way to present different security envelopes to the same user. 

However, while this pattern works technically, it does introduce challenges from a maintenance and scalability perspective.
If the number of roles increases in the future (e.g., from 2 roles today to 4 or more later), maintaining multiple datasets and multiple versions of the same report becomes difficult and not very manageable for ongoing development, testing, deployment, and governance.

Nonetheless, I appreciate the explanation and the confirmation that this is currently a platform limitation rather than a modeling issue. I will go ahead and submit this as a feature request in Microsoft Fabric Ideas, as the ability to support secure, dynamic role switching within a single dataset would be extremely valuable for many real-world scenarios.

Thanks again for your response.

[v-hashadapu]

Hi @PrasadIngare , Thank you for reaching out to the Microsoft Community Forum.

You’re absolutely right, the multi-dataset or multi-report pattern works, but it does become harder to manage as the number of roles grows. Unfortunately, that maintenance overhead is the direct consequence of the current platform limitation. Power BI enforces a single security envelope per dataset, so any scenario that requires users to switch between different secured views will always require either separate datasets or an external identity-driven architecture.

If you outgrow the multi-dataset pattern, the only scalable alternative today is an embedding or semantic-server model (AAS/SSAS or Power BI embedding), where the effective identity can be set before the report loads. That gives you true dynamic role switching without duplicating content, but it does require a different architectural approach.

Also, thanks for the update. Please do share the link here once the feature request is submitted, so, others with similar issues may upvote it, which will make it more likely to be implemented as a feature.

[PrasadIngare]

Hi @v-hashadapu,

Thank you for the clarification regarding the multi-dataset pattern and the suggestion to use Power BI Embedded or a semantic-server approach for true dynamic role switching.

In our case, this is very relevant because we already have our own custom embedding platform built in .NET, where users access all Power BI reports through our internal portal. Since we control the embedding layer, we may be able to use the EffectiveIdentity mechanism you mentioned to dynamically switch the user’s active RLS role (e.g., default to CompanyHR and allow switching to SuperUser only when explicitly selected).

To proceed correctly, could you please help elaborate on the following?

1. What would the end-to-end steps look like for implementing dynamic RLS switching through embedding?

A high-level outline or recommended architecture would be very helpful.

2. How should we structure the EffectiveIdentity and token generation on the .NET side?

If possible, sample code showing how to set a specific RLS role (e.g., “CompanyHR”, “SuperUser”, “Self”) when generating the embed token would greatly help us validate the implementation.

3. Are there official Microsoft docs or examples that demonstrate this pattern?

Specifically:

• Embedding a report where the user can select which RLS role to apply

• Passing the selected role into EffectiveIdentity

• Ensuring Power BI enforces that role during report rendering
  
  

4. Any best practices or limitations we should be aware of when implementing dynamic identity switching using embedding?

Since this approach seems like the cleanest way to achieve our requirement without duplicating datasets, we want to make sure we follow the recommended method.

We appreciate any additional direction or sample material you can provide to help us correctly implement this pattern in our embedded platform.

Thanks again for your guidance so far.

[v-hashadapu]

Hi @PrasadIngare , Thank you for reaching out to the Microsoft Community Forum.

Since you already control the embedding layer in your .NET portal, you’re in the ideal position to implement true dynamic RLS switching. In an embedded setup, the active RLS role is chosen at the moment the embed token is generated, not inside the report. That means your portal can let the user pick a role such as CompanyHR or SuperUser and your backend simply issues a new embed token that includes that role through EffectiveIdentity before the report loads.

At a high level, your UI collects the selected role, your .NET backend validates it and then generates an embed token where the EffectiveIdentity specifies both the user and the chosen RLS role. Power BI renders the report under that role for that session. Switching roles is just regenerating the token with a different role value.

The key best practice is that your backend must decide which roles a given user is allowed to select; Power BI will only enforce what you pass through EffectiveIdentity. Tokens also cannot change roles mid render, so each switch requires a fresh token.

Security in Power BI embedded analytics - Power BI | Microsoft Learn

Using standard cloud based row-level security with embedded content in Power BI embedded analytics -...

Embed Token - Reports GenerateTokenInGroup - REST API (Power BI Power BI REST APIs) | Microsoft Lear...

Power BI embedded analytics overview - Power BI | Microsoft Learn

[tharunkumarRTK]

@PrasadIngare 

One workaround I can suggest—if you are okay with maintaining multiple semantic models and reports—is to create three different reports and datasets, with one RLS rule applied per dataset:

1. Super User

2. Company HR

3. Self

Publish them to a workspace and add users to the appropriate security roles. Include all three datasets and reports in a workspace app. Using the workspace audience feature, you can restrict access to each report for specific audience groups.

• Super Users should be added to all three reports.

• Company HR users should be added to the Company HR and Self reports.

• All remaining users should be added only to the Self report.

This way, Super Users can switch between roles by switching between reports using the app’s navigation panel. Other users can follow the same pattern based on the access assigned to their role.

Connect on LinkedIn

Did I answer your question? Mark my post as a solution!
If I helped you, click on the Thumbs Up to give Kudos. Proud to be a Super User!

[MFelix]

Hi @PrasadIngare ,

The RLS allows you to filter out information at row level, meaning that the information presented at the report is only concerning the rows you have, so in this case when you refer that RLS does not impact slicers, this is not entirely true because the slicer will show the values that are available in RLS.

In this case if you have a user that can see all of the rows, but then you want to change the RLS to show only specific lines, the RLS will be applied depending on the DAX that you implement, in your case you are using a SWITCH that first of all has the SUPERUSER so all rows so the slicer will present all rows.

I believe that what you need here is a mix between your RLS to get the correct filter based on  the RoleMapping table and some Calculations groups that will allow you to have a change of context of your calculations based on the role select.

Basically you would filter your Calculation group based on the RLS that the user would have and then on the slicer selection on the Calculation group you could show only all the values, only specifc companies or only specifc user.

Your information is preety detail to get a working demo on my side can you please share a mockup data or sample of your PBIX file. You can use a onedrive, google drive, we transfer or similar link to upload your files.

If the information is sensitive please share it trough private message.

[MFelix]

Hi @PrasadIngare ,

I have made a mockup with a simple fact table and setup the following way:

• RLS on RoleMapping Table to ge the information about company and users role
• Create a Calculation group of each of the roles:

SuperUser = SELECTEDMEASURE()

CompanyHR = CALCULATE( SELECTEDMEASURE(), Companies[Company] in VALUES(RoleMapping[Company_Code]))

Self = CALCULATE( SELECTEDMEASURE(), 'Fact'[EmployeeID] in VALUES(RoleMapping[Employee_lD]))

This may need some adjustment based on your dimensions and also your measures.

The I added the following measure to filter the role:

Role Filter = 
      IF("Self" in VALUES('Calculation group'[Calculation group column]), 1 , 
 COUNTROWS(FILTER('Calculation group', 'Calculation group'[Calculation group column] in VALUES(RoleMapping[Role]))))

Be aware you also need to add in the Role mapping table the users that are with USER access only but on that part you do not need to add the companies this is just for the filter to work properly.

Also setup the Role Slicer has a single selection and on Self has default value.

[PrasadIngare]

Hi @MFelix ,
Thank you for the detailed response and for sharing the workaround approach using calculation groups. I really appreciate the effort you put into proposing an alternative approach.

I tested this approach in our model, and here are our findings:

Calculation groups cannot filter row-level data

Your calculation items correctly filter measure results (Self, HR, SuperUser), but Power BI calculation groups:
-Do not filter columns
-Do not remove rows from table visuals
-Do not override RLS row visibility

Thus, in table visuals (or any visual that uses raw columns), users with SuperUser privileges still see all rows regardless of the calculation group selection.

Your workaround works well for measure-level role simulation, and we fully understand the technique.
Unfortunately, it does not solve the key requirement we have which includes table visuals that are using raw columns.

Please let me know if we are missing something or if there is any other alternative approach we should consider.

Thanks again for your time and support.

[MFelix]

Hi @PrasadIngare ,

Once again everything depends on the way you have your model and your visualizations, even using the raw data from the tables you could add a measure with a Simple rowcount to your table filters and get the information to BE filtered.

However and dependong once again on the data probably the best options is not to force the RLS but maybe Change the way you filter the data itself.

What I mean is that if you have 3 levels you will have the self user that Will for sure have the impact of the RLS, the others two roles Will depende mainly on how they want to see the Next level.

Quick question is all your fact tables information based only on the companies? Or is there any others data levels?

Can you elaborate a little bit?

Just to u derstand the correct way you can setup this because if someone is a super user they Will havea access to all the data on any way só the way to go is not RLS for those users but a specific filter on your report.