Power BI Governance - What Actually Works in Australian Organisations

Governance is the word that makes Power BI projects either succeed or quietly rot. I've sat in plenty of meetings where someone holds up the Microsoft Fabric adoption roadmap and says "we should do this". And then six months later the same organisation has 800 workspaces, nobody knows which report is the canonical one, and finance is exporting everything to Excel because they don't trust the dashboard anymore. The roadmap isn't wrong. It's just that following it requires a level of organisational maturity most teams don't have when they start.

This post is about what works in practice when you're trying to put governance around Power BI and Fabric in an Australian organisation. The Microsoft documentation on this is genuinely good (link at the bottom), but it's written for an ideal world. Most of the clients we work with are not in an ideal world.

What governance actually means here

Governance isn't a folder structure or a naming convention. Those are artefacts. Governance is the set of rules, roles, and decisions about who gets to do what with data, who is accountable when something breaks, and how decisions get made when there's disagreement.

In Power BI specifically, that means deciding:

• Who can publish to production
• Who can share content externally
• Who decides what counts as a "certified" dataset
• What happens when two teams build different reports that contradict each other
• How sensitive data gets labelled and protected
• Who pays for the capacity

That last one matters more than people admit. I've seen governance arguments that were really about who was footing the bill for a Premium capacity, dressed up as concerns about data quality.

The roles that matter

The Microsoft documentation talks about an executive sponsor, a Power BI champion network, a centre of excellence, and various working groups. In a big bank or a Federal department, all of these exist. In a 400-person manufacturing business in the Hunter, you've got one IT manager who also does the website, and a finance analyst who happens to know DAX. Both versions need governance.

What I've found works at the small to mid end is to pick three roles and make them clear:

An owner. One person, usually in IT or a data team, who is the buck-stops-here for the Power BI tenant. They own the licensing, the capacity, the tenant settings. They don't have to build reports. They have to care that the thing works.

A small group of trusted publishers. These are the people who can publish content to certified workspaces. Not everyone with a Pro licence. A small number, maybe three to ten, who have been trained, who understand what "certified" means, and who agree to follow the standards.

A wider community of self-service builders. Everyone else who wants to use Power BI. They can build, they can share within their own team workspaces, but they can't promote to enterprise level without going through a publisher.

This is a simpler version of what Microsoft describes, and it scales reasonably well. It also matches what we see succeed across the organisations we work with on Power BI.

Policy without paperwork

The instinct in a lot of organisations is to write a forty-page Power BI governance policy. It will get printed once, filed, and ignored. Don't do that.

What works better is a short set of rules, ideally one or two pages, that covers:

1. What workspaces exist and what each is for
2. Who can publish to each
3. How content gets certified
4. What datasets are the single source of truth
5. How sensitivity labels are applied
6. What's allowed and not allowed in terms of external sharing
7. How the capacity is monitored and what happens if it's overloaded

If your governance document is longer than that, nobody reads it. If it's shorter than that, you've missed something important.

The other thing to write down, separately, is a list of certified datasets and who owns each. This is the artefact people actually use. A new analyst joins the team, you point them at the list. "These are the datasets you should be building from. If what you need isn't here, talk to me."

Sensitivity labels are not optional anymore

If your organisation handles anything covered by the Privacy Act, the Notifiable Data Breaches scheme, or APRA's CPS 234, you need to be applying sensitivity labels to Power BI content. This isn't a nice-to-have. It's the baseline.

Microsoft Information Protection labels (Public, General, Confidential, Highly Confidential, and variants) flow through from your Microsoft 365 tenant into Power BI. When applied properly, they restrict what can be downloaded, what can be exported, who can share. They also stick to exports - so if someone exports a labelled dataset to Excel and emails it, the label travels with it.

Setting this up is fiddly. You have to:

• Enable sensitivity labels in the tenant
• Configure label policies in Microsoft Purview
• Decide which labels apply to which content
• Train your publishers to apply them

The bit that trips people up is the training. Labels are useless if nobody applies them. We usually recommend making "label applied" a hard requirement for any dataset to be certified. No label, no certification.

The capacity question

If you've moved to Fabric or you're running Premium, you've got a shared resource that costs real money. F64 starts around the price of a decent sedan per year. F256 is into hundreds of thousands of dollars territory. Governance around capacity is what stops someone from accidentally torching it.

The things that hurt capacity most:

• Big DirectQuery queries from people who don't understand DirectQuery
• Refreshes scheduled to all run at 7am
• Datasets that try to import a billion-row table
• Notebooks running on premium pool without budget controls

You can monitor all of this in the Fabric Capacity Metrics app. The trick is having someone whose job it is to actually look at the app. Otherwise the alerts get ignored and the next thing you know there's an incident report being written.

For Microsoft Fabric specifically, the workload allocation question is the one that bites people. By default a Fabric capacity runs everything - Power BI, Notebooks, Data Engineering, Real-Time Analytics, Warehouse. If you don't tune this, a heavy data engineering workload at 2am will smear over into Power BI refreshes at 4am and your dashboards will be stale.

What I'd skip from the official roadmap

The Microsoft adoption roadmap is comprehensive. It's also written for organisations with the appetite to spend twelve months on adoption. A few bits I'd treat as optional in the Australian mid-market:

The formal Centre of Excellence. Useful at scale, theatre at small to mid scale. A WhatsApp group of your three best Power BI builders is a centre of excellence. You don't need a charter and a steering committee.

The maturity assessment. It's a useful exercise once. Doing it annually as a formal process consumes more time than it generates value. Just keep an eye on whether things are improving or getting worse.

The full champion network programme. Champions are great. The programme around them, less so. If you have natural enthusiasts, give them time, give them a budget for training, get out of their way.

What I'd add that isn't in the roadmap

A few things we've found matter more than the documentation suggests:

A break-glass plan for when production breaks. Who's on call? How do you roll back a broken dataset? What's the comms plan when finance can't run their EOM report? Most organisations don't have this written down. They should.

A regular cull. Workspaces accumulate. Reports accumulate. Datasets accumulate. Once a quarter, run a query against the activity logs and identify anything that hasn't been viewed in six months. Have a conversation with the owner. Archive or delete. The signal-to-noise ratio in your tenant is half of governance.

Procurement clarity. Who buys Pro licences and PPU licences? How does someone get one? Is it self-serve or does it need approval? This is mundane and it's where governance falls apart in practice.

Where to start if you're starting now

If you're a few months into Power BI and you're realising you've got a mess on your hands, here's the order I'd tackle things:

1. Inventory what you have. Workspaces, datasets, reports, who owns what.
2. Identify the three to five datasets that are actually load-bearing for the business.
3. Get those certified, labelled, and properly owned.
4. Write the one-pager that says what good looks like.
5. Set up monitoring on the capacity.
6. Then, and only then, worry about the rest.

If you try to fix everything at once you'll fix nothing. If you fix the load-bearing things first, the rest can be tidied up over six to twelve months.

We've helped a lot of Australian organisations through this exact journey. If you'd like to talk about where your Power BI tenant sits and what to do about it, get in touch. And if you're earlier in the journey and trying to figure out what to even ask for, the strategy work is the place to start.

For the full Microsoft view on Power BI governance and the Fabric adoption roadmap, the documentation is here: Microsoft Fabric adoption roadmap - Governance. It's worth a read even if you only end up implementing a fraction of it.