Forum Discussion
Post ProdigyManaging logical data unbundling between companies
Hi,
in a Fabric environment I've three workspace, the DataWS having a warehouse with all companies data, two Power BI reporting workspaces, the RepWS01 for the main company and the RepWS01 for the other companies.
I need to implement a logical data unbundling or separation between the main company and the other companies.
I don't want to duplicate warehouse tables in the DataWS workspace.
I think to create a lakehouse in the two reporting workspaces to allows the users to access and query the warehouse; each lakehouse could "see" the warehouse by a shortcut.
Moreover, I think to create in the warehouse specific views for the main company and for the other companies, simply filtering the companies. I could also implement the RLS in the warehouse.
Which could it be the right solution in a such scenario? Thanks
Hi pmscorca ,
You can meet the data unbundling requirement by carefully managing workspace and data permissions. For each company, create a dedicated reporting workspace where the end users will access Power BI reports. Then, in a central lakehouse, create shortcuts to the unique data warehouse for each workspace.
This way, you don’t duplicate data but still provide controlled access. Make sure to grant the right permissions both on the reporting workspace and on the lakehouse,warehouse shortcuts so users can query the data without accessing other companies data. This approach keeps things simple, secure, and aligned with Fabric’s best practices for data access and separation.
Thank you.
17 Replies
ssritharSuper User
Hi pmscorca ,
In this scenario, the simplest and most maintainable solution is to keep one central Warehouse in the Data workspace and implement logical data separation using SQL views and security, rather than duplicating data or introducing extra Lakehouses.
One Warehouse → filtered SQL views → Warehouse RLS → Power BI semantic models per reporting workspace.
This approach provides clear data separation, strong security, and minimal operational complexity.
If this post helps, then please appreciate giving a Kudos or accepting as a Solution to help the other members find it more quickly.
If I misunderstand your needs or you still have problems on it, please feel free to let us know. Thanks a lot!
pmscorcaHi, thanks for your reply.
I intend to have one warehouse in the DataWS workspace, where I would like to create some filtered SQL views, but the end users will be able to access to the two reporting workspaces, RepWS01 and RepWS01, where they will be able to use the reports and query by a SQL Analytics endpoint; for this reason, I think to create one lakehouse for each reporting workspace and one shortcut linked to the unique warehouse.
Thanks
Hi pmscorca ,
There is no need to introduce a Lakehouse or shortcuts in this scenario.
Warehouses can be accessed across workspaces, including via the SQL Analytics endpoint, with security consistently enforced at the Warehouse level rather than the workspace level.
By creating filtered SQL views in the central Warehouse and applying the necessary permissions or row-level security, users in either reporting workspace will only have access to the data they are permitted to see. Implementing a Lakehouse with shortcuts would not enhance isolation or security and would add unnecessary complexity. Maintaining a single Warehouse with logical separation through views and security is the most straightforward and sustainable solution for this setup.
Thank you.
- stoic-harsh
Hi pmscorca,
I suggest not to reuse a Fabric Warehouse across workspaces for secured access (RLS/CLS) via Lakehouse shortcuts. That pattern is not supported and will behave inconsistently.
Keep one warehouse in DataWS, expose company-specific views/tables + RLS/CLS in the same workspace, and build separate semantic models on top of these views/tables, and finally share the reports or semantic models, not shortcuts.
