Forum Discussion
How to Set Up Row Level Security for 2 Separate Filter Conditions Without Duplicating Fact Table?
- 6 months ago
Hi chasejc,
Thank you samratpbi Zanqueta danextian, for your insights.
Apply RLS to set the maximum access for each salesperson, so they can view either their own sales or sales made to customers they manage. RLS should define the complete range of data they are allowed to see and should not be used as a toggle. Create a disconnected table with options such as “Personal Sales” and “Customer Responsibility” to use as a slicer in the report. Depending on the slicer selection, use measures to adjust the visuals to display either personal sales or customer-owned sales, and apply these measures as visual-level filters (like > 0 or not blank) to manage what is shown without needing extra tables or relationships.
Thank you.
Hi chasejc
Row-Level Security (RLS) is enforced at the semantic layer, which means it is applied at the data model level and cannot be overridden or altered at the report layer. As a result, report-level filters or visuals cannot bypass or change the access restrictions defined by RLS.
When multiple roles with different levels of access are defined, a user who is assigned to more than one role will inherit the combined permissions of those roles. This determines the scope of data the user can access when interacting with reports that are built on the same semantic model.
What to try:
- Zanqueta 's suggestion
- If different permissions are required depending on the view, consider creating a dedicated calculated summary table that exposes only aggregated values. The calculated table must be designed at the appropriate granularity, since different visuals or audiences may require aggregations at different levels (for example, by month, region, or product category). This table will not be affected by RLS as long as it does not receive filter context from any table that has RLS applied. For example, if the Employees table has RLS, it should not have any relationship with the summary table.
If I were to create a summary table that doesn't have any RSL applied, how would I be able to only show information for a seller if they view it from their account? I'm not sure what the actual practical reason to have a summary table here is.
- v-saisrao-msft6 months agoCommunity Support
Hi chasejc,
Thank you samratpbi Zanqueta danextian, for your insights.
Apply RLS to set the maximum access for each salesperson, so they can view either their own sales or sales made to customers they manage. RLS should define the complete range of data they are allowed to see and should not be used as a toggle. Create a disconnected table with options such as “Personal Sales” and “Customer Responsibility” to use as a slicer in the report. Depending on the slicer selection, use measures to adjust the visuals to display either personal sales or customer-owned sales, and apply these measures as visual-level filters (like > 0 or not blank) to manage what is shown without needing extra tables or relationships.
Thank you.