Power BI Tenant Administration - The Unglamorous Work That Keeps Analytics Sane

Nobody gets into analytics because they love administering a tenant. People get into it because they want to turn a mess of data into something a manager can act on. But here is the uncomfortable truth I have watched land on team after team: the difference between a Power BI deployment that stays healthy and one that turns into a swamp is almost entirely tenant administration. The reports are the visible bit. The administration is the plumbing, and when the plumbing is bad, everything above it eventually smells.

I have walked into organisations where Power BI had spread for three years with essentially nobody at the wheel. Thousands of workspaces, half of them abandoned. Sensitive financial reports shared to "the whole organisation" because someone found that easier than picking the right group. No idea who the actual owners were. Nobody could answer the basic question of what data was flowing where. None of that was a tooling problem. Power BI gives you the controls. What was missing was somebody deciding to use them, which is what tenant administration actually is.

What tenant administration covers

Tenant administration is the layer where you set the rules for the entire Power BI, and now Fabric, environment across your organisation. It is done mostly through the admin portal and the tenant settings within it, and it governs the things that apply above any individual workspace or report.

Microsoft's tenant administration guidance breaks this into the areas that matter, and in practice the ones you spend real time on are these: the tenant settings that switch capabilities on and off, the admin roles that decide who can do this configuration, the monitoring and auditing that tell you what is actually happening, and the lifecycle habits that stop the environment rotting. Let me go through the ones that earn their keep.

Tenant settings are where the real decisions live

The tenant settings page is a long list of toggles, and most people either leave it all at default or lock it all down, and both are mistakes. The default settings are Microsoft's opinion for a generic organisation, not yours. Locking everything down kills the self-service value that made you buy Power BI in the first place. The skill is in the middle.

Two settings deserve particular attention because they cause the most trouble when handled badly.

Publish to web. This one lets a user publish a report to a public URL that anyone on the internet can view, with no authentication whatsoever. It is a genuinely useful feature for public data, and it is also the single most common way sensitive corporate data ends up exposed by accident. My strong opinion: turn this off for your whole organisation, and if a genuine public-data use case appears, enable it for a specific, named security group that understands exactly what it means. I have seen a company discover that quarterly numbers were sitting on a public link because someone used publish-to-web to "quickly share" with a colleague. Do not let that be you.

Export and sharing controls. Power BI has a family of settings governing whether users can export to Excel, export underlying data, share externally, and print. The instinct in a regulated business is to switch it all off. Resist that instinct slightly. If you make Power BI so restrictive that people cannot get their numbers into Excel, they will simply pull the data another way, often a worse and less governed way. Scope these controls to the groups where the risk is real rather than blanketing everyone. Governance that pushes people towards shadow workarounds is worse than looser governance they actually follow.

The broader principle is that most tenant settings support scoping to specific security groups rather than a blunt on-or-off for everyone. Use that. The organisations with the healthiest deployments are the ones that granted capabilities deliberately to the groups that needed them, rather than choosing between anarchy and a lockdown. This is a lot of what our Power BI consultants do in the first few weeks of an engagement, because a well-scoped tenant settings baseline prevents most of the fires you would otherwise be fighting later.

Roles, and the danger of too many admins

The Power BI, or Fabric, administrator role is powerful. It can see and change tenant-wide settings, access workspaces, and read audit data. Because it is powerful, the temptation in a busy organisation is to hand it out generously so nobody is ever blocked. That is a mistake.

Keep the number of full tenant administrators small and known. Every person with that role is someone who can change a setting that affects the entire organisation, and the more of them there are, the harder it is to know who changed what and why. Microsoft has added more granular roles over time, including ways to delegate specific administrative capabilities without granting the full crown, and you should use those where they fit. Give someone exactly the access their job needs and no more. This is not distrust. It is that a small, clear set of administrators is auditable, and a sprawling one is not.

While we are here, separate the roles in your head. The person who administers the tenant is not necessarily the person who owns data governance policy, who is not necessarily the person building reports. In small shops these collapse into one overworked human, which is understandable but fragile. As you grow, pull them apart so that tenant administration is a defined responsibility somebody owns, not a thing that happens to whoever logs into the admin portal that week.

Monitoring is how you find out the truth

You cannot administer what you cannot see. Power BI gives you an activity log and an admin API surface that together let you answer the questions that matter: which reports are actually used, which workspaces are abandoned, who is sharing what, where the sensitive content lives, and how capacity is being consumed.

My honest experience is that almost nobody uses this until something forces them to, and by then they are doing archaeology instead of administration. Set up monitoring early. Pull the activity data into a workspace and build a simple admin dashboard on top of it, ironically using Power BI to watch Power BI. Once you can see usage, a lot of decisions get easy. That workspace nobody has opened in eight months? Archive it. That report being hammered daily by two hundred people? That is a candidate for proper support and a certified dataset. Without the data you are guessing, and guessing at scale is how tenants rot.

The monitoring also matters for capacity, especially now that Fabric has folded Power BI into a broader capacity model. Watching consumption tells you whether you are about to hit a wall, and gives you the evidence to right-size rather than reflexively buying more. Numbers beat opinions in that conversation every time.

Lifecycle, or how to stop the swamp forming

The reason so many Power BI tenants turn into swamps is that creation is easy and cleanup is nobody's job. Anyone can make a workspace, publish a report, build a dataset. Almost nobody ever removes anything. Multiply that over three years and you get the sprawl I described at the top.

Tenant administration is where you fight this, and the weapons are unglamorous but effective. Decide who can create workspaces, because "everyone" is rarely the right answer once you are past the early days. Establish naming and ownership so that every workspace has a human accountable for it, not an orphan nobody will admit to. Use the monitoring data to identify and retire dead content on a regular rhythm rather than never. And certify the datasets and reports that people should trust, so that in a sea of duplicates there is a clear signal about which version is the real one.

None of this is exciting, and all of it compounds. An organisation that spends a little effort on lifecycle every month has a tenant people can navigate. One that never does ends up with a governance project two years from now that costs ten times as much as the habit would have.

The bottom line

Power BI tenant administration is the least glamorous part of an analytics practice and one of the most important. The tenant settings decide what is possible, the admin roles decide who holds the levers, the monitoring tells you what is really going on, and the lifecycle habits stop the whole thing rotting. Get those four right and self-service analytics stays a genuine asset. Get them wrong and you get sprawl, exposure, and a mess that somebody eventually pays a consultant a lot of money to untangle.

If your Power BI, or Fabric, environment has grown past the point where anyone is confidently in control of it, that is a very normal place to be and a very good time to fix it. We help organisations get their tenant governance in order through our Microsoft Fabric consultants and Power BI practice, and if you want a frank assessment of where your deployment stands right now, get in touch. It is a lot cheaper to tidy the plumbing on purpose than to wait for it to burst.