Forum Discussion
Row Level Security
RLS always applies for the condition where the expression is TRUE. Imagine that you have a dimension and an RLS table like the following screenshot:
As you notice, these are not paired via any relationships... You can always test for if an evaluation is TRUE or FALSE for your RLS by creating a temporary column to check the expression:
In this sample case, I'm looking to see if [email protected] is found my RLS table, if so, let's go look for him in the Dimension table as well:
Again, as long as it returns TRUE, then RLS can be applied... I checked for User1 and seems he's found.. If I change it to another user... USERABC and he's not found so his records will be false:
Now... since we know it works... replace the hardcoded UPN with USERPRINCIPALNAME to make it dynamic in your actual RLS:
I've uploaded a sample for your reference.
I have seen this article already. we explored treatas option before. But performance is not good with treatsas. So we cannot go that route as well
If USERELATIONSHIP is not working and TREATAS is slower, I can only can think of using VALUES with/without TREATAS.
Also consider:
Redo your calculate logic with different approach. Say, if your role is giving thousands of row, add a category or group and then bring the group to the user, this way it reduces the data to filter based on the user.
Below are the videos he talks about few scenarios. since you can't share the model, take a look:
https://www.youtube.com/watch?v=qID6g_WmNEo
https://www.youtube.com/watch?v=s7PPArgNzd8
https://www.youtube.com/watch?v=2caokSoWWUA
I am sure you might have tried already, but providing to have one more review! If your RLS is too complicated and affects more dax functions, then performance may be affected. It also depends on the performance of your data model.
https://learn.microsoft.com/en-us/power-bi/guidance/rls-guidance