.png)
Most Power BI estates are not designed, they just accumulate over time. Someone publishes a report, someone else copies it, a third person shares a link, old developers followed their own process and a year later nobody can say with confidence where anything lives or who can see it. The mess arrives from two directions at once. There is no structure in where content lives, whether that is everything dumped into one person's My Workspace or a new workspace spun up for every report and there is no structure in how content reaches people, just shareable links and Excel exports scattered across the business. Usually this happens for one simple reason: nobody, in particular the BI or central data team, ever sat down and designed the structure. It defaulted into existence!
That is the whole point of this blog. If you do not design the environment, it designs itself, and it rarely designs itself well from my experience of working with 100s of clients over the years. What follows is how to think about the structure, some specific items I want to flag from my own experience, not a click-by-click setup guide.
A quick note on terms, when I refer to a Power BI framework, I mean the workspaces, apps, app audiences, org apps and the security surrounding them. Everything here applies equally to Microsoft Fabric, where Power BI is one workload within the wider platform.
Summary
A Power BI and Microsoft Fabric framework is the deliberate structure of workspaces, apps and audiences that keeps an estate navigable, secure and trustworthy as it grows. Some of the decisions that matter most are separating your semantic models from your reports, shaping your workspaces around how your team actually works rather than copying a best practice template, not resulting to shareable links for everything and using app audiences to control who sees what instead of creating ever more workspaces or links. Get those right and the estate scales with you. Get them wrong and you spend your time firefighting duplication and access requests.
Key takeaways
- If you do not design your Power BI framework, it designs itself, usually as sprawl and shareable links nobody can govern.
- Separate semantic models from reports into their own workspaces, with reports connecting to models by live connection or direct lake.
- "One workspace per department" is the common advice, but it is not always right, and "one workspace per report" is almost always wrong.
- You do not automatically need a DEV workspace. Add environments when they earn their place, not by default.
- Control who sees what through app audiences, not by creating more workspaces. End users should only ever open an app.
Workspace or App: who each one is for
Two of the building blocks still get confused to this day, and I mean all the time, so it is worth being clear before we go deeper.
First, think of a workspace as a folder that stores different items. It is the place your Power BI reports and semantic models first land once you publish to the Power BI Service (app.powerbi.com). Just as important, a workspace is where we collaborate, build and test, aimed at the core data team and content owners, not the business users or report consumers. This is not the environment for them. Workspaces, also referred to as shared workspaces, hold various items such as reports and dashboards, dataflows, paginated reports and semantic models, and now with Microsoft Fabric a lot more, such as notebooks, pipelines, warehouses and so much more. Importantly, a workspace also acts as a security layer, it gives you controlled access and clear ownership over everything inside it.
An app is the read-only, packaged version of selected items within that workspace. So the workspace is for development and testing, for the core data team and anyone building, and the app is for business users and report consumers to read what is built for them. You publish an app on top of the workspace for the people who only need to consume it. So, a workspace and an app has a one to one relationship. An app is also presented with clean navigation, on brand, without the technical detail and buttons a workspace holds. The point is, it is for the end user, and it is business friendly. Side note, as workspaces evolved over the years, with so much more being added, it should be clear this is not an environment for end users.
One thing to get out of the way early... we also have something called, My Workspace! This is not the same as the shared workspace we discussed above. Think of it is a personal workspace, a private sandbox tied to one individual account. Believe it or not, I have seen entire production solutions hosted in a single My Workspace and distributed by shareable links across the whole Power BI tenant (multiple times). Please do not do this! Content there cannot be governed through workspace roles, cannot be distributed through an app, cannot have access managed through groups and depends entirely on one account staying available. Nothing the business relies on should live there.
So, the rule of thumb is simple. Developers and owners work in workspaces. Consumers get the app, and should never need to set foot in a workspace at all. Keep that split clear and most of the later decisions get easier.
Power BI workspace roles: who gets what
Workspaces have four roles, and choosing the wrong one is a common mistakes I also see, so will highlight it here. Admin has full control, including managing access and deletion. Member can create, edit and publish content, and can publish apps and update them. Contributor can create and modify content but cannot touch the app, unless an Admin explicitly delegates app-update permission to Contributors, a setting I would leave off. Viewer can only view content within the workspace itself.
With the above said, I would keep Admin to a very small group, typically the central BI team plus a Fabric admin for oversight. If that BI team is large, restrict it within there also. Most people building content only need Contributor. The ability to update the app is the ability to push content live to the whole business, so it is worth treating Member as a deployment role and holding it back from anyone who does not need it. In smaller central teams the same few people hold Admin and everything below it, and that is fine; the discipline matters more as the team grows. Worth remembering too that these roles stop at the workspace: platform-wide controls, tenant settings, who can create workspaces, sit in the admin portal (Fabric Settings) with your Fabric Admins.
The role I would use least is Viewer, and your probably thinking why... when we have more consumers, so surely we need more Viewer roles. But, as I explained above, workspace are more for development and testing purposes. Giving report consumers Viewer access to a workspace gives them a window into the working environment, with drafts, half-finished content and everything else. So again, that is exactly what the app exists to avoid. Ideally, business users and report consumers should hold no workspace role at all. Their route is the app.
Separate your semantic models from your reports
If you take one structural decision from this blog, make it this one. Keep your semantic models (what Power BI used to call datasets) and your reports in separate workspaces, rather than bundling model and report together in a single file published to one place.
To be clear on this, when we open Power BI Desktop, the default file type is .PBIX. To all you experts, yes I know there are other format types, but to simplify it and make this point... each .PBIX file contains two things. The report elements and data model elements. When you publish from Power BI Desktop, it will publish the semantic model and report as two items within a workspace. So, what I am suggesting is to create the semantic model first (say in Import mode), publish it. Then you open PBI Desktop again, and connect to that model with a Live Connection. This is also what we call thin reports and I am sure now you can start to see the difference. One centralised, well governed and built semantic model with many reports pulling from the same place.
With the above in mind, the semantic model should ideally sit in its own workspace, perhaps called "Enterprise Semantic Models", with limited access. The reports are then published to separate workspaces. Again, the model workspace holds the governed, certified semantic models. Think of this as the golden suite that serves all your reports. To be clear, a semantic model can contain the data connections, Power Query transformations, relationships and measures. The report workspace holds the reports, which connect to those models using a live connection (or Direct Lake depending on underlying source) rather than carrying their own copy of the data. The connectivity choice is its own topic, so I will not rebuild it here: Power BI Storage Modes Demystified covers the options, and Power BI Direct Lake in Microsoft Fabric goes deep on how Direct Lake actually works.
But, why bother? Because it changes how the whole estate behaves. Every report stops dragging its own slightly different version of the data behind it. There is one place to fix a measure, one definition of revenue, one model to certify and secure. It separates the work too, so the people who model the data and the people who build reports can get on without standing on each other. I have written separately about why the model itself matters so much, in Power BI Semantic Model and Why It Matters More in the Age of AI and Data Modelling in Power BI, so I will not repeat the modelling detail here.
One practical point that catches people out once models and reports are separated: report consumers still need Read permission on the semantic model to view the reports built on it. Access to the app alone is not enough; without Read on the model, the reports inside the app simply will not load and look broken... ahh the amount of times this has been raised with me over the years. Grant it through the same groups you use for audience membership and it stays manageable.
The structural point is simply this, models in one workspace, reports in another, connected live, never carrying their own copy of the data.
Shape the estate around your team, not a template
Once models and reports are separate, another question may be how to divide the workspaces themselves. This is a very common question we receive in Metis BI. You can split them up in several ways. Here are some I heard over the years from Microsoft and from my own experience: per report, per analysis or subject area, per initiative or project, or per department. As you would expect, the most common one is per department and for a large organisation with separate teams building their own content independently, it works well most times.
It is not always the right answer though. For a small, central team producing content that cuts across the whole business, one workspace per department can backfire. Again, not a one size fits all with these things. Either you duplicate every shared report per department workspace and now each copy has its own refresh schedule, its own security to maintain and its own chance to drift (not good) or you keep shared reports in one workspace and give every department access to it (think a enterprise wide workspace), which creates dependencies between them that add overhead of their own. The other way around this is host all in a single workspace, and use Shareable Links. All of these are not good. I always tell my clients the same thing, shape the structure around how your team actually works, not around a diagram lifted from a best-practice deck. The deck will not be there maintaining the estate in a year, you will.
An an example, for a small central data team, a clean and genuinely scalable shape could be a handful of workspaces organised by content type (think reports and models) and environment (DEV, UAT, PROD), and the separation of business area can actually be through App Audiences within a App - more on this below.
You might not need a DEV workspace
As I mentioned the environments, above, this is a good place to raise this point. The standard lifecycle pattern, and the default in most best practice guides, is three deployment environments: development (DEV), user acceptance testing (UAT) and production (PROD). The idea is sound and we always implement a deployment process for clients in Metis BI. Simply put, changes move through stages rather than landing straight on live. However, here is the the point... you do not automatically need all three as their own workspaces.
For years, when working with clients I have been promoting (in specific cases - not always) whether we ned the DEV environment at all. So, a DEV workspace in the Power BI Service and MS Fabric earns its place when several developers are working on the same content at once, when automated testing is in place, when there are multiple SQL database instances and policy also pushes us to align or when deployment pipelines are promoting content between stages. Without any of those, it tends to sit empty or quietly become a dumping ground for half-finished work. For a smaller team, development happens locally in Power BI Desktop and that is perfectly sound.
What you do want is UAT and PROD. UAT is where you test the things that can only be tested in the Service, refresh schedules, data source credentials, security role behaviour, the live connection between a report and its model, and, crucially, a place for selected users to check a report and sign it off before it goes live. A useful trick here is to publish a separate UAT app from the UAT workspace, so testers validate the report the same way they will consume it in production, through an app rather than by browsing a workspace, then remove their access once sign-off is done.
People sometimes question the point of UAT when it connects to the same data sources as PROD. The answer is that UAT exists to validate structural and configuration changes also. This matters most for the models, where a change to security roles, schema or measures takes effect immediately across every connected report. A broken change published straight to PROD hits every user instantly. UAT is where that gets caught.
PROD is the governed, live estate that the business actually uses. If you grow into needing DEV or deployment pipelines later, they slot in without disrupting what you already have. The deeper mechanics of pipelines and lifecycle management deserve their own blog, so I will not go into them here.
Use app audiences, not more workspaces
Here is a common scenario that traditionally drives workspace sprawl, and I touched on it briefly earlier. You start with one finance report, stored in a Finance workspace. All good. Then the execs want a report of their own, but only they should see it, not the finance analysts who use the first report. So a new workspace gets created. Then FP&A, who sit under finance, want their report too, one the analysts and the execs should not see. Another workspace. Then along comes a report they should all see, and you can see where this is going: four workspaces, all under finance, each existing purely to fence off who sees what.
App audiences sort this out as they give you granular control at the app level. One Finance workspace, one Finance app, and each group, the analysts, the execs, FP&A, gets its own audience within that single app. Think of an audience as a folder inside the app: the report every group needs appears in every audience, the restricted ones appear only in theirs, and each report still exists exactly once in the workspace.
This pairs with the other half of the distribution model, a single app as the front door. Rather than scattering shareable links and leaving people to hunt through "Shared with me", you publish one app from the production report workspace and that is the only route end users need. They get a clean, curated experience, they see only what is relevant to them, and they never touch a workspace. Links stop being your distribution strategy, which is a good thing, because links give you no structure and no real way to know who can see what. The detail of sharing options sits in How to Share Power BI Reports and Share Power BI Reports with External Users, so I will not rebuild it here.
One detail that is not obvious until you test it, some senior stakeholder groups usually need to see everything, so the instinct is to add them to every audience. Do that and Power BI surfaces a system-generated "All" tab alongside every audience tab, and any report sitting in multiple audiences appears repeatedly across the navigation. We tested this in our own tenant and the result is a cluttered app that is hard to navigate and harder to explain. The clean answer is a dedicated executive audience containing every report. Senior users sit in that one audience only: a single curated view, no "All" tab, no duplicates.
Sections, groups and org apps
A few smaller decisions round out the framework.
Use Sections to organise the app's navigation. They behave like folders, grouping related reports so people can find what they need rather than scrolling a flat list. Even a modest estate turns into a long, scroll-heavy navigation without them, especially for audiences that can see most of the content.
Grant access through Entra ID (formerly Azure Active Directory) security groups, not individual user accounts. Joiners and leavers become one group-membership change rather than a hunt across workspaces, models and audiences. Access is easier to review and evidence and the same groups can be reused across every layer: workspace roles, semantic model permissions and app audiences. Two caveats worth knowing, a security group applies the same access to every member wherever it is used, so create an additional group when a genuinely different, role-based access pattern exists, not for one-off exceptions. Also, groups built for workspace access and audience membership are not automatically the right groups for row-level security roles; RLS assignment needs its own design, and, like sensitivity labels, sits a layer deeper than the framework covered here.
On org apps, a quick word, because people ask. An org app lets you publish several apps from a single workspace, where the traditional model is one app per workspace, with audiences handling the different groups inside it. Org apps reached general availability in mid 2026, including audience support, so they are no longer the preview feature to watch from a distance that they were a year ago. They bring custom landing pages, theming and richer branding. One difference to understand before adopting them... org apps have no versioned publish step. Changes are visible to consumers the moment you save, where a workspace app holds changes back until you deliberately update it. That deliberate update is a governance control worth keeping. For most estates the workspace app with audiences remains the proven default and there is no deprecation of it on the horizon, but if your use case calls for the extra presentation control, org apps are now a legitimate option rather than a gamble. I am personally in process of writing more on Org Apps.
How Metis BI helps
Designing this structure or untangling an estate that designed itself, is a lot of what we do. We help organisations set up a framework that fits their team and scales, separate models from reports properly, and replace shareable-link chaos with a clean app and audience model, then carry that thinking through into how reports actually get built on top. It tends to help two kinds of organisation: those setting up Power BI properly for the first time who want the structure right, and those whose estate has already sprawled and needs bringing back under control. If that is you, our Power BI and Microsoft Fabric governance assessment is a good place to start.
A framework is not bureaucracy, it is the difference between an estate you control and one that controls you. Separate your models from your reports, shape your workspaces around your team, add only the environments you need, and let one app and its audiences handle who sees what. Do that and the estate grows with the business. Skip it, and it will design itself, one stray workspace and one shared link at a time.
Frequently asked questions
What is the difference between a Power BI workspace and an app?
A workspace is the working environment where content is built and managed, controlled through roles. An app is the packaged, consumer-facing version of that content, published for people who only consume. Developers work and test in workspaces; everyone else opens the app and should never need access to one.
Should I create one workspace per report?
Almost never. It feels tidy at first but leaves you with dozens of near-empty workspaces, no way to see the estate as a whole, and an app each to maintain. Group content by type and environment, or by team where teams genuinely build independently.
Do I need separate DEV, UAT and PROD workspaces?
In most cases UAT and PROD are enough. A DEV workspace tends to earn its place when multiple developers work on the same content concurrently or when pipelines and automated testing are in play. For smaller teams, development usually happens locally in Power BI Desktop. The point made in this blog is not to force a DEV environment for the sake of following best practice, think about your organisation, your team and your data, and add environments when they earn their place.
Do I need to update the app every time the data refreshes?
No. Data flows through on the semantic model's refresh schedule regardless of the app. You only update the app when you want structural or visual changes, new reports, changed visuals, added pages, to reach end users.
Why can users see the app but not the reports inside it?
Almost always because they are missing Read permission on the semantic model. When models and reports live in separate workspaces, audience membership alone is not enough; consumers also need Read on the model the reports connect to.
Everything in this blog comes from the same place: our proven Power BI and Microsoft Fabric governance approach, which we have refined across client engagements over the years and consistently get great feedback on. If you want this framework designed for your estate rather than worked out by trial and error, that is where to start.
This blog is one of a series I have built from my Leeds Power BI User Group talk on Power BI governance. For the wider argument, start with Power BI Governance: The Foundations Matter More Than Ever, the overview of the talk, and it sits alongside the previous blog in the series, Trust, Security and Classification: Where Power BI Trust Is Built or Lost.
.png)
.png)
.avif)