Workspace permissions for event teams that stop everybody becoming an admin

The access dialog on the shared analytics workspace had sixty names in it and every one of them could edit. Nine were admins, because each show team had asked for one and nobody had a reason to refuse. The rest were members, which had become the default answer to any request, because member was the role that made whatever the person was trying to do work on the first attempt.

Workspace permissions for event teams tend to arrive at that state through a long series of kindnesses. Somebody needs to schedule a refresh, somebody needs to subscribe a colleague to a report before a board meeting, and the fastest path to yes is the role above the one they need.

How sixty people ended up with edit rights

Retrace the requests and none of them look wrong on the day.

The audience acquisition lead needed to fix a broken visual at eight in the evening before doors opened. The finance analyst needed to add a measure. A show director wanted to send the pre-show pack to twelve colleagues on a schedule. An agency contractor needed to publish a report for one edition and never got removed.

Each of those is a real need and each was answered with membership rather than with the narrower thing that would have worked. The aggregate is that all sixty people can create, edit and delete content in the workspace, nine can delete the workspace itself, and the row filters carefully built on the portfolio model apply to nobody at all.

The four roles and what each actually permits

Four roles exist and they nest, which is the first useful thing to know. The Power BI documentation for content creator security planning (Microsoft Learn, 2026) states that "The four workspace role permissions are nested", so an admin has everything a member has, a member everything a contributor has, and a contributor everything a viewer has.

Admin is the only role that can update or delete the workspace and add or remove any user in any role. Member can add people at lower permissions and can publish, unpublish and change permissions for the app. Contributor can create, edit and delete content, schedule refreshes through a gateway and subscribe others to reports. Viewer can view and interact, read data in workspace dataflows, and subscribe themselves.

One asymmetry causes a lot of confusion in practice, and the workspace roles documentation (Microsoft Learn, 2026) spells it out: "Members can't change existing users' roles. Members can add users to a workspace with lower permissions, but can't remove users from any workspace roles." Upgrading somebody from viewer to contributor therefore takes an admin to remove them first. That single limitation is why teams with no available admin end up granting member to everybody, and it is worth knowing before you design the process rather than after.

Why does an extra contributor break row level security?

This is the consequence that turns a tidiness problem into a data exposure problem.

Row filters are enforced against people who can read the model and bypassed by anybody who can edit it. The Power BI documentation (Microsoft Learn, 2026) states that filtering "only restricts data access for users with Viewer permissions. It doesn't apply to workspace Admin, Member, or Contributor roles." The implementation planning guidance says the same thing from the permission side: a user with read permission has filters enforced, a user with write permission sees all data in the semantic model.

Apply that to the workspace above. Sixty people, all with edit rights, means the show-level filter on the portfolio model is currently protecting nobody. The security page looks correct. The filter expression is correct. Every director can see every rate card in the group.

Fix the membership and the arithmetic inverts. Two admins and six contributors is eight people holding edit rights, 13 per cent of the sixty, and the other 52 are reading a filtered model for the first time. The filter design that makes that worth doing is a separate subject, handled in row level security for event portfolios, but no amount of design effort there survives a workspace where everyone is a member.

Put consumers in an app audience

The mechanism that lets you shrink workspace membership without taking anything away from anybody is the app.

Report consumer security planning guidance (Microsoft Learn, 2026) is direct about it: "Generally, it's a best practice to use a Power BI app for most consumers." A workspace can publish one app, and within that app you define audiences, each seeing a different subset of the items. Somebody in an audience gets a curated set of finished reports and never sees the half-built page a modeller is working on in the workspace.

For a portfolio team, four audiences usually cover it. Show teams, at 31 people, see the pre-show, on-site and post-show pages for the shows they are mapped to. Commercial leadership, nine people, adds the renewal and pricing pages. Finance, eight people, sees revenue and nothing on attendee detail. Four external agency users get one page and nothing else. That is 52 consumers, none of them in the workspace, all of them subject to the row filter.

The same guidance grounds this in the principle of least privilege and notes that consumers typically need read permission on the underlying model and nothing more, since build permission is what allows exporting underlying data and creating new reports.

One caution the guidance flags is worth planning around. Publishing an app publishes its content and its permissions together, so you cannot republish purely to change who has access. Assign audiences to security groups rather than to individuals, and access changes become group membership changes with no publish at all.

How many admins should a workspace have?

Two, and the reasoning has both a floor and a ceiling.

The floor comes from the content creator security planning guidance (Microsoft Learn, 2026), which recommends "at least two administrators so that one serves as a backup should the primary administrator be unavailable" and names the failure it prevents: a workspace whose only admin leaves the organisation becomes an orphaned workspace with nobody able to manage it.

The ceiling comes from what the role can do. The same guidance warns that a workspace administrator has high privileges, can view and manage all content, can add and remove users including other administrators, and can delete the workspace. Nine admins is nine people who can remove the other eight.

Two is enough for cover during a show week, when the person who normally handles access is on a stand in another country. Pick people whose job includes being reachable, and write their names somewhere other than the access dialog.

There is a variant worth knowing about before somebody argues for a third admin. A workspace setting lets admins delegate app updates to contributors, so a contributor can push a change to the published app without gaining the ability to publish a new app or change who can edit it. That covers the most common reason a team asks for another admin, which is that the person who republishes the app after every content change is not always around.

The other reason teams over-grant is the semantic model owner. Refresh credentials and parameters belong to whoever owns the model, and taking ownership requires contributor or above. If one analyst owns fourteen models and goes on leave, the pressure to promote somebody arrives immediately. Setting model ownership deliberately, to a person who will still be there next year, removes that pressure before it turns into a permanent role change.

The review that happens when a show closes

Access decays on a schedule that event businesses already have, which makes the review easy to place.

The week after doors close, contractors leave, temporary access granted for on-site reporting stops being needed, and a set of people who were added in the last fortnight before the show are still in the workspace. Run the list then, while everybody remembers why each person was added.

Two questions per name. Does this person still need to edit, or would an app audience serve them now? And was this access granted for one edition? The second question catches agency staff and the seconded analyst, which are the two categories that accumulate. Whether the reports those people were reading deserve a badge at all is the certification question, and what happens when a filtered figure leaves the tool as a file belongs with sensitivity labels on event reports.

Where this stops

Workspace roles govern the workspace. They do not govern everything a determined person can reach, and two gaps matter for an event portfolio.

The first is the gateway. Contributors can schedule refreshes through an on-premises gateway, and gateway permissions are managed separately from workspace roles. Tightening the workspace does not tighten who can point a refresh at a data source, and those permission lists drift apart quietly.

The second is that a viewer with build permission can still export underlying data and analyse it in a spreadsheet, filtered by whatever row rules apply to them. That is often the correct outcome and it is worth knowing you have chosen it. Once the data is in a workbook on a laptop, workspace permissions have stopped applying entirely, and the only control still attached is whatever classification travelled with the file.

The first step is a screenshot. Open the access dialog on your busiest analytics workspace, count the names above viewer, and divide by the total. If the answer is above a quarter, the row filters on that reporting model are doing less than the people who built them believe, and the fastest correction is an app with two or three audiences rather than a permissions policy nobody reads.