The ultimate Fabric, Power BI, SQL, and AI community-led learning event. Save €200 with code FABCOMM.
Get registeredAsk the Fabric Databases & App Development teams anything! Live on Reddit on August 26th. Learn more.
Greetings, all. I have an enterprise-oriented scenario and am wondering if anyone has suggestions around how to handle this. We want to segregate client reporting/data by workspace out of a centralized data warehouse. Ideally, we'd keep the data duplication to a minimum while still being able to leverage capabilities such as DirectLake given the data volume.
Here's my question: is it possible to use shortcuts from a lakehouse in one workspace to another but "filter" the data being shortcuted over? In other words, is it possible to ensure that a target workspace only contains a particular client's data?
Thank you for the replies, @frithjof_v and @FabianSchut. To clarify, we are working toward the use of Power BI Embedded in an app-owns-data scenario, so the isolation of data into separate workspaces is a data security redundancy. Here's a diagram illustrating the concept:
If isolated data workspaces are used for our organization, the thinking would be this would ensure there is a reduced risk of the wrong RLS role being granted access to other clients' data within the same dataset if data is segregated into different models and clients receive explicit access grants to models containing their data. Granted, there are tradeoffs elsewhere, but the logic here is that if a DAX role were misconfigured (easy thing to do), there still would be no chance another client's data would be surfaced.
Hi @arpost ,
Did the above suggestions help with your scenario? if that is the case, you can consider Kudo or Accept the helpful suggestions to help others who faced similar requirements.
If these also don't help, please share more detailed information and description to help us clarify your scenario to test.
How to Get Your Question Answered Quickly
Regards,
Xiaoxin Sheng
I created an Idea for it, please vote ☺️
Filter and RLS on OneLake shortcuts
https://ideas.fabric.microsoft.com/ideas/idea/?ideaid=3377564d-c79e-ef11-95f6-002248555ab4
Just did 👍
Hi, unfortunately, it is not possible to add some filters on the shortcuts you create from one workspace to another. Do the client's need to see the data in the lakehouses too? Or only the reports? If only reporting is important for the client, you can add row level security rules. The data will still be in the client's workspace, but inaccessible if set correctly. Another option is to have the data in the "main" workspace already seperated by client and unionen together in a view within the "main" workspace. You can then select the client specific data for shortcuts.
Otherwise you really need to copy the data with filters applied which results in data duplication.
"If only reporting is important for the client, you can add row level security rules. The data will still be in the client's workspace, but inaccessible if set correctly"
Note that if you use this approach, the client should not have any workspace roles in the client workspace, because the workspace roles will give too much access. Instead, the client should only get item Read permission on the Power BI report or Power BI App. Sharing a Power BI report or Power BI App also automatically grants the recipient Read permission on the entire underlying semantic model. So it's important to use RLS (and/or OLS) to limit the amount of data the users can access.
Another option would be to keep the semantic model in the main workspace, apply RLS/OLS to the semantic model, and share the Power BI report or Power BI App with the client with only Read permission. Again, remember that sharing a Power BI report (or Power BI App) also means sharing access to the underlying semantic model, so remember to use RLS/OLS if the users are not supposed to have access to all the data in the semantic model.
User | Count |
---|---|
16 | |
10 | |
8 | |
4 | |
3 |
User | Count |
---|---|
53 | |
22 | |
20 | |
17 | |
12 |