In Power BI, when should you distribute content as an app rather than sharing reports directly?

## Three distinct ways to give someone access Power BI has three access mechanisms that beginners conflate. **Workspace roles.** Add a person to the workspace as Admin, Member, Contributor or Viewer. Admin/Member/Contributor are *authoring* roles with increasing rights over items and access; Viewer is read-only. But a Viewer in a workspace sees **everything** in it — including the experimental report someone is mid-way through rewriting, and every semantic model. Workspace membership is for the team that builds the content. **Direct sharing.** Share a single report or dashboard with named people or groups via a share link, optionally granting *Build* on the underlying semantic model as well. This is fast and precise, and it is the right tool when one colleague needs one report once. **An app.** Publish an app from the workspace, selecting which items belong in it and how they are organised into navigation. Consumers install or open the app and see a curated read-only product. **Audiences** let one app serve several groups with different item sets and different access lists — so "Sales Leadership" and "Regional Managers" can be two audiences of the same app rather than two apps or two workspaces. ## Why apps win for real distribution **Separation of authoring from consumption.** Content in the workspace changes constantly as authors save. An app publishes a *version* of that content: consumers keep seeing the last published app until you update it. That editorial gate is the single biggest reason to use apps — it turns "I saved a broken visual at 4pm" into a non-event. **Access you can actually audit.** With an app, access is a list per audience, in one place. With direct shares, permission has been granted item by item over months by several people; answering "who can see the margin report?" becomes an investigation, and offboarding is unreliable. This is a governance argument, and interviewers expect it. **A navigable product.** Consumers get one entry point with sections and ordering, not five links in five emails. Adoption of BI content is mostly a findability problem. **Update control.** Republishing the app pushes changes to all audiences at once, and you choose when. ## What an app does not do An app is a *packaging and access* layer, not a security layer over data. **Row-level security still applies** through the semantic model: an app consumer who is in an RLS role sees only their rows, and if the model has no RLS, the app shows everyone everything. Never present "put it in an app" as an answer to "how do I stop this audience seeing other regions" — that is RLS's job. An app also does not remove licensing requirements. Consuming content in a workspace on shared capacity requires each consumer to hold a paid per-user licence; workspaces backed by dedicated capacity are the mechanism for letting free users consume. The exact licence names and capacity SKUs have been restructured more than once, so describe the shape of the rule and verify the current specifics rather than quoting a tier from memory. And an app does not grant *Build* on the model by default in a useful way for self-service: if consumers need to make their own reports or use Analyze in Excel, they need Build permission on the semantic model explicitly. ## The decision, stated simply - Two colleagues, one report, this week → **direct share**. - A team that builds the content together → **workspace roles** (Contributor/Member), not an app. - A defined audience consuming finished content → **app**, with audiences if the groups differ. - Audience must see different *rows* of the same report → **RLS on the model**, whichever distribution you chose. ## Failure modes to name The classic mess is a workspace with forty Viewers, thirty direct shares, and no app. Consumers see drafts, permission is unauditable, leavers keep access, and every author is afraid to save. The remediation is: strip the workspace down to its authors, define audiences, publish an app, move the consumers there, and revoke the direct shares — plus RLS on the model if any of those consumers must not see all rows. The opposite mistake is publishing an app per report. Apps are per workspace; a proliferation of one-report apps means your workspace boundaries are wrong, usually because they were drawn per report instead of per subject area and audience.