Managed Self-Service BI in Power BI - The Model That Actually Scales

Most Australian organisations we work with land in one of two ditches with Power BI. In the first, a small central BI team builds every report, has a twelve-week backlog, and the business quietly goes back to Excel. In the second, everyone has a Pro licence, everyone builds their own model, and three months later finance has four versions of "revenue" that don't agree and nobody can explain why.

Managed self-service BI is the road between those two ditches. It's one of the usage scenarios Microsoft describes in its Power BI implementation planning guidance, and honestly, it's the one I recommend to more clients than any other. The idea is simple. A central team (or a skilled data person in each domain) owns and publishes the shared semantic models. Business users then build their own reports on top of those models. Data is managed centrally. Reporting is self-service.

It sounds obvious written down like that. Getting it working is a different story, so here's what we've learned doing it.

What managed self-service BI actually means

Microsoft's guidance splits the work into two layers:

• The data layer. Semantic models (what we used to call datasets) built and maintained by people who understand data modelling, DAX, refresh, and security. These models are published once and reused many times.
• The reporting layer. Reports, dashboards and Excel workbooks built by business users who connect to those shared models. They don't import their own copies of the data. They don't write the core measures. They drag fields onto a canvas and answer their own questions.

The technical piece that makes this work is the live connection. When a report author in Power BI Desktop connects to a published semantic model, they get the tables, relationships and measures, but the data stays in the model. Their report file is basically just visuals. Same deal when someone uses Analyze in Excel or builds a report directly in the service from an existing model.

Users need Build permission on the semantic model to do this. That one permission is a big lever, and I'll come back to it.

Microsoft also recommends separating workspaces: one (or more) workspaces for semantic models, and separate workspaces for reports. That separation is the thing most organisations skip, and it's the thing that causes the most pain later.

Why we like this pattern so much

The core benefit is that you get one definition of each important number. If "gross margin" is defined in the shared model, every report that uses it gets the same answer. When the CFO asks why the sales dashboard and the operations dashboard disagree, the answer isn't "they built different models", it's "they filtered differently", which is a much easier conversation.

The second benefit is speed for the business. Once a decent model exists, a sales manager can build a new view of their pipeline in an afternoon without filing a ticket. That's the bit that makes people actually adopt Power BI instead of tolerating it.

The third benefit gets less attention: maintenance. One model with one refresh schedule and one set of row-level security rules is far easier to look after than forty personal models each hitting the source system at 6am. We've seen clients cut their gateway load and refresh failures dramatically just by consolidating duplicate models into a few shared ones.

What goes wrong in practice

Here's where I'll be honest. The pattern is sound. The execution is where organisations struggle.

The models aren't good enough to self-serve from

If your shared semantic model has cryptic column names like CUST_ACCT_NBR_2, no descriptions, fifty hidden-but-not-really tables, and measures named Measure 14, business users will not self-serve. They'll look at it, get confused, and export to Excel.

A model built for self-service is a product, not a technical artefact. Friendly names. Display folders. Descriptions on measures. Hidden technical columns. A date table that works. We usually spend as much time on this "usability layer" as on the actual modelling, and clients are often surprised by that. They shouldn't be. It's the difference between a model people use and one they avoid.

Build permission gets handed out carelessly

Build permission lets someone create new content from a model. It also lets them query the model in ways you didn't anticipate, including through Excel and external tools. If row-level security is set up properly that's fine. If it isn't, you may have just given a lot of people a very flexible window into data they shouldn't see.

My rule of thumb: get RLS right before you widen Build permission, not after. And manage Build permission through security groups, not individual users, or you'll be untangling it in two years.

Everything ends up in one workspace

When semantic models and reports live in the same workspace, everyone who needs to publish a report needs a workspace role that also lets them mess with the models. Contributor on a workspace means you can overwrite the model. We've seen a well-meaning analyst republish a shared model from an old Desktop file and wipe out a week of changes from the data team. (This, incidentally, is where semantic model version history can save you, but better not to need it.)

Separate workspaces fix this cleanly. The data team has full control of the model workspace. Report authors get Build permission on the models and their own workspaces for reports.

Nobody knows which model to use

Once you have a dozen shared models, discoverability becomes a problem. This is what endorsement is for. Promote models that are ready for use. Certify the ones that have been properly reviewed and are owned by someone accountable. Then tell people, loudly and repeatedly, to start with certified content. The OneLake catalog in Fabric makes this easier than it used to be, but a catalogue only helps if the endorsement labels mean something.

We've had clients certify everything to look tidy. Don't. If certification doesn't mean anything, people learn to ignore it.

When business users need more than the shared model offers

This is the most common pushback we get: "The shared model is great, but I need to add my own targets spreadsheet." Fair enough.

You have a few options. First, ask whether it belongs in the shared model. If three teams need targets, the data team should add them properly. Second, Power BI supports composite models that combine a live shared model with additional local data (Microsoft calls this customisable managed self-service BI, and it's a separate usage scenario in the same guidance). It works, but it adds complexity, performance can suffer, and you now have a chunk of logic sitting outside the governed model. I treat it as a pressure-release valve rather than the default path.

The worst option is the one people take when nobody answers them: export everything to Excel, build a new import model from scratch, and publish it to a personal workspace. That's how you end up back in ditch number two.

The people side

Managed self-service BI is as much an operating model as a technical one. A few things we've seen make the difference:

Name an owner for every shared model. A real person, not "the BI team". When the numbers look wrong, someone needs to pick up the phone.

Run a short training for report authors. Not general Power BI training. Specifically: how to find certified models, how to connect live, what Build permission means, and when to ask for a change to the model versus building a workaround. Two hours is enough to start.

Have a request process for model changes. Business users will find gaps. If the only way to get a new measure added takes six weeks, they'll build around you. A lightweight request channel (a Teams channel with a weekly triage works fine) keeps people inside the managed model.

Watch the activity data. The Power BI activity log tells you who's building what and against which models. If you see lots of new import models appearing in personal workspaces, that's a signal the shared models aren't meeting a need.

Is it right for you?

If you've got more than a handful of people building reports and any shared definitions that matter (revenue, headcount, margin, inventory), I'd say yes. It's the pattern we default to for mid-sized and enterprise clients.

It's probably overkill if you're a 30-person business with one person doing all the reporting. In that case, the "central team" and the "business user" are the same human, and the separation is mostly ceremony.

And if your data is genuinely messy at the source, managed self-service BI won't fix that. You'll need some data engineering upstream first, which is where tools like Microsoft Fabric and a proper lakehouse come in.

Getting started

If you're moving towards this model, the order we usually recommend is:

1. Pick one high-value subject area (sales is common) and build one really good shared semantic model.
2. Put it in its own workspace, set up RLS, and certify it.
3. Give Build permission to a small group of report authors via a security group.
4. Train them, watch what they build, and fix the model gaps they find.
5. Then do the next subject area.

Resist the urge to do everything at once. One great model that people actually use beats ten average ones.

If you'd like help setting this up, our Power BI consultants do this kind of work regularly, and if your organisation is also looking at the broader Fabric platform, our Microsoft Fabric consultants can help with the data layer underneath. We also look at where AI fits on top of good BI through our AI for business intelligence work. Copilot in Power BI, for what it's worth, works far better against a clean, well-described shared model than against a pile of personal ones.

Reference: Power BI usage scenarios - Managed self-service BI (Microsoft Learn)