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.
Hi ak-5537 ,
Thanks for reaching out to the Microsoft fabric community forum.
This design demonstrates thorough planning and consideration for both MVP and long term production needs. Centralizing Bronze, Silver, and Gold processing in one workspace establishes a strong foundation, streamlining ownership, support, and troubleshooting, while clearly separating data engineering from business data consumption.
Setting up a dedicated reporting workspace for semantic models and centrally managed reports is an effective approach. This structure supports efficient model management, RLS implementation, and access control, while enabling multiple departments to leverage the same trusted resources. Managing access through apps and security groups is a proven method, particularly as teams continue to build familiarity with Fabric and Power BI.
Department-specific spoke workspaces, with a shared DEV environment for experimentation and a controlled PROD environment for publishing, provide users with learning opportunities without compromising platform stability. Utilizing shortcuts to Gold data, rather than duplicating it, enhances consistency and reduces potential issues.
It is important to maintain strict permission controls. Leverage Entra ID security groups, restrict write access to core data and central models to the data team, and grant business users build access only where necessary. Applying RLS at the semantic layer will further support model flexibility and reusability.
Overall, this architecture is well-positioned to scale as more departments are onboarded and should support a smooth transition from MVP to a robust production environment.
Best Regards,
Tejaswi.
Community Support
Hi ak-5537 ,
I wanted to follow up and see if you had a chance to review the information shared. If you have any further questions or need additional assistance, feel free to reach out.
Thank you.Hello v-tejrama, thank you for your feedback!
I'm considering separating the Fabric SQL Database and Lakehouses into a dedicated storage workspace. The goal is to optimize items lifecycle management and avoid rehydrating storage each time a new feature workspace is created.
I'd really appreciate your thoughts on whether you see any potential pitfalls or risks with this approach.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.