← All Kits · Power BI Kit

Power BI Workspaces, Roles and Apps: Publishing to Readers

Michael Nocito · Updated August 2026 · Behaviour checked against Microsoft's own documentation, linked at the end

You fixed the report, published it, and somebody emailed to say the number is still wrong. This page explains why, in one sentence and then in detail: publishing puts your work in the workspace, and your readers are not looking at the workspace. It also covers the four roles that decide who can do anything about it, and what a dashboard is for.

What you do: after publishing from Power BI Desktop, go to the workspace and press Update app. Microsoft calls the workspace your staging area and states that changes are not live in the app until you publish again.

The short version. The workspace is where you work. The app is what your readers see. They are not the same thing.

The path from your machine to a reader

Before the steps: how many separate publishing actions stand between a change on your laptop and a reader seeing it?

Two, and only the first one is automatic in any sense.

1. Build in Power BI Desktop and publish to a workspace. The workspace is the team's working area, and everybody with a workspace role can see what is in it.
2. Package the workspace content as an app and publish that to your audience. App users get it from the Apps marketplace, from a direct link you send them, or installed automatically if your admin allows it.
3. After every later change, publish to the workspace as usual, then press Update app. The people you published to then see the updated version.

Say out loud why the second step exists at all. Because without it there is no safe place to be half-finished. The staging step is what lets you republish a broken report at 4pm, notice, and fix it, without four hundred people watching it happen.

Two details in the same documentation that catch people out on the update. New content added to an already published app is not included by default, so a new report can sit in the app's content list invisible to every audience until you unhide it. And if you remove a report and update the app, app users lose their customizations on it, including personal bookmarks and comments, and those cannot be restored even if you add the report back.

The four roles, and the two that catch people out

First: somebody needs to edit reports in your workspace but must not be able to change who else has access. Which role?

Contributor. Here is the whole ladder, cut down to the rows that decide real arguments.

The two that catch people out are both worth memorising.

A Contributor can update the app, but only if an Admin turns that on. The workspace setting is "Allow contributors to update the app". Even then, they cannot publish a new app or change who is allowed to edit it. So "can Contributors update the app" has three answers depending on the workspace, which is exactly why the exam asks it.

Members cannot change an existing person's role. They can add somebody at a lower level, but to move a Viewer up to Contributor an Admin has to remove that person first, and then the Member can add them back at the new level. If a role change is not sticking, that is usually why.

One more, and it decides whether your security works at all: Viewer is the role that makes row-level security apply. Anyone with edit rights on the data sees all of the data, by design. RLS and a Contributor role on the same person means no filtering. That is covered in row-level security.

Reports and dashboards are different objects

Before the comparison: both show visuals, both live in a workspace. What actually separates them?

Where they can be built, and what they are made of.

A dashboard is the answer to "I need one screen pulling the top number out of four different reports". Alerts live there too, which is covered in refresh, gateways and alerts.

One trap when you package a dashboard into an app: a dashboard tile pointing at a report that is not in the app, or is hidden from that audience, does not work. The reader gets an error saying the report does not exist or they do not have permission. Add the reports behind your tiles, and make them visible to the audience.

Endorsement tells people something. It gives them nothing.

First: you certify a semantic model. Who can now see it that could not before?

Nobody. Endorsement is a signal about quality, not a permission. There are two levels.

You can endorse semantic models, dataflows, reports and apps. If semantic model discoverability is switched on, an endorsed model can be made discoverable, which lets people who do not have access find it and request access. Finding and requesting is still not having: the request goes through the normal permission route.

Picture your own workspace. If somebody outside your team found four semantic models with similar names, which one would they pick, and is that the one you would want them to pick? Endorsement is the only thing on that screen that answers the question for them.

Edge cases worth knowing

One app per workspace. If you need two separately governed collections, you need two workspaces. You can, however, create up to 25 audience groups inside one app and show different content to each.

Nobody is emailed about an update. Power BI does not send internal users email when you distribute or update an app. If the change matters, tell them yourself.

Hidden is not secure. If "Access to hidden content" is on, anyone with a direct link to any item in the app can open hidden content. Hiding is navigation, not permission.

Unpublishing destroys reader customizations. Unpublish an app and users lose personal bookmarks and comments, even if you republish later.

App items have their own IDs. The same report in the workspace and in the app carries two different unique IDs, which matters the day you start reading usage logs and the numbers do not add up.

Why the staging step exists

Every reporting tool has to answer one question: what does a reader see while the author is halfway through a change?

Power BI answers it with two layers. The workspace holds live, editable content for people who are building. The app holds a published version for people who are reading. Publishing from Desktop only touches the first layer, which is why your fix can be genuinely live and genuinely invisible at the same time.

The same split explains the roles. Admin, Member and Contributor are all names for degrees of "can change what is in the staging area", and Viewer is the only one that means "reads what was published". It also explains why row-level security only bites on Viewers: the other three roles are, by definition, people who work on the data rather than people who consume it.

How to apply this to your own work

1. Write the two-step release out and stick it next to your screen: publish to the workspace, then Update app. Nothing reaches a reader until the second one.
2. After any update that added content, open each audience group and unhide the new items. New content is invisible by default.
3. Audit who has which role in your busiest workspace. Anybody who only reads reports should be a Viewer, both for least privilege and because RLS depends on it.
4. If your report owner is not an Admin, get "Allow contributors to update the app" turned on, or every release goes through somebody else's calendar.
5. Endorse the models people actually should use. It costs one click and it is the only guidance a stranger gets.

If you have paper nearby, draw the two boxes, workspace and app, and write the names of everyone who can see each one. Most teams discover that the workspace list is longer than they thought and the app list is shorter.

Cheat sheet

The one habit to keep

Check your change the way a reader will. Open the app, not the workspace, in a private browser window if you can. The workspace will always show you your own work, which is exactly why it is the wrong place to confirm anything shipped.

Who in your organisation can press Update app on your main report, and what happens to your release schedule the week they are on holiday?