Managing Semantic Model Access in Power BI - Auditing and Revoking the Preview Feature

Every Power BI cleanup job we get called into has the same moment. We open a semantic model that the whole business runs on, click into who has access, and there's a list of names that nobody in the room can fully explain. Contractors who left a year ago. A person from a team that got restructured out of existence. Three service accounts, two of which someone thinks might be important. Granting access is the easy, fun part that happens on day one. Managing it afterwards is the boring, ongoing part that almost nobody does, and it's exactly where governance quietly falls apart.

The manage semantic model access page, currently in preview, is Microsoft giving you a proper place to do that second part. Not the initial grant, but the day-two-onwards work of seeing who has access to a model, what they can do with it, and pulling that access when it's no longer needed. It's less exciting than the sharing feature it sits next to, and honestly more important.

Why this is the half that gets skipped

Access grants are easy to give and easy to forget. Someone asks for build access to the Sales model so they can put together a report, you grant it in ten seconds, and that grant sits there forever. Nobody sends a follow-up when the report is finished. Nobody removes it when the person moves teams. Permissions only ever accumulate. In a healthy organisation the list of people who can touch a critical model should shrink about as often as it grows, and in practice it basically never shrinks, because taking access away requires someone to notice it, question it, and act. All three of those cost effort and none of them have a deadline.

So you get sprawl. A model that genuinely needs to be reachable by eight people ends up shared with thirty. Most of those extra twenty-two never do anything harmful. But every one of them is a name a security review has to account for, a potential path if an account gets compromised, and a small piece of the reason nobody feels confident changing anything about that model. The cost of unmanaged access isn't usually a dramatic breach. It's a slow loss of confidence in your own environment.

The manage access page gives you the one thing that makes cleanup possible: a clear, single view of the current state. Who has access to this model, at what permission level, and the ability to change or remove it from that same screen. That sounds basic because it is basic. But you can't clean up what you can't see, and until you have a decent view of the access list, the honest answer to "who can build on our finance model" is a shrug.

What the preview actually gives you

At its core the page lists the people and groups that have been granted access to a semantic model, shows their permission level, and lets you adjust or revoke it. Read, build, reshare - the three levels that matter for the shared-model pattern - are all visible here rather than scattered.

The permission level column is the one to actually read rather than skim. Read means someone can consume content connected to the model. Build is the meaningful one, because build lets a person create new reports and connected Excel workbooks against your model, effectively querying whatever the model exposes. Reshare lets them pass access onward to other people. When we audit an environment, build and reshare are where we spend our attention. A long list of read-only viewers is usually fine. A long list of people with build access on a model carrying sensitive data, half of whom nobody can account for, is the actual problem.

Being able to fix it from the same screen matters more than it sounds. The friction in access cleanup has always been that seeing the problem and fixing the problem happened in different places, or the fix was buried three menus deep. Put the view and the revoke button next to each other and cleanup goes from a project to a five-minute task you can actually do on a Friday afternoon.

This is the kind of tidy-up work our Power BI consultants end up doing on nearly every engagement where a client has had self-service BI running for a couple of years without much governance behind it. The models are usually fine. The access lists are the mess.

The honest caveats

Two things to keep in mind, and neither is a reason to avoid the feature.

First, it's preview. The layout and the exact behaviour can shift before general availability, so I wouldn't write a rigid, screenshot-by-screenshot internal runbook around it just yet and expect every step to survive. For actually doing cleanups and reviews right now, it's perfectly usable. For a documented compliance process that has to be identical every quarter, I'd wait for GA or at least keep the process described loosely enough that a UI change doesn't break it.

Second, and this is the bigger one: a management page makes reviewing access easier, but it doesn't make anyone do it. The tool is not the habit. If nobody owns the job of periodically opening this page and asking "does this person still need this", the sprawl comes back regardless of how nice the interface is. The technology removes the excuse of "it was too hard to see"; it can't remove the excuse of "nobody's job".

Which leads to the advice we give every client. Do your access management through security groups, not individuals, and this whole problem shrinks by an order of magnitude. If the Sales model is shared with a "Sales Analysts" group instead of fourteen named people, the manage access page shows you one clean entry instead of fourteen, and access follows people in and out of the team automatically as their group membership changes. You still use the manage page, but now it's showing you a short list of groups you can reason about rather than a long list of names you can't. Direct per-person grants are what create the mess this page exists to clean up. Use the page to fix the sprawl you already have, then switch to group-based access so it doesn't come back.

How I'd use it in practice

Run an audit first. Open the manage access page on your most important models - the certified ones, the ones with financial or customer data - and just read the list properly. For every name with build or reshare, ask whether that access is still doing a job. You will find things. Everyone does. The first pass on a neglected model is always the one that surfaces the departed contractor and the mystery service account.

Then set a cadence. Access review is one of those tasks that only works if it's scheduled, because it never becomes urgent on its own. Quarterly is a reasonable default for important models. Put it on someone's calendar, give them the manage access page as the tool, and make "confirm each grant still has a reason" the actual task. Fifteen minutes a quarter per critical model is nothing against the cost of an access list nobody trusts.

Pair it with row-level security where the data needs it. Build access lets someone query the model, so if different people are supposed to see different slices of the data, that separation has to live in row-level security inside the model, not in who you did or didn't share with. Reviewing access and reviewing RLS go together. It's worth checking both in the same sitting.

The broader point is that Power BI governance isn't a one-time setup you configure and forget. It's a small, boring, recurring habit, and the tooling around it is finally getting good enough that the habit is cheap to keep. A management page like this doesn't govern anything on its own, but it removes the friction that was the usual excuse for not bothering. Getting the models, the access strategy and the ongoing review working together is the real job, and it's the sort of thing we sort out through our business intelligence practice and our managed services when a client wants someone to actually own it rather than let it drift again. If your Power BI environment has quietly grown into a pile of access lists nobody wants to look at, have a chat with us. Cleaning them up is oddly satisfying work.