Best Implementation Practices

Hi SamyAbdul​,

Yes, I think you are moving in the right direction, and for one team with fewer than 100 users I would probably start simpler than the original 9-workspace design.

Your proposed six-workspace pattern is reasonable:

DEV Engineering
DEV BI

TEST Engineering
TEST BI

PROD Engineering
PROD BI

I would use the Engineering workspace for ingestion, bronze/silver processing, pipelines, notebooks and related engineering assets, then keep semantic models/reports in the BI workspace.

The reason I like that split is that a Fabric workspace is an important security boundary. Microsoft’s workspace permission model applies workspace roles across the items in that workspace, so separating engineering data from business-facing BI content gives you a cleaner access boundary.

I would not create separate Ingest/Data/BI workspaces in every environment unless you have a real security, ownership or deployment reason for doing so.

For one team, folders, naming conventions and separate Lakehouse layers can keep the Engineering workspace organized without multiplying the workspace count.

For example:

Engineering workspace

- ingestion/pipelines
- bronze
- silver
- gold engineering tables

BI workspace

- semantic models
- reports
- apps

Then introduce domain-specific workspaces later when NetSuite, iMIS, HubSpot, etc. become independently owned or governed data products, rather than creating a workspace purely because a new source system appears.

I would also establish Git and deployment pipelines early. Microsoft’s Fabric CI/CD guidance recommends separate Dev/Test/Prod environments so changes can be promoted rather than manually recreated.

One important point on F16: I would not size the capacity from the number of users alone.

Pipelines, Spark jobs, semantic-model refreshes and interactive reporting all consume the same capacity pool. I would start with F16 if the budget and expected workload support it, then use the Capacity Metrics app to measure actual CU consumption before deciding whether F32/F64 is needed.

Also check your Power BI licensing model. On Fabric capacities below F64, report consumers still need Power BI Pro/PPU or another qualifying license. F64+ is where Free users can consume Power BI content as viewers.

For Dev/Test/Prod capacity isolation, Microsoft recommends separate capacities when you need strong isolation, but for a smaller cost-sensitive implementation I think sharing the initial capacity can be reasonable as long as you understand that development workloads can compete with production for the same CUs.

So for your current size, I would start with the six workspaces, keep the architecture disciplined, monitor capacity usage, and only introduce additional workspace/domain boundaries when there is a clear security, ownership or scaling reason.

That is usually easier to govern than designing the full enterprise workspace topology before the estate actually needs it.

AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.

Hi SamyAbdul​ ,

Thank you for reaching out to fabric community.

For your scenario, OneLake + Lakehouse is a suitable choice if the workload is mainly API-based analytics rather than transactional OLTP.

Key things to define upfront:

• Architecture: Bronze -> Silver -> Gold -> Semantic Model. 
• Workspace: Keep Dev/Test/Prod separate, but avoid unnecessary workspaces.
• API ingestion: Plan for incremental loads, pagination, retries, 429/rate limits, and schema changes.
• Security: Use least-privilege access, service principals/managed identities and RLS where required.
• Performance: Avoid small files and unnecessary full loads.
• Monitoring: Maintain audit tables for pipeline status, record counts, watermarks and failures.
• CI/CD: Establish Git, deployment and environment parameterization early.
• Governance: Define naming, ownership, retention and data-quality standards.

Thanks!!