Almanac
Microsoft/power-biPower Platform

Consultant KB for Microsoft Power BI: semantic models, DAX and modelling, Power Query and dataflows, reports and visuals, the service and workspaces, capacity and performance, embedding and integration, governance and security, ALM and deployment, and licensing, plus cross-cutting decision guides. Scoped to Power BI, with Microsoft Fabric covered where it touches Power BI directly. Implementation notes, configuration decisions and the gotchas that bite on real projects. Populated by the daily author agent from the Power BI release plans, docs repo and product blog, plus the author's own consultant notes.

power-bi/05-service-and-workspaces/feature-power-bi-apps.md
feature-power-bi-apps.mdv1 · history
CurrentApplies to ServiceUpdated last monthSource Microsoft Learn ↗

What it does

An app is the published, packaged, read-only face of a workspace — a curated set of reports and dashboards with its own navigation, its own permissions and its own release cycle. The workspace becomes your staging area; the app is what the business sees.

Key facts

  • One app per workspace. You can't publish two apps from the same workspace.
  • Up to 25 audience groups per app. Each audience sees its own subset of the content and has its own access list.
  • Total access limit is 10,000 users and groups combined across the app, with up to 1,000 per audience group. Each group counts as one entry, which is the argument for using security groups.
  • Workspace users count against every audience group. Four workspace users across five audiences consume twenty of the 10,000.
  • Publishing and updating an app has a one-minute timeout. Large apps fail to update and have to be trimmed.
  • Publishing needs Pro or PPU. Consumers need Pro or PPU unless the workspace is on capacity — Microsoft names P SKUs and F64 or larger for free-licence consumption.
  • Content added to an already-published app is hidden from every audience by default. You have to go and unhide it per audience.
  • Admins can grant the right to auto-install apps into users' accounts. Auto-install and "entire organisation" are mutually exclusive.
  • Apps top out at 200 dashboards.

When to use / skip

Use an app the moment you have more than a handful of consumers, and certainly before anyone asks "can you share that with the regional managers too". Direct sharing scales linearly with your patience; apps don't. The one case for staying with direct sharing is a genuinely ad hoc, short-lived report with a named audience of three — anything that will still exist in six months should be in an app. Multiple audiences also let you avoid the classic mistake of building four near-identical reports because three groups shouldn't see the fourth's numbers.

Configuration decisions

  • How many audiences you need, and whether the difference between them is content visibility or actual data — because if it's data, that's RLS, not audiences.
  • Whether app users get Build permission on the semantic models, which decides if they can create their own reports or just read yours.
  • Whether "allow access to hidden content" is on. It fixes broken drillthrough and dashboard tiles, at the cost of anyone with a direct link reaching hidden items.
  • Whether the app auto-installs for users or they find it themselves through the Apps marketplace or a link.
  • Whether Contributors are delegated the ability to update the app, or every release goes through an Admin.

Gotchas

  • Hiding content from an audience breaks anything that depends on it. Drillthrough targets, dashboard tiles pointing at excluded reports, paginated subreports — all fail with an unhelpful permission error. Include the dependencies or turn on access to hidden content.
  • Removing a report and updating the app destroys users' bookmarks and comments permanently. Adding the report back doesn't bring them back. Unpublishing does the same thing to everyone at once.
  • Items in an app get their own unique IDs, distinct from the workspace originals. Usage telemetry and audit logs will show both, and people misread the numbers.
  • Chained semantic models and models in other workspaces don't inherit app permissions. You have to grant access to every model in the chain separately.
  • If the app relies on a semantic model in another workspace, Build permission granted through the app doesn't reach it.

Consultant notes

  • Sell apps as release management, not as a sharing feature. The workspace-as-staging-area point is what makes stakeholders comfortable — you can break things in the workspace at 4pm and the business sees nothing until you publish.
  • Set the expectation early that new content is invisible by default on update. Consultants get blamed for "the report didn't appear" more often than for anything else in this feature.
  • Use security groups for audiences from the start. Named users hit the per-audience limit slowly and the maintenance burden quickly.
  • If the client has grown a large app organically and updates start timing out, that's the signal to split the workspace, not to keep pruning.

Revisit if the audience or user limits change, or if org app behaviour shifts again in a future wave.

Was this accurate?
Related
Power BI licensing overview10-licensingFree users and content viewing10-licensingWorkspaces and workspace roles05-service-and-workspacesWorkspace and model topology11-decision-guidesPro vs PPU vs capacity11-decision-guidesSharing and distribution05-service-and-workspaces