Home / Data Platform / Fabric & Power BI

Data PlatformHow-toIntermediate

Microsoft Fabric foundation: capacities, workspaces, domains and deployment pipelines

Plan Fabric capacities per environment or workload, structure workspaces and domains, lock down tenant settings, and use Git integration with deployment pipelines for dev, test and prod.

Deepak Bhardwaj2 min read

Applies toMicrosoft Fabric (F SKUs), Power BI Premium capacities

1. Capacities

  • Separate capacities for production and development/test, so a developer's heavy notebook can't throttle production reports.
  • Large organisations: a capacity per business unit or per critical workload.
  • Choose the region deliberately (data residency); OneLake data lives in the capacity's region.
  • Pause/resume non-prod F SKUs outside working hours (pay-as-you-go) to save cost.

Scaling and pausing are done on the Fabric capacity Azure resource (portal, ARM/Bicep or the Azure REST API), so you can automate them with the same tooling as the rest of your Azure estate.

2. Workspaces

Pattern per data product or team, per environment:

sales-dev     → capacity fab-nonprod
sales-test    → capacity fab-nonprod
sales-prod    → capacity fab-prod
  • Workspace roles: Admin (platform), Member (owners), Contributor (developers), Viewer (consumers). Prefer sharing apps or items with consumers rather than giving workspace access.
  • Group by domains (Sales, Finance, HR) in the admin portal so governance and discovery follow the business structure.

3. Tenant settings (admin portal)

Review before go-live, especially:

  • Who can create workspaces and Fabric items (security group, not everyone).
  • Export and sharing to external users.
  • Service principal access to Fabric APIs (needed for automation).
  • OneLake access from outside Fabric apps.

4. Git integration and deployment pipelines

  • Dev workspaces connected to Git (Azure DevOps or GitHub): items are stored as code.
  • Deployment pipelines promote content dev → test → prod, with deployment rules to switch data source connections per stage.

5. Security of data

  • Lakehouse/warehouse permissions plus OneLake security (role-based data access) where needed.
  • Row-level security on semantic models.
  • Sensitivity labels (Microsoft Purview Information Protection) on items.

6. Monitoring

  • Fabric Capacity Metrics app: utilisation, throttling, top items.
  • Alerts on capacity overload (see the Fabric throttling post).
  • Admin monitoring workspace for activity and usage.

DR foundations

  • OneLake data is stored with zone redundancy where available. Enable disaster recovery capacity setting for cross-region replication of OneLake data if needed (it has cost implications and limitations; read the current documentation).
  • Keep items in Git so workspaces can be recreated in another capacity/region.

Related fixes