Customisable Managed Self-Service BI in Power BI - Letting Analysts Extend Shared Models

Here's a conversation I've had in some form with at least a dozen clients. The central BI team has done the right thing. They've built a clean, certified sales semantic model. Measures are consistent, security works, refresh is reliable. Then a regional manager in Perth says "this is great, but I need to compare it against our local targets spreadsheet, and the targets aren't in the model."

The BI team has three options. Add the Perth targets to the central model (and then Brisbane's, and Adelaide's, and every other team's special data). Tell the manager no, and watch them export to Excel and build their own thing. Or let them extend the shared model themselves, without touching the original.

That third option is what Microsoft calls customisable managed self-service BI. It's one of the usage scenarios in the Power BI implementation planning guidance, and it's the natural next step after managed self-service BI, which we wrote about earlier this month. Microsoft's article is here: Power BI usage scenarios - Customizable managed self-service BI.

I'll be honest up front. I like this scenario a lot, but it's the one most likely to bite you if you turn it on without thinking through who's allowed to do it.

What the scenario actually is

In plain managed self-service BI, business users connect to a shared semantic model and build reports. They can't change the model. They get the measures and tables the central team published, full stop.

In the customisable version, a content creator (usually a capable analyst, not a casual report builder) connects to that shared model and creates a new semantic model on top of it. That new model is a composite model. It uses DirectQuery to reach back into the original shared model, and it can add things the original doesn't have:

• New tables imported from other sources, like that Perth targets spreadsheet
• New measures specific to the team's needs
• New calculated columns or relationships between the shared data and the local data
• Renamed or hidden fields to make things friendlier for their audience

The original model stays untouched. The central team keeps owning the core data and logic. The analyst owns their extension. Reports for the Perth team are then built on the extended model.

Under the hood this relies on DirectQuery for Power BI semantic models (the feature people used to call "composite models on Power BI datasets"). The analyst needs Build permission on the source model, and the tenant settings have to allow DirectQuery connections to Power BI semantic models. If your Power BI admin has those switched off, none of this works, which is sometimes a deliberate choice and sometimes just an oversight.

When it makes sense

We recommend this pattern when a few conditions are true.

The core data really is shared and stable. If your enterprise sales model is solid and certified, extending it is a good idea. If the central model is still changing every fortnight, every extension built on it is going to break, and you'll spend your life fixing other people's composite models.

The local additions are genuinely local. Regional targets, a team-specific product grouping, a mapping table that only marketing cares about. Things that would clutter the central model and that the central team has no business maintaining.

The people doing the extending know what they're doing. This is not a scenario for every Pro licence holder. Building a composite model means understanding relationships, granularity, filter direction and how DAX behaves across a DirectQuery boundary. Someone who's comfortable dragging visuals onto a canvas is not automatically ready for that.

When those three things line up, this pattern is a nice middle ground. The central team stops being a bottleneck for every local request, and you still have one version of revenue.

What goes wrong

This is where I want to spend most of the time, because the Microsoft docs describe the happy path and the problems only show up six months in.

Logic drift

The biggest risk is that the extensions start redefining things that should be central. An analyst adds a measure called "Net Revenue" in their extended model because the central one "doesn't quite work for us." Now you have two Net Revenue measures, they return different numbers, and both reports look official.

We had a client in the professional services space where three different practice groups each added their own utilisation measure in extended models. Same name, three different calculations, three slightly different answers at the partner meeting. Nobody had done anything wrong individually. Collectively it was a mess.

The fix is mostly cultural, with a bit of process. Agree what counts as a "core" measure that must only live in the central model. When an analyst needs something that looks core, it goes back to the central team as a request. Extensions are for local data and local logic, not for disagreeing with the central definitions.

Performance

Composite models are clever, but they're not free. When a report queries the extended model, some of the work happens locally and some gets pushed to the remote shared model. If the analyst builds a relationship between a large table in the shared model and a local table, or writes a measure that iterates across the DirectQuery boundary, queries can get slow quickly.

In practice, a report that ran in a second against the original model can take ten seconds or more against a poorly designed extension. Users blame Power BI. The real cause is usually a relationship on a high-cardinality column crossing the boundary.

Our rule of thumb: keep the local tables small, relate them on low-cardinality keys (region, product category, month), and check query plans in Performance Analyzer or DAX Studio before publishing anything to a wide audience.

Chaining

You can build an extended model on top of another extended model. Power BI limits how deep that chain goes, but even within the limit, chaining is usually a bad idea. Every link adds latency, makes lineage harder to follow, and multiplies the blast radius when something upstream changes. I've yet to see a chain of three models in a client environment that I thought was a good decision. Keep it to one level of extension where you can.

Security assumptions

Row-level security on the source model is respected when the extended model queries it, because the query runs against the source as the end user. That's good. But data the analyst imports into their extension isn't covered by the source model's RLS. If the local data is sensitive, the analyst has to secure it themselves in their model, and they often don't think about it.

Also worth knowing: anyone using the extended model needs appropriate permissions on the source model too. That catches people out when they share an extended report and recipients see errors instead of numbers.

Refresh dependencies

The extended model's imported tables have their own refresh schedule. If the local spreadsheet lives in someone's OneDrive and they leave the organisation, refresh fails and the report quietly goes stale. Boring, but it happens constantly. Put local source files somewhere owned by a team, not a person.

How we set it up with clients

When a client wants to enable this scenario, here's roughly what we put in place.

Decide who can do it. We usually limit DirectQuery to semantic models to a security group of trained content creators rather than the whole tenant. Most organisations don't need everyone building composite models.

Separate workspaces. The central shared models live in workspaces owned by the BI team. Extended models live in team or departmental workspaces. That makes ownership obvious and keeps the central workspace clean.

Endorse the central models, not the extensions. Certify the shared model. Extensions can be promoted by their owners if they're widely used, but they shouldn't carry the same certification badge as the central model. Users need a visible signal of what's official.

Use lineage view. The lineage view in the Power BI service shows you which extended models depend on which shared models. Before the central team changes anything, they check it. Renaming a column in the central model without checking lineage is how you break fifteen reports on a Thursday afternoon.

A light review step. Not a heavyweight approval board, just a quick review by someone from the central team before an extended model gets shared beyond a small group. Ten minutes looking at the model diagram and measure list catches most of the logic drift problems.

A path back to the centre. If three different teams all add the same mapping table to their extensions, that's a sign it belongs in the central model. We encourage clients to review extensions quarterly and promote common patterns upward. Done well, the extensions become a sort of requirements pipeline for the central team.

Is it worth it?

For mid-sized and larger organisations with a functioning central BI team, yes. It takes a lot of pressure off the BI backlog and keeps analysts working inside the governed environment instead of drifting back to spreadsheets. When it works, the central team focuses on the data that really is shared and analysts get to move quickly on everything else.

For smaller organisations, or anyone whose central models aren't stable yet, I'd hold off. Get managed self-service working well first. Customisation on top of shaky foundations just spreads the shakiness around.

And for anyone tempted to switch it on tenant-wide because it sounds flexible, please don't. Start with a small group, see how they use it, then widen access once you've seen what the extensions actually look like.

Getting help

If you're working out how much flexibility to give analysts in Power BI, or you've already got a tangle of composite models and want to sort it out, our Power BI consultants do a lot of this work with Australian organisations. We also help with the wider reporting and analytics side through our AI for business intelligence work, especially where teams want Copilot and AI features sitting on top of well-governed models. Happy to have a chat if it's useful, just get in touch.