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/07-embedding-and-integration/feature-power-bi-embedded.md
feature-power-bi-embedded.mdv1 · history
CurrentApplies to EmbeddedUpdated last monthSource Microsoft Learn ↗

What it does

Puts Power BI reports, dashboards and tiles inside your own web application rather than sending users to the Power BI service. There are two scenarios with genuinely different architectures, licensing and auth models, and picking the wrong one is expensive to undo.

Key facts

  • Embed for your customers (app owns data) is aimed at external users. Your app authenticates non-interactively with a service principal or a master user, and the end users never sign in to Power BI or hold a Power BI licence.
  • Embed for your organisation (user owns data) is aimed at internal users. Each user signs in against Microsoft Entra ID with their own credentials and needs their own Power BI licence.
  • R and Python visuals aren't supported in the embed-for-customers scenario. They are supported in embed-for-organisation, subject to region restrictions.
  • Both scenarios need a capacity for production. Microsoft lists three offers: Power BI Embedded (A SKUs, Azure, hourly billing, pause and resume), Power BI Premium (P and EM SKUs, Office, monthly or yearly commitment), and Microsoft Fabric (F SKUs, Azure).
  • Free embed trial tokens work with a Pro licence for development testing only. Until you buy capacity, a Free trial version banner stays on the embedded report.
  • In the user-owns-data and Microsoft 365 embedding scenarios, only P SKUs and F64-or-higher let free Power BI users consume the content. Below F64, or on an A SKU, every viewer needs Pro or PPU.
  • Secure URL embedding — the no-code iFrame option from the service — works on F and P SKUs but not on A SKUs.
  • Publishing content to a workspace needs a Pro or PPU account, or a service principal calling the Post Import In Group REST API.

When to use / skip

Use embed-for-customers when the audience sits outside your tenant and you're building a product: an ISV portal, a customer-facing extranet, a partner dashboard. Use embed-for-organisation when you're putting reports into an internal line-of-business app and everyone already has a Power BI licence — it's much less code, because you're not minting embed tokens or managing an embedding identity. If the requirement is really "show this report inside our intranet page to staff who all have Pro", stop before you reach for the developer APIs and look at secure embed or the Teams and SharePoint options first. A lot of embedded projects are built because nobody checked whether the no-code path would do.

Configuration decisions

  • Which of the two scenarios you're in, decided by who the audience is, not by what the app looks like.
  • The capacity type, and specifically whether the pause/resume and hourly billing of an A SKU matters more than the free-viewer entitlement you get at F64 and above.
  • Whether the embedding identity is a service principal or a master user, if you're going app-owns-data.
  • How the app maps its own users onto Power BI row-level security, since the semantic model has no idea who your customers are.
  • Where capacity sizing comes from — number of concurrent renders and model memory footprint, not licence count.

Gotchas

  • The two scenarios aren't interchangeable in code. Embed-for-organisation applications can't use a service principal, so a mid-project pivot from internal to external means rewriting the auth layer.
  • A SKUs aren't a cheaper route to internal sharing. Below F64 every internal viewer still needs Pro or PPU, so the licence bill doesn't go away.
  • Capacity pause is a real outage. If someone pauses an A SKU while a report session is open, users get an OpenConnectionError or a model-schema load failure, not a friendly message.
  • Fabric F SKU capacities aren't supported in GCC — only EM and P SKUs are. They are supported in GCC High and DoD.
  • Semantic model memory limits are per item, not cumulative. On an F64 a single model is capped at 25 GB, which is a different constraint from total capacity memory.

Consultant notes

  • Scope the embedding identity conversation with the client's security team in week one. "We need a service principal that is a member of these workspaces" is a much easier ask early than a fortnight before go-live.
  • Get them to build a proof of concept against the embedded analytics playground before committing to a design. It rules out half the "is it us or is it Power BI" arguments later.
  • Licensing detail beyond the SKU table lives in Microsoft's licensing guide rather than the docs. Don't quote numbers to a client from memory — send them to procurement with the scenario written down.
  • Budget for a capacity-sizing exercise, not a capacity guess. Embedded workloads are spikier than internal ones because a customer portal has no 9-to-5.

Worth a look again if the A SKU story changes, or if the client's Fabric capacity plans move the F64 threshold into scope.

Was this accurate?
Related
Licensing for embedded scenarios10-licensingPower BI on Dynamics 365 dashboards07-embedding-and-integrationEmbedding APIs and authentication07-embedding-and-integrationPower BI in model-driven apps07-embedding-and-integrationPower BI in Microsoft Teams07-embedding-and-integrationPower BI vs native Dynamics 365 reporting11-decision-guides