topic Re: Seeking advice on structuring workspaces for centralized data & departmental self-service in Data Engineering

Seeking advice on structuring workspaces for centralized data & departmental self-service

ak-5537 — Mon, 02 Feb 2026 11:46:41 GMT

Hi everyone,

We currently operate an MVP data platform designed around a medallion architecture. All processing runs in a single workspace and is orchestrated through a metadata-driven master pipeline. Operational metadata, monitoring, and watermarks are stored in a Fabric SQL database.

As we prepare the platform for production, I'd really appreciate advice on how best to organize the workspaces. The key requirements are:

Centralized Gold layer
The platform should produce centralized Gold tables that can be reused across departments.
Central ownership of semantic models and reports
The data engineering team (2 people) will develop and own centralized semantic models and reports. Access to reports and models will likely need to be restricted by department, so that different business teams see different content.
Department-level reuse and self-service
Departments should be able to:
- Reuse centralized semantic models to build their own reports
- Consume and reuse centrally managed reports
- Potentially publish and share reports within their own department in the future

Our end users are not highly technical. Today, most of their work is done in Excel, but they are going through training. We want to give them enough freedom to experiment while still keeping the platform governed and manageable. Departments are relatively small, typically 8-10 users.

Currently, I'm considering a Hub-and-Spoke workspace model with three main workspace types: HUB, REPORTING_HUB, and SPOKE (per department).

HUB workspace

Contains the core data platform (Bronze/Silver/Gold processing).
Has two main environments: TEST and PROD
Feature development is done in temporary FEATURE workspaces
Responsible for producing centralized Gold tables
Data access to Gold tables would be manages with OneLake security

REPORING_HUB workspace

Contains:

A Lakehouse with shortcuts to the centralized Gold data
Centralized semantic models
Centrally managed reports

Also split into TEST and PROD, with development done in temporary FEATURE workspaces
Uses Org Apps to distribute reports to relevant user groups, with access scoped by department

SPOKE workspaces(per department)

Each department has:

A Lakehouse with shortcuts to the centralized Gold data (relevant for the Department)
A shared DEV workspace for experimentation and report development
A PROD workspace for published departmental content

Promotion from DEV to PROD is handled via Fabric deployment pipelines.
Business users are granted Build permissions on centralized semantic models relevant to their role, allowing them to:

Create their own reports on top of the centralized models
Copy and adapt centrally managed reports
(In the future) publish and share reports within their own department

Questions:

1. Does the proposed Hub / Reporting Hub / Spoke workspace model align with good practices for a production data platform?

2. Am I missing anything important (for example around security, governance, scaling as more department are added, or deployment perspective)?
3. Are there any recommended improvements or adjustments to the workspace structure?

Thank you in advance for your time and feedback!

Re: Seeking advice on structuring workspaces for centralized data & departmental self-service

ati_puri — Thu, 05 Feb 2026 06:29:41 GMT

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

Re: Seeking advice on structuring workspaces for centralized data & departmental self-service

v-tejrama — Fri, 06 Feb 2026 06:15:32 GMT

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

Re: Seeking advice on structuring workspaces for centralized data & departmental self-service

v-tejrama — Mon, 09 Feb 2026 04:54:49 GMT

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.

Re: Seeking advice on structuring workspaces for centralized data & departmental self-service

ak-5537 — Tue, 10 Feb 2026 13:18:56 GMT

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.

Re: Seeking advice on structuring workspaces for centralized data & departmental self-service

v-tejrama — Thu, 12 Feb 2026 07:43:03 GMT

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.

Re: Seeking advice on structuring workspaces for centralized data & departmental self-service

v-tejrama — Mon, 16 Feb 2026 07:17:01 GMT

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.

Re: Seeking advice on structuring workspaces for centralized data & departmental self-service

BalajiL — Mon, 16 Feb 2026 09:01:06 GMT

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.

Re: Seeking advice on structuring workspaces for centralized data & departmental self-service

BalajiL — Mon, 16 Feb 2026 09:01:28 GMT

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.

Re: Seeking advice on structuring workspaces for centralized data & departmental self-service

ak-5537 — Mon, 16 Feb 2026 10:56:28 GMT

@BalajiL thank you for your feedback!

We call notebooks in a pipeline. In the notebooks, we define a JSON exit value. Then, using a Lookup activity that executes a stored procedure and passes parameters from the notebook’s exit value, we write the required values into the SQL database.

Re: Seeking advice on structuring workspaces for centralized data & departmental self-service

ak-5537 — Mon, 16 Feb 2026 10:59:16 GMT

@ati_puri thank you for your feedback!