Power BI Workspace Roles - Simply Explained

Welcome to the M365 FM podcast, where we explore the people, ideas and technologies shaping the future of work. What a power BI workspace role actually is. You gave your teammate a seat in power BI without reading the rules. Most of us assume the share button controls what people see. But the real control sits in a role you picked in one click. Welcome to the M365 FM podcast, where we explore the people, ideas and technologies shaping the future of work. Today, we're talking about power BI workspace roles, the four seats that decide who can look, who can build, and who can change things. By the end, you'll know which role fits a teammate and where the role stops protecting your data. One of these roles sees far more than people expect, and most teams hand it out without a second thought. A workspace is the shared room where your team keeps its power BI work, and it holds more than most beginner's picture. Inside, you'll find the dashboards people check every morning, the reports sitting behind those dashboards, the semantic models that feed the reports, and the paginated reports that still print like a page. Your role is the seat you get in that room, and it settles one question whether you can only look at what's here or also change it, that's a different thing from sending someone a single file, sharing hands over one item while a role hands over a seat in the room itself, and everything that comes with it. That sounds small until it isn't. Because almost every access headache a new team hits comes back to this one choice. Most people meet at the same way. A colleague adds them to a workspace, they click accept and they never think about it again. The four seats in a workspace. There are four seats and power BI names them viewer, contributor, member and admin. Picture them as a single ladder with the least power on the bottom rung and the most at the top. They stack in a clear order, and the two seats in the middle are where most of the confusion lives. A viewer can look at everything in the workspace and interact with it, and that's the entire job. They open reports, click through the pages, and they can subscribe to a report. So a fresh copy lands in their inbox on a schedule. What if you can't do is change a single thing? A contributor can do everything a viewer can, and they can also build. They create and edit reports, work on the semantic models underneath them, and delete content the team no longer needs. What they can't do is share that work outward or publish the app that wraps the workspace into something a wider audience can open. A member takes the next step up and adds sharing to the mix. Members can share items with the people around them, update the workspace app, and add other people at the same level or lower, and admin can do all of it. And an admin is also the only person who can delete the workspace or change someone else's role. When you see a single name listed as the owner of a workspace, that person is almost always sitting in the admin seat. One detail about these roles is easy to miss and it shapes everything else. A role applies to the whole workspace, not to a single report. There's no switch that lets someone edit this dashboard while only reading that one, because the seat covers everything inside the room. That's also why groups make this so much easier to run. You're not limited to adding one name at a time, because power BI lets you assign a role to a security group, a Microsoft three hundred sixty five group, or a distribution list. Everyone in that group picks up the role, and if a person belongs to several groups, they end up with the highest role. Any of those groups gives them nest one group inside another, and the role flows down to everyone inside, which saves work and is also easy to forget. Say your company keeps a group called Data Team. Give that group the contributor role and every person in it becomes a contributor in one step. Add a new analyst to the group next month and they inherit the role without anyone touching power BI. What each role can and cannot do. Now that the ladder makes sense, the useful part is where the rungs sit close together. The gaps between them matter far more than the names. Start with the contributor because this is the role people misjudge most. A contributor creates, edits and deletes reports, dashboards, and semantic models, and they can schedule a refresh so the numbers stay current. All of that is real work. What a contributor can't do is share any of it. If a contributor builds the best report in the company and wants a colleague outside the workspace to see it, someone else has to hand it over. An admin can let contributors update the app, which helps with publishing, and it still doesn't turn them into people who can give out access. There's one more practical perk in this seat. A contributor can connect a data refresh to an on premises gateway, which is how a lot of companies pull numbers from a server that lives inside their own building. It's a real ability, and it makes contributor more powerful than the name suggests. A member sits one rung higher, and the difference is easy to miss. Members can share what they build, update the app, and add people to the workspace. The wrinkle is worth spelling out. A member can add a new person, but a member can't remove anyone and a member can't change an existing person's role. If a colleague joins as a viewer and later needs to become a contributor, the member can't simply upgrade them. An admin has to remove the person first, and then the member can add them back with the new role. Picture that in practice, a manager joins to read the numbers, then takes on a project that needs editing. The member who added her can't upgrade her, so an admin removes her and adds her back as a contributor. It works and it takes two people and a bit of patience. An admin holds the keys to the room itself. Only an admin can delete the workspace, and only an admin can rewrite the access list. That's why the admin seat is the one worth guarding. The viewer seat looks like the safest choice, and most of the time it's just that it also carries a surprise that catches new teams off guard, and that surprise is big enough to deserve its own section. The viewer role sees more than you think. This is the part that surprises people because a viewer doesn't see just one report. A viewer sees the entire workspace. Everything the team has saved in that room is open to a viewer, and that includes the half finished dashboard, the report you built to test an idea, and the semantic model you weren't ready to talk about yet. If it lives in the workspace, a viewer can open it. Teams hand the viewer roll out freely because it sounds harmless, and then they wonder why a contractor can browse six months of work in progress. This is why it pays to think about what else lives in a workspace. Before you add a viewer. A workspace built only for finished reports can take viewers all day long. A workspace that doubles as a workbench full of drafts, test files, and experiments is a different kind of room, and every viewer you add walks straight into the middle of it. The confusion runs in both directions, and it shows up most often when someone tries to take access away. Say you share a single report with a colleague and later you decide to pull that share back. You remove their permission on the report and you feel finished. If that colleague still holds the viewer role on the workspace, they open the report anyway because the workspace role is doing the work now to genuinely cut them off. The workspace role has to go as well Once the workspace role is gone, you can still share one report by sending a link. That person opens the report, sees exactly that report, and never learns the rest of the workspace exists. So a real decision sits in front of you. Between handing someone the whole room and handing them the one thing they asked for. For a small internal team, the whole room is often fine and the simplest thing to run for anyone outside the team. The single link is the safer default, and it keeps your unfinished work out of view. That's worth keeping in mind the next time a viewer feels like the easy choice. Apps sharing and the wider audience. Once the audience grows past a handful of people handing out individual links stops working. And that's where a power BI app earns its place. An app is a curated bundle you publish from the workspace. You choose the reports and dashboards that belong together, arrange how they're laid out, and publish the whole package as one clean product. People open the app and they never touch the workspace itself. They see the reports you selected and nothing else. The app also lets you point different content at different groups. You can set up audiences so the finance team opens the app and lands on the finance reports while the sales team lands on theirs. All of those reports live in the same workspace, and each audience only sees its own part of the app. This is how one workspace can serve several teams without giving anyone the keys. An app also gives you one place to update when a report changes, you republish the app, and everyone who opened it picks up the new version with a pile of shared links. You'd be chasing each person to send them a fresh one. Now for the honest limit because it catches people. An app is a delivery layer, not a data lock. It decides what a person can open, not which rows of data they see. Once it's open, if the sales report holds every region's numbers, everyone in the sales audience still sees every region's numbers. Keeping one region from seeing another region's rows is a separate job, and it needs a separate tool. A rough rule helps here. If you're passing one report to one colleague, a link is fine. If you're sharing a set of reports with a group or with anyone outside your team, publish an app. That choice comes down to how many people you're serving and how often the content changes. Why? The license question keeps coming up. Before you assign anyone a seat, there's a money question to settle, and it changes the answer for a lot of beginners if the workspace sits in a shared capacity, which is where most small teams start, then every person you add needs a paid power BI pro or premium per user license. That includes the people who only ever look in a shared capacity. Viewing isn't free. Move the same workspace into a premium capacity, and the rule flips. A viewer can open the workspace and its content without a paid license. And that's the path most companies use to give a wide audience read access without buying a license for every single person, the capacity behind the workspace is the paid horsepower, and it decides which license rules apply. A shared capacity is the free default, and a premium or fabric capacity is the paid upgrade. Which one a workspace sits in is usually an admin decision. So if the license math looks wrong, that's the first thing to check. The catch lives in the role you pick. Give one of those free viewers a higher role like contributor or member, and they can still browse, but the moment they try to create something, power BI nudges them to start a paid trial. The free experience holds only while they stay at viewer, and it breaks if they pick up a higher role through some group you forgot they belong to. One more detail confuses people during setup, and it's worth knowing before it wastes an afternoon. Assigning a role doesn't check the license at that moment. You can add a person with no license to a role that requires one, and everything looks fine until they try to use it. Published from power BI desktop into a shared capacity workspace without a Pro license, and the publish fails with a message telling you that only users with power BI Pro licenses can publish their roles are not the same as row level security. Here's the idea that clears up most of the confusion around power BI access. A workspace role and row level security are two different locks, and they guard two different things. The workspace role answers whether a person can get into the room and open what's inside. Row level security answers which rows of data that person can see. Once a report is open, you can hand someone the viewer role and still let them see only their own regions numbers. Because the two controls stack on top of each other, power BI checks three layers in order before anyone reaches data. First, it checks whether the person can sign into the organization's identity at all. Then it checks whether they can get into the power BI or fabric service. Finally, it checks whether they're allowed to do the specific thing they're asking for on that specific table or file, a person has to clear all three. This is why access can still fail after you've granted a role, and why a role by itself never hides data inside a report. Row level security is set up inside the semantic model, usually in power BI desktop. By defining roles and rules on the tables, those rules travel with the model. So the same report shows different rows to different people depending on who opens it. Microsoft's own guidance makes the split concrete to enforce row level security. For the people who browse a workspace, you use the viewer role, the role gets them through the door, and the row rules shape what they see once they're inside. Skip the row rules and lean on the role alone, and every viewer sees every row. The two tools also fail in different ways. Get the role wrong and the wrong person walks into the room. Get the row rules wrong and the right person sees the wrong numbers. Both mistakes stay quiet and both tend to surface later, usually in a meeting where someone reads out a total they were never supposed to see. Once you see the role as one gate and not the whole wall, the questions people ask about power BI access start to make sense. where this sits in Microsoft three hundred sixty five and Azure. Zoom out for a second, because where these roles live explains why they behave the way they do. The identity behind every power BI role comes from Microsoft Entra ID, the same identity service that Microsoft three hundred sixty five and Azure rely on. That's why you can hand a role to a group rather than to a single person, and let the group carry the work. Add one person to the group and they pick up the workspace role on their own. It's also why you can give a role to a service principle, which is an app registration rather than a human, so an automated process can work with the workspace by itself. That same setup is why an access change can feel slow. Power BI is asking enter ID who you are and whether you belong to the right group. So a group change has to land before the workspace role catches up. One behavior here surprises people during Offboarding. Disabling a person in Microsoft Entra ID doesn't strip their power BI access records. Those records stay until the account is permanently deleted, which is deliberate so that re-enabling the account brings the access back while the account sits disabled, the person can't use it and the record is still there. Power BI now sits inside Microsoft Fabric, and the same four rolls carry over a fabric workspace uses the same admin, member, contributor and viewer ladder, and those rolls reach fabric items like lake houses and warehouses. Learn the ladder once and it keeps showing up. One small limit is worth remembering for scale. A person with a power BI Pro license can belong to a maximum of one thousand workspaces. The mistakes beginners make with rolls. With the full picture in place, the mistakes get easier to spot because they tend to come from the same place. People treat the workspace role as a quick switch instead of a deliberate choice. The biggest one is handing out admin because deciding feels slow. It's the easiest role to give and the hardest one to take back, since only an admin can change another person's role. Give three people admin on day one and you have three people who could wipe out the whole workspace. The second is adding named individuals one at a time that works for a week, and then someone changes teams and nobody remembers which of forty names still needs access. Groups solve this and they cost nothing extra to use. The third is trusting the role to protect the data. The role gets people into the room and it does nothing to hide rows inside a report when the numbers are sensitive, the row rules are a separate job you still have to do. The fourth is sharing individual reports long after the audience has grown. Once more than a handful of people need the same view. An app gives you one clean front door instead of a pile of links. The fifth is easy to forget. A member can bring people in. So if you hand out member widely, you've handed out the ability to grow the workspace. The short version and a question for you. So here's the short version to carry with you. A power BI workspace is a shared room and a role is the seat you get in it. The four seats stack in one line from viewer who only looks up through contributor who builds member who also shares an admin who also runs the room. A viewer sees everything in that room, not just the one report you had in mind in a shared capacity. Everyone needs a paid license, while a viewer in a premium capacity can look for free, the role only controls who gets in, and it never controls which rows of data they see. One question to take with you when you look at your own team's workspace, does everyone really need the seat they have? If this made the topic feel less intimidating, subscribe to M365 FM to master the tools and the mindset shaping the future of work.