Forum Discussion
Seeking advice on structuring workspaces for centralized data & departmental self-service
Hi ak-5537 ,
Few suggestions and soltuions for the above approach:
1) Best-practice pattern for Gold-layer serving is to expose views and grant access to views (not base tables), manage roles/groups, and keep security artifacts deployable—often via pipelines/Git.
2) If users are non-technical, it is recommended to give limited access to Gold tables and most users consume via semantic models/apps. Only PBI users should get the build permissions.
3) Users who has contributor access to reporting workspace automatically gets build permissions to semantic models.
4) Since your users are not highly technical, you will want to avoid accidental data leakage and model misuse.
- Create Entra groups like dept_finance_pbi_builders, dept_finance_pbi_consumers
- Grant Build only to the Builders group for the relevant centralized models
- Everyone else consumes via app audiences (read-only experience)
If you found this helpful, consider giving some Kudos. If I answered your question or solved your problem, mark this post as the solution.
Thanks
Ati
Hello again ak-5537 ,
Separating the Fabric SQL Database and Lakehouses into a dedicated storage workspace is an effective strategy for enhancing lifecycle management and minimizing unnecessary rehydration when creating or removing feature workspaces. This approach is most successful when the storage workspace is managed as stable production infrastructure, with defined ownership, restricted write access, and a formal process for handling schema to avoid unintended effects on dependent development and reporting workspaces.
Thank you.
Fundamentally looks good to me. We are working on the similar approach.
Few thoughts:
- Domains can be used for departmental specific need.
- No need to create shortcut in the BI, create semantic model in your data workspace ie. HUB and reference that in the BI need for creating reports etc. Semantic model cannot be created from shortcut tables that is a limitation in Fabric.
- Trying to understand using sql database in Fabric for auditing purpose. We are facing some challenges calling sql database in spark notebook. %%tsql still in preview - Are you able to use DML inside spark notebook.