Power BI Workspace-Level Planning - The Decisions You Make One Workspace at a Time

Creating a Power BI workspace takes about fifteen seconds. You type a name, click Apply, and you're done. That speed is the problem. Most of the workspaces we review at Australian organisations were created in exactly that way, by someone who needed somewhere to publish a report before a 2pm meeting, and nobody ever went back to ask what the workspace was for.

A few months ago I wrote about tenant-level workspace planning, which is the big-picture stuff: who can create workspaces, naming conventions, governance levels. Microsoft's implementation planning series has a companion article on workspace-level planning, and it covers the tactical decisions you make each time a single workspace gets set up. It runs to more than 8,000 words. This is the shorter version, with my opinions on which parts earn their keep.

Start with what the workspace is for

Microsoft frames workspace purpose around two intents: collaboration and viewing. I like this framing more than I expected to.

Their example is two finance workspaces. One is a month-end workspace where a small group works on reconciliations and closing reports together. Everyone in it can edit, nobody needs an app, and it's informal. The other is a financial reporting workspace holding the finished, presentation-quality reports that go out to executives through a Power BI app. Same team, same subject matter, very different rules.

The mistake we see most often is one workspace trying to be both. The working files and the polished board reports sit side by side, half the finance team has Member access because they need to edit the working files, and so half the finance team can also edit the board pack. Nobody intended that. It just fell out of putting two purposes in one container.

So the first question for any new workspace is a blunt one: is this a place where people build things, or a place where people read things? If the answer is "both", that's usually two workspaces.

Personal workspaces are where the risk hides

The guidance is direct on this point, and I agree with it. A personal workspace used for anything beyond learning, temporary content or testing increases your organisation's risk.

Here's how it plays out. An analyst builds a report in My Workspace because it's the default. The report turns out to be useful. They share it with a link. Then a few more links. Two years later it's a report forty people open every Monday, it lives in one person's personal workspace, only that person can manage it, and they've just resigned.

You can't publish an app from a personal workspace, so per-item sharing is the only distribution method, which is the hardest kind of access to audit. If you do one thing after reading this, pull the activity data and find out which personal workspaces have content that other people are viewing regularly. The list is always longer than admins expect.

Ownership before structure

Microsoft puts ownership ahead of organisation in the article, and that ordering is right. The goal is to know exactly who is accountable for creating, maintaining, publishing, securing and supporting the content in each workspace.

They suggest a responsibility matrix. I'll be honest, most of our clients don't produce a formal one, and I don't push hard for it in smaller organisations. What I do push for is a named owner per workspace, recorded somewhere that isn't someone's head. A SharePoint list is fine. When two teams genuinely share responsibility for content, the guidance recommends separate workspaces so the line is clear, and that advice has held up every time we've followed it. Co-owned workspaces tend to become nobody's workspace.

Three ways to scope a workspace

The article lays out three options for what goes in a workspace.

One per subject area or project. Think "Quarterly Financials" or "Product Launch Analysis". Access is scoped to a topic, which makes it easier when people from several departments need the same content. Microsoft calls it a good compromise between too many items and too few, and it's the option we recommend most often.

One per department or team. This is where nearly everyone starts, because the org chart is already there. It's simple to explain. But the guidance lists a long set of downsides and they match what we find in the field: workspaces with hundreds of items, apps stuffed with everything, and no way to let a creator edit some items but not others, because roles apply to the whole workspace. Microsoft explicitly recommends against this approach when you expect a lot of items or a lot of users.

One per report or app. Not recommended as a default. The legitimate exception is highly sensitive content. Executive remuneration, for example, should sit in its own workspace so it can be governed on its own terms.

My view: department workspaces are fine for a 50-person business with a dozen reports. Past that, move to subject areas. And when an org restructure happens (it will), subject-area workspaces survive it. Department workspaces need renaming, re-permissioning, and an awkward conversation about who owns "Sales and Marketing - Old".

Separating data from reports

The guidance describes splitting data workspaces (lakehouses, warehouses, pipelines, semantic models) from reporting workspaces (reports, dashboards, scorecards). The benefits are real. Fewer people can edit the certified semantic model. Report creators only get Build permission on the model, which means row-level security is enforced for them too. Ownership gets clearer when a central team owns the data and business units own the reports.

The costs are also real, and Microsoft lists them fairly: more workspaces, more naming conventions, more user education, and a change request process when report builders need something the model doesn't have.

We recommend this split for any semantic model that more than one team reports from. For a self-contained team solution with one model and five reports, it's overhead you don't need.

On development stages, the article recommends a minimum of two. I'd go further and say that if consumers rely on the content, a single workspace where creators publish straight over the top of production is a matter of time before something breaks in front of an executive. Dev and prod at minimum. Add test when you have people who will really do UAT, not just because the diagram looks tidier with three boxes.

The security group problem

This is the most honest section of the whole article. Microsoft recommends assigning groups to workspace roles instead of individuals, and suggests one group per role per workspace. For a single workspace that's five groups: admins, members, contributors, viewers, and app viewers.

Then they walk through what happens next. Split data from reporting and five groups become nine. Add dev, test and prod and the number potentially triples. For one subject area. The article says plainly that this "can quickly become unmanageable".

I appreciate that they said it. In practice, we do a few things to keep it sane:

• Use one set of groups across a collection of related workspaces. If the finance team owns six workspaces, they rarely need six sets of groups.
• Skip viewer groups for development workspaces. Nobody should be viewing there anyway.
• Reuse the same admin group across dev, test and prod.
• Give viewers access through the app audience, not the Viewer role, wherever possible.

If only IT can create Entra groups and the turnaround is a week, people will add individuals to roles instead. Every time. Sort out the group request process before you publish a policy that depends on it.

Settings that are painful to get wrong

A few workspace settings deserve attention at creation time because changing them later hurts.

Workspace type. Pro, Premium Per User, or Fabric capacity. This determines features and who can view. A PPU workspace can only be accessed by users who also have PPU licences, which catches people out when they try to share with the wider business. If you want free-licence users to view content, the workspace needs to be on F64 or higher. We've seen organisations buy a smaller F SKU, publish an app to a few hundred people, and discover the licensing gap on launch day.

Lifecycle management. Git integration and deployment pipelines both need capacity. The guidance suggests Git on the development workspace and deployment pipelines to promote to test and production, and recommends a proof of concept before rolling it out. Do the proof of concept. The two features overlap in ways that confuse teams, and Git integration still has rough edges for item types beyond reports and semantic models.

Azure Data Lake Storage Gen2 connection. If you want dataflow data or semantic model backups in your own storage account, the workspace connection has to be set before you create any dataflows in that workspace. Easy to miss, and annoying to fix afterwards.

Log Analytics. Connecting a workspace to Azure Log Analytics gives you detailed semantic model event logs. Worth it for your handful of high-traffic production models. Not worth the Azure cost for everything.

What I'd skip, and what I wouldn't

The Microsoft article has a checklist after every section, and if you tried to action all of them for every workspace you'd never ship a report. That's fine. It's reference material, not a form to fill in.

For most organisations I'd reduce it to five questions asked at creation time. What is this workspace for? Who owns it? Is it scoped to a subject area? Which groups get which roles? What licence type does it need? If someone can answer those in a two-minute request form, you're ahead of most tenants we look at.

The piece I wouldn't skip is retrofitting. New workspaces are easy to get right. The 200 that already exist are the hard part, and that's usually where our Power BI consultants spend their time: working out which ones matter, who owns them, and which can be archived without anyone noticing. If you're also moving to Fabric capacity, the stakes go up, because workspaces now hold lakehouses and pipelines as well as reports. Our Microsoft Fabric consulting work nearly always starts with a workspace design session for that reason.

Workspace design is unglamorous, and it's also the foundation for everything you want to do later with AI-assisted business intelligence. Copilot in Power BI works off the semantic models people can find and are allowed to use. If those are scattered across personal workspaces and "Test - v2", no amount of AI will sort that out for you.

If you'd like a second pair of eyes on your workspace setup, get in touch. We're happy to have a look.