Forum Discussion
Performance Issues when to many RLSs are defined
Hi, Anonymous
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. If only 50 users, it should be no problem.You can access as a user, it doesn’t matter if it’s not slow.
But in the dashboard tile refresh, it will be affected. You can refer to the content of the document:
By default, Power BI maintains a single cache for every tile, but if you use dynamic security to restrict data access based on user roles, then Power BI must maintain a cache for every role and every tile. The number of tile caches multiplies by the number of roles.
If it doesn’t solve your problem, please feel free to ask me.
Best Regards
Janey Guo
If this post helps, then please consider Accept it as the solution to help the other members find it more quickly.
what are the rules behind these roles? simple filters on a single column, or very complex DAX expressions?
If your client doesn't know the eventual size of the list then you may want to consider outsourcing the RLS computations to a reference table that you then incorporate into your data model as a top level dimension. That will allow you to drastically reduce the number of Roles required.
These are basic rules, a filter on a single column.
The scenario is more like: a user is part of 1 or mutiple portfolios and when he logs in he should see only the entities which are part of his portfolio. The client already has configured CWS groups which works more or less like AAD groups. By having a RLS for each portfolio we can assign a CWS group to each role. Is there any other way to implement this scenario?
lbendlin
I know this comment is a few years old but I hope you see this.
How would I reference a table that has RLS applied to it? I have a model with 25 dimensions and if I put RLS on all of them it fails. However, this idea seems like a great one I just can't get it to work. I created a dimension that is joined to the RLS table. I then referenced that table to join to my fact table. Problem is my dimension isn't being filtered by the RLS...Here's the preference of RLS implementation
Best: No RLS. Do you really, really need it? Is your data very sensitive?
Good: Dynamic RLS, with rules outsourced to reference dimension table that controls the protectables.
Not so good: Static RLS with rules defined in the semantic model. Too much maintenance effort.
