Power BI Team BI - How Small Teams Should Share Reports Without Making a Mess

Most Power BI rollouts we see in Australian organisations don't start with a centre of excellence and a governance framework. They start with one analyst in finance who builds a really useful report, shares it with three colleagues, and then a few months later there are eight people editing things in the same workspace and nobody is sure which version of the margin report is the real one.

That middle stage, where a handful of people are working together on reports for their own team, is what Microsoft calls the team BI usage scenario. It's one of the usage scenarios in their Power BI implementation planning guidance, and I think it's the most underrated one. Personal BI is easy. Enterprise BI gets all the attention and budget. Team BI is where most of the actual reporting work in a mid-sized business happens, and it's where a lot of the bad habits get locked in.

What team BI actually means

The scenario is pretty simple. A small group of people, usually in the same department, collaborate on Power BI content and share it with each other. Think a sales ops team of four, a finance team building month-end reports, or a project management office tracking delivery across a portfolio.

The typical setup looks like this:

• Content creators build reports in Power BI Desktop
• They publish to a shared workspace that the team owns
• Team members get access through workspace roles
• Everyone in the team is both a creator and a consumer, more or less
• The data usually comes from a mix of sources the team already has access to

The key point is that the people building the content and the people using it are the same small group. There's no separate audience of hundreds of report viewers. That changes how you should think about access, licensing and governance.

Microsoft's guidance has more detail on the specifics, and it's worth a read: Power BI usage scenarios - Team BI.

Workspace roles are where it starts

In team BI, the workspace is the collaboration space. You add the team to it, and you assign roles. The four roles are Admin, Member, Contributor and Viewer, and in a team BI setup most people end up as Member or Contributor because they need to publish and edit.

Here's what we tell clients. Don't add individuals to workspaces. Add a Microsoft Entra security group or a Microsoft 365 group, and manage membership there. It sounds like admin overhead for a team of five, but the first time someone leaves the business and still has access to the commission report six months later, you'll wish you'd done it.

The other thing I'd push on is not giving everyone Admin. We regularly find workspaces where all eight people are admins because that was the easiest way to stop the "I can't publish" complaints. Two admins is plenty. Everyone else can be Member or Contributor depending on whether they need to manage access.

Licensing is the bit that catches people out

Team BI is the scenario where Power BI Pro (or Premium Per User) licensing makes the most sense. If every person in the team is creating and consuming content in a workspace that isn't on Premium or Fabric capacity, every one of them needs a Pro licence. That's usually fine for a small team, and it's honestly the simplest model.

Where it gets messy is when the team starts wanting to share with a wider audience. Suddenly the finance team wants the CFO, the exec team and thirty cost centre managers to see the reports. That's no longer team BI. That's departmental BI, and the licensing conversation changes, especially if those viewers don't have Pro licences. We've had more than one client discover this the hard way when people outside the team started getting "you need a licence" prompts the morning of a board meeting.

My advice: know which scenario you're in. If the audience is the team, stay in team BI and keep it simple. If the audience is growing, plan the move to a distribution model (an app, or a capacity-backed workspace) rather than just adding more people to the workspace as Viewers.

Sharing semantic models within the team

One of the better habits you can build in a team BI setup is separating semantic models from reports. Instead of every report having its own embedded model with its own copy of the data, one person publishes a shared semantic model, and others build thin reports connected to it.

This does a few useful things. You get one definition of "revenue" rather than four slightly different DAX measures that give four slightly different answers. Refresh load goes down because you're refreshing one model, not six. And when the source system changes, you fix it in one place.

I'll be honest though. Small teams often resist this because it feels like extra structure for not much benefit. And for a team of two or three with a handful of reports, they're probably right. Where it pays off is when the team gets to five or more reports drawing on the same data. That's usually the point where someone notices two reports showing different totals for the same month and the trust problem starts.

OneDrive, SharePoint and version control

A real problem in team BI is the .pbix file itself. Somebody builds a report, saves it to their desktop, publishes it, goes on leave, and then someone else needs to change it. Where's the source file? Is the version in the service the same as the version on their laptop?

The guidance recommends storing source files somewhere shared, and we agree. A SharePoint document library or a Teams channel's files area is the minimum. You get version history and everyone can find the file. Better still, if the team is comfortable with it, use Power BI Desktop projects (the .pbip format) with Git integration. That gives you proper source control and the ability to see what changed between versions.

Git integration is still a bit rough for non-developer analysts. The concepts of branching and merging don't come naturally to most finance people, and I don't think it's fair to expect a team of accountants to suddenly become comfortable with pull requests. For most team BI setups we recommend SharePoint with a simple naming convention and a rule that you check the file back in when you're done. Not glamorous, but it works.

Data sources and gateways

Team BI often relies on data the team already has: an Excel file on SharePoint, a SQL database the department owns, an export from the CRM. If any of that is on-premises, you'll need a data gateway for scheduled refresh.

This is where we see a lot of fragility. Someone installs a personal-mode gateway on their own laptop, sets up refresh, and everything works until that laptop is turned off for the weekend. Then Monday's reports are stale and nobody knows why.

If the team needs on-premises data, push for a standard-mode gateway managed by IT, running on a server that stays on. If that's not possible straight away, at least document who owns the gateway and what happens when they're away. A short note in the workspace description is better than nothing.

What we've seen work

Across the Power BI work we've done with Australian clients, the team BI setups that hold up over time tend to share a few traits.

One workspace per team, not per person. Personal workspaces have their place for drafts, but anything the team relies on should live in the team workspace.

A named owner. Someone is responsible for the workspace. Not in a heavy governance sense, just someone who knows what's in there, cleans up old content, and is the person to ask.

Shared semantic models once the report count grows. As above. It's the single biggest quality improvement for teams that have outgrown "one report, one model".

Endorsement for the good stuff. Promote the semantic models and reports that are actually trusted. It sounds minor, but it helps new team members figure out which of the twelve reports is the one they should use.

A plan for when it grows. Team BI works until it doesn't. The moment the audience extends beyond the team, you want a plan for publishing through an app and sorting out the licensing.

What's still rough

The honest answer is that team BI relies a lot on people being disciplined, and Power BI doesn't do much to enforce that discipline for you. There's no built-in prompt saying "you have three semantic models that look nearly identical, maybe consolidate them". Workspaces tend to accumulate junk: test reports, old versions, things named "Sales Report FINAL v2 (Sarah)".

Fabric has added more items to workspaces as well, which can make a team workspace feel cluttered if the team is also using lakehouses, notebooks or dataflows. Folders in workspaces help, and I'd use them early.

The other gap is visibility. Unless someone with admin access goes looking at the activity log, a team often has no idea which of its reports are actually being used. We regularly find workspaces where half the content hasn't been opened in months. A quarterly cleanup is a good habit, and it doesn't need to be a big deal.

Where team BI fits in the bigger picture

Team BI is a good place to be. It's where people learn the tool, figure out what questions matter, and build reports that are close to the business. The risk is staying there too long when the content has clearly become something the wider organisation depends on.

If you're at that point, where a team's reports have become business critical and you're not sure how to move them into something more structured, that's a common conversation for us. Our Power BI consultants help teams tidy up their workspaces, consolidate semantic models and plan the move to departmental or enterprise distribution. If your reporting is starting to sit on Fabric as well, our Microsoft Fabric consultants can help with the platform side. And if you're thinking about how AI fits on top of your reporting, our work on AI for business intelligence is a good place to start.

Start small, keep it tidy, and know when you've outgrown it. That's most of team BI in one sentence.