Power BI Workspace Planning - Why Your Folder Structure Is Actually an Architecture Decision

Every Power BI tenant review we do for an Australian organisation starts the same way. We open the workspace list, and it tells us the entire history of the company's BI journey in one scroll. "Sales Reports." "Sales Reports v2." "Finance - Do Not Delete." "Test." "Test - Karen." Somewhere in there, a workspace called "New Workspace" that has been in production for three years and feeds a report the CFO reads every Monday.

Nobody plans for this. It happens one reasonable decision at a time, because workspaces are free to create and nobody owns the question of how they should be organised. Then one day you need to apply governance, or migrate to Fabric capacity, or work out why a contractor who left in 2024 is still an admin on eleven workspaces, and the mess stops being funny.

Microsoft's workspace planning guidance is one of the better documents in the implementation planning series, and it makes a point most teams miss: workspace design is an architecture decision, not a filing exercise. Having spent years cleaning up tenants through our Power BI consulting work, I want to add the field notes the documentation is too polite to include.

What a workspace actually is, and why the mental model matters

The trap is thinking of workspaces as folders. They look like folders. They are not folders.

A workspace is simultaneously a security boundary, a deployment boundary, a licensing boundary, and an ownership boundary. Every item in a workspace inherits its capacity assignment. Roles are granted at workspace level, so everyone with access to a workspace has that level of access to everything inside it. When you understand that, most workspace design questions answer themselves. When you don't, you end up with the classic antipattern: one enormous workspace per department, with forty people as Members because that was easier than thinking about roles, and a security model that amounts to hope.

Microsoft's guidance frames planning at two levels, and the split is genuinely useful. Tenant-level planning is about the rules of the game - who can create workspaces, what naming conventions apply, how workspaces map to capacities and domains. Workspace-level planning is about each individual workspace - its purpose, its owner, its membership, its lifecycle. Most organisations do neither and improvise both.

Scoping - the decision that drives everything else

The core question is what one workspace should contain, and the honest answer is "less than you think."

The guidance talks about organising by subject area, by team, by project, or by type of content, and the right answer varies. But after enough tenant reviews, my rule of thumb is this: a workspace should hold content that shares an owner, an audience, and a release cadence. Break any one of those three and you'll feel friction. Content with different owners in one workspace means nobody feels responsible for it. Different audiences means your role assignments are always either too generous or too restrictive. Different release cadences means someone's careful monthly release process shares a space with someone else's daily hotfixes.

The two failure modes sit at opposite ends. Workspace sprawl - hundreds of tiny workspaces, one per report, usually caused by leaving workspace creation open to everyone. And workspace monoliths - "Finance" as a single workspace holding two hundred items spanning payroll, board reporting, and someone's abandoned experiment from 2023. Sprawl is annoying but survivable. Monoliths are worse, because the day you need to give the payroll analysts access without exposing board papers, you discover the workspace boundary is your only real security boundary and you've built everything inside one.

One pattern that's worked well for our mid-sized clients: separate workspaces for data and for reports. Semantic models live in a workspace managed by the data team, reports live in workspaces closer to the business, connecting to those shared models. It adds a little coordination overhead, and it completely changes the governance story, because your single source of truth stops being a slogan and becomes an access control list. I wrote separately about sharing semantic models across workspaces, which is the mechanism that makes this pattern go.

Dev, test, prod - yes, even for that little report

The guidance is firm on separating development, test, and production workspaces, and I'll be firmer: every report that anyone relies on deserves this, and deployment pipelines make it cheap enough that the old excuses have expired.

The pushback is always the same - "it's just one report, we edit it live." Then someone edits it live at 4pm on the day of a board meeting, the numbers change, and suddenly BI has a credibility problem that takes a year to repair. Trust in reporting is expensive to build and absurdly cheap to destroy. Dev, test, and prod workspaces plus a deployment pipeline is maybe an hour of setup. It's the cheapest insurance in the entire platform.

What we've seen work: developers get Contributor or Member in dev, almost nobody has write access in prod, and content moves forward only through the pipeline. The moment someone with prod write access "just quickly fixes something," your environments have diverged and the pipeline will surprise you at the worst possible time. This is a people problem wearing a technology costume, which is why the role assignments matter more than the pipeline itself.

Roles - fewer Admins than you have, Viewers for almost everyone

The four roles - Admin, Member, Contributor, Viewer - are simple, and almost every tenant we review misuses them the same way: too many Admins, and Viewer barely used because content gets shared through workspace access instead of through apps.

Two admins per workspace, and ideally one of them is a group, not a person. Everyone consuming content should be doing it through an app, not through Viewer access to the workspace itself, because apps let you curate what consumers see and decouple your working area from your published surface. Workspace access is for people who build. If your consumer count inside workspaces is growing, your app strategy has quietly failed.

And use security groups for role assignment, always. Assigning individuals feels quicker and creates the exact "departed contractor still has admin" finding that turns up in every audit we run.

The Fabric wrinkle

Everything above got more consequential when workspaces became Fabric workspaces. A workspace can now hold lakehouses, warehouses, pipelines, and notebooks alongside reports, workspace capacity assignment now determines real consumption costs, and domains add a grouping layer above workspaces for data mesh style organisation.

My honest take: domains are useful for large organisations and premature for most others. If you have under fifty workspaces, get the workspace layer right first. But capacity assignment planning is now unavoidable at any size, because which capacity a workspace lands on is a cost and performance decision, and a runaway workload in a badly placed workspace can slow down everything sharing that capacity. This comes up constantly in our Microsoft Fabric consulting engagements - workspace layout and capacity strategy have effectively merged into one conversation, and teams still planning them separately are planning twice and getting neither right.

Where to start if your tenant is already a mess

Don't boil the ocean. The full re-org projects we've seen attempted mostly stall, because every workspace move touches someone's bookmarks and somebody's Excel connection.

What actually works is a settlement strategy. Write the target standard - naming convention, scoping rules, role policy, lifecycle stages. Apply it to everything new, ruthlessly, starting today. Then migrate old content opportunistically, whenever something is being reworked anyway. Within a year the centre of gravity shifts and the legacy mess becomes a shrinking island rather than the whole map. Restrict workspace creation while you're at it - not banned, but requested, with a human who asks "what's this for and who owns it" before clicking create. That one governance control prevents more mess than any cleanup removes.

If your workspace list currently reads like an archaeological dig, or you're staring down a Fabric capacity migration and realising your workspace layout was never designed for it, this is bread-and-butter work for us - get in touch and we'll tell you honestly whether you need a settlement strategy or a proper rebuild.

Workspaces are the one part of Power BI that every user touches and nobody designs. Design yours. Future you, mid-audit, will be grateful.