This is the 6th part of our Fabric Capacity Management series. If you haven’t yet, check out the earlier articles:
- Part 1: Causes and Consequences of Capacity Overloads
- Part 2: Actions to Take During Capacity Throttling
- Part 3: Alerting Users During Capacity Throttling
- Part 4: Capacity Monitoring for Self-Service
- Part 5: Capacity Monitoring for Self-Service
Testing on production is one of the oldest IT jokes – everyone knows it’s risky, yet it still happens. In Fabric, the problem is especially visible in self-service scenarios.
Think about it: a single shared capacity hosts both critical production workspaces (with reports used daily by hundreds of users) and development workspaces where citizen developers experiment, test queries, tweak incremental refresh, and trigger manual refreshes.
That’s effectively “testing on prod” — and it’s a recipe for trouble. From time to time, it leads to capacity throttling, causing slowdowns, report errors, or even refresh failures.
So, how do you mitigate the risk? Let’s break it down.
Separate Workspaces by Purpose
Production workspaces
- Only for production-ready items.
- No direct development or manual refreshes.
- Refreshes should be scheduled and predictable.
- In some organizations, developers don’t even have edit rights here (Viewer only, or no access at all).
Development / Test workspaces
- The number depends on your governance model — dev, test, UAT, pre-prod, etc.
- The development workspace is the place for building and testing.
- No scheduled refreshes — only used when active development or testing is happening.
Moving Content Across Environments
There are several ways to promote content from dev to prod:
- Manual deployment (not recommended): developers publish content directly. Risky and error-prone.
- Deployment pipelines (recommended): Power BI’s built-in mechanism. Supports parameter and source replacement (e.g., dev sources in dev, prod sources in prod).
- Advanced CI/CD approaches: using pipelines or repositories with approval workflows, automated testing, and version control. More effort, but also more governance.
Use a Separate Development Capacity
Even with dev/test workspaces, you don’t want development activities to impact production capacity. The best practice is to run them on a separate Fabric capacity.
Key considerations:
- Assign dev/test workspaces there.
- It doesn’t need to be large — sometimes even F2 is enough.
- Typically used only by Pro-licensed developers and self-service users.
- Should support start/stop to minimize cost.
- Give teams the ability to start it when needed.
- Add automatic shutdown (e.g., after hours or in the evening) to avoid wasted spend.
Final Thoughts
Separating development from production workspaces — and ideally running them on separate capacities — is one of the most effective ways to keep your Fabric environment stable.
It reduces the risk of experiments disrupting business-critical reports and helps organizations scale their self-service safely.
How do you handle this in your organization? Do you separate dev/test/prod workspaces? Do you use a dedicated development capacity?
#MicrosoftFabric #PowerBI #Optimization #MicrosoftFabricOptimization #SelfService #SelfServiceBI #CitizenDeveloper #FabricMonitoring #FabricObservability #FabricManagement #FabricGovernance
Leave a Reply