Power BI Tenant Setup - Getting the Foundations Right Before Anyone Builds a Report

The most expensive Power BI mistakes I see are not bad reports. They are decisions made in the first week, before anyone had built anything, that quietly locked an organisation into a shape it later had to fight against for years. Tenant setup is that first week. It is the least visible part of a Power BI rollout and the part that determines how much pain everything after it will cause.

Here is the pattern that plays out again and again. A team gets a bit of budget, someone signs up for Power BI, a handful of people start publishing reports, and it works. It genuinely works. So more people join, more reports appear, and eighteen months later you have a tenant where nobody can tell you who owns what, sensitive data is scattered across workspaces named "test" and "test2", and the licensing bill has crept up in a way nobody can explain. None of that was a tooling failure. It was the absence of a proper setup at the start.

So this is the guide I wish more organisations read before they got going. Microsoft's own tenant setup guidance is the reference, and I want to put the consulting experience on top of it, because the docs tell you what the settings are and not which ones will bite you.

Start with who is actually going to use this

Before you touch a single setting, you need an honest answer to a question most organisations skip: who is going to use Power BI, and how. Not the aspirational answer where everyone is a data-driven decision maker. The real one.

In practice you have three groups, and they need different things. You have a small number of people who build reports and models, the ones who live in Power BI Desktop. You have a larger group who consume reports, open a dashboard, look at a number, get on with their day. And you have a middle group who do a bit of both, the analysts who slice and filter and occasionally build something themselves. The mix of those three groups drives almost every setup decision that follows, from licensing to how you structure workspaces.

I have watched organisations set up a tenant as if everyone would be a builder, then discover that ninety percent of their users just wanted to view a weekly sales report. The result was over-provisioned licences and a security model far more complicated than the actual usage justified. Map your users first. It takes an afternoon and it saves you from designing for a fantasy.

Licensing is a decision, not a default

Power BI licensing has three broad shapes and getting this wrong is a direct hit to the budget. There is Pro, which is per user and fine for smaller teams where most people build and share. There is Premium Per User, which gives individuals the bigger capabilities without buying a whole capacity. And there is capacity-based licensing, now folded into the Fabric model, where you buy a pool of compute and viewers can consume content on a free licence.

The rough rule I give clients is about the ratio of viewers to builders. If you have a lot of people who only ever look at reports, capacity-based licensing usually works out cheaper because those viewers do not each need a paid seat. If you are a smaller shop where most people are hands-on, per-user Pro is simpler and you are not paying for capacity you cannot fill. There is a crossover point, and it moves as Microsoft repackages things, so the honest advice is to model it against your actual user mix rather than picking the option that looked good in a webinar.

The bit people get wrong is treating this as a one-off. Your user mix changes. A rollout that started with twenty analysts on Pro and grew into two thousand viewers is paying the wrong way, and nobody notices until someone looks. Revisit the licensing shape once a year against real usage. This is a lot of what our Power BI consultants do early in an engagement, because the licensing decision quietly sets a ceiling on everything else.

Workspaces are your org chart, so design them on purpose

A workspace is the container where content lives, and how you organise workspaces is the single most consequential structural decision in your tenant. Get it right and people can find things, permissions make sense, and content has a clear owner. Get it wrong and you end up with the swamp.

The instinct is to let workspaces grow organically, one per person or one per whim. Resist that. Design a workspace structure that maps to how your organisation actually works, usually by business function or by team, with a clear separation between development, test and production content for anything that matters. A finance workspace, a sales workspace, an operations workspace, each with a named owner who is accountable for what lives inside it.

The separation between development and production is the one people skip and regret. When your report-building and your live, business-critical reports share the same workspace, someone editing a measure at 4pm can break the number the leadership team looks at every morning. Keep the place people experiment separate from the place people trust. It is not complicated, it just requires deciding to do it before the content exists rather than untangling it after.

Security and sharing settings deserve real thought

The tenant settings around security and sharing are where good intentions meet reality. Two settings in particular cause most of the trouble.

The first is publish to web, which lets someone put a report on a public URL with no login required. It is genuinely useful for public data and it is also the most common way corporate numbers end up exposed by accident. My firm view is to turn it off across the organisation and enable it only for a specific, named group that understands exactly what it does. I have seen quarterly figures sitting on a public link because someone used it to "quickly share" with a colleague. Do not let that happen on your watch.

The second is external sharing. Power BI can share content with people outside your organisation, which is great for working with clients and partners, and it is also a data-governance question you want to answer deliberately rather than by leaving a default on. Decide who can share externally, scope it to the groups that genuinely need it, and know that it is on rather than discovering it later.

The broader principle across the whole settings page is that most controls can be scoped to security groups rather than flipped on or off for everyone. Use that. The healthiest tenants I see are the ones that granted capabilities to specific groups on purpose, rather than choosing between total lockdown and total anarchy. Lock everything down and people route around you with exports and shadow spreadsheets, which is worse governance than a sensibly loose setup people actually follow. Getting this baseline right is core to our Microsoft Fabric consultants work, because a well-scoped set of settings prevents most of the fires you would otherwise fight later.

Naming and ownership, the boring bit that saves you

Nobody wants to write a naming convention. Everybody wants one two years later when they are staring at forty workspaces called some variant of "reporting" and cannot tell which is real.

Decide, before anyone builds, how workspaces and key reports get named, and make sure every workspace has a human owner attached, not an orphan nobody will claim. This sounds trivial and it is the difference between a tenant you can navigate and one you have to excavate. A workspace named "FIN-Monthly-Reporting-PROD" with a named owner tells you everything. A workspace named "Sarah test" tells you that Sarah left in 2024 and nobody knows if the report inside still matters.

The same goes for datasets and semantic models. When there are five versions of "the sales numbers" floating around, people need a signal about which one is trustworthy. Certify the ones that should be trusted so that in a sea of duplicates there is a clear answer. You cannot bolt this on cleanly once the duplicates exist, so set the habit at the start.

Plan for monitoring before you need it

You cannot administer what you cannot see, and almost nobody sets up monitoring until something forces them to. By then they are doing archaeology instead of administration. Power BI gives you an activity log and admin APIs that answer the questions that matter: which reports are actually used, which workspaces are dead, who is sharing what, where the sensitive content lives.

Set this up early, even in a basic form. Pull the activity data into a workspace and build a simple admin view on top of it, using Power BI to watch Power BI. Once you can see usage, the decisions get easy. The workspace nobody has opened in eight months gets archived. The report two hundred people hammer daily gets proper support and a certified dataset. Without the data you are guessing, and guessing at scale is exactly how tenants rot.

The bottom line

Power BI tenant setup is the unglamorous foundation nobody wants to spend time on and everybody wishes they had. Map your real users before you design anything. Choose licensing against your actual viewer-to-builder mix and revisit it yearly. Structure workspaces to match how the organisation works, with development kept away from production. Scope your security and sharing settings deliberately rather than leaving defaults. Name things and give them owners from day one. And set up monitoring before you are forced to. Get those right and Power BI stays a genuine asset as it grows.

If you are about to roll out Power BI, or you inherited a tenant that has already drifted into a mess, that early foundation work is exactly what we do. Have a look at our services or get in touch and we will give you a frank read on where things stand. It is a great deal cheaper to set the foundations on purpose than to rebuild them under a live deployment later.