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 , 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.

[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.