Power BI Embedded Analytics, Explained for SaaS Engineering Teams

What Is Power BI Embedded Analytics? Three Things the Phrase Names

Half the confusion we hear in scoping calls isn't about Power BI's capability. It's about which product the person on the other end of the call actually means, because three different things answer to the same name and each one lands a different bill.

Power BI embedded analytics is Microsoft's set of options for placing Power BI reports, dashboards and visuals inside another application, and the phrase covers three separable things (Microsoft Learn). You pick a scenario from how your viewers authenticate and how they're licensed; you pick a capacity from how much concurrent query load they generate.

The first is the Power BI Embedded Azure resource, bought as A SKUs (stock keeping units) and billed hourly. The second is capacity-based embedding on Microsoft Fabric F SKUs, which replaced the retired Premium P SKUs. The third is the choice between two embedding scenarios: "embed for your customers", where your application authenticates external users who hold no Power BI licence, and "embed for your organization", where each internal user signs in with Microsoft Entra ID and needs an appropriate licence of their own (Microsoft Learn). The scenario decides authentication and licensing; the capacity decides the bill.

Those three choices are orthogonal, which is the part that trips people up. Microsoft's own licensing notice confirms the Premium P SKU path closed to new purchases on 1 July 2024, so the live capacity options are A SKUs through Azure and Fabric F SKUs; anyone still framing the decision as "Embedded vs Premium" is working from a retired menu.

A quick aside on naming, because it costs people an afternoon: "Power BI Embedded" in search results sometimes means the Azure resource, sometimes means any Power BI content inside any app, and occasionally means a consultancy's service line. Say which one you mean in the first sentence of your own internal doc.

So the honest answer to "should we use Power BI embedded analytics?" is that you can't evaluate it until you've named which of the three you're talking about. Each carries a different bill, a different authentication model, and a different list of things your engineers end up owning. That last list is where the real cost sits, and it's the same list whichever SKU you land on.

Embed for Your Customers vs Embed for Your Organization

Microsoft splits embedding into two scenarios, and which one you're in is not simply a preference. Your audience is the usual signal, not the rule: the scenario turns on how viewers authenticate, how they're licensed, and where their identities live. If they authenticate through your own application and hold no Power BI licence, you're in "embed for your customers" (historically called app-owns-data) — while external people invited into your own Microsoft Entra ID tenant as B2B guest users sign in with Entra ID and are licensed under the same rules as any other viewer.

Microsoft's own embedded analytics overview publishes a comparison of the two. It's accurate and worth reading, but it stops at licensing and authentication. Here are the runtime columns we'd add, because they're the ones that turn into tickets:

The asymmetry is the whole point. In "embed for your organization", Power BI already knows who the user is and what they're allowed to see, so authorisation is largely Microsoft's problem. In "embed for your customers", Power BI has no idea your customers exist. Your application becomes the identity provider, your backend becomes the token service, and every correctness decision about who sees which rows moves into code your team writes and maintains.

So: the scenario follows from authentication, licensing and where identities live, not from where your audience sits. SKU shopping comes after that, not before.

Multi-Tenancy and Row-Level Security in Embedded Power BI

A customer logs into your product. Your own authentication (single sign-on via your identity provider, or your session cookie) says they belong to tenant 4471. Your backend then calls the Power BI REST API as a service principal, generates an embed token, and attaches an effective identity: a username, the dataset it applies to, and the row-level security (RLS) role to activate. The client software development kit (SDK) loads the report in the browser with that token. The semantic model's RLS filter reads the identity and restricts every query to tenant 4471's rows.

That's the whole chain. Host app auth produces the tenant claim; a service principal (or a master user account, which Microsoft supports but which concentrates a lot of trust in one credential (Microsoft Learn)) mints the token; the token selects the RLS role; the role filters the data. Break a link — a mis-mapped role, a missing effective identity — and the report can still render, just with rows the customer should never see.

Which is the uncomfortable part. In the "embed for your customers" scenario your application is the identity provider — Power BI never sees your end users, has no record of them, and has no way to check the tenant assertion your backend hands it. When tenants share one semantic model, the boundary between two tenants' data is an RLS role your team wired up and has to keep correct through every schema change, every new dataset, every new report. Microsoft's own row-level security guidance for embedded analytics is clear that the effective identity is your responsibility to construct.

Power BI also supports workspace-level isolation, where each customer gets a separate workspace and typically its own semantic model, provisioned programmatically using service principal profiles. Microsoft recommends this model for large-scale independent software vendors (ISVs). It removes the shared-model RLS boundary between customers, but replaces it with another engineering responsibility: provisioning and maintaining potentially thousands of Power BI workspaces, models, connections and report versions.

The ceilings are published. Without profiles, a service principal is limited to 1,000 workspaces; each profile can access or create up to 1,000 workspaces, and a single service principal can have up to 100,000 profiles (Microsoft Learn). So is the cost: Microsoft says profiles "can add complexity to your application design", and recommends them "when you have many workspaces and more than 1,000 application users" (Microsoft Learn).

On a shared model, the common failure mode is quieter than a breach. A team builds the per-customer dashboard, filters it by tenant in the report's visual-level or page-level filter, demos it, ships it. It works. Then someone adds a drill-through, or exports the underlying data, or a new report gets published against the same model without the filter, and the boundary isn't there.

Enforcement has to sit below the presentation layer: at the data, semantic, query, or governed runtime layer. A filter in a report is a display choice. We build row-level security into the model and the runtime for exactly this reason: the boundary shouldn't depend on which report someone opened.

What Your Team Still Has to Build

Choosing Power BI Embedded doesn't take the analytics runtime off your roadmap. It hands you a named list of components to build, operate, and keep in sync with your product. Microsoft's own developer documentation is the best source for this list, which is why it's hard to argue with.

Here's what lands on your backlog in the "embed for your customers" scenario:

1. Embed token minting and refresh. Your backend calls the Power BI REST API to generate embed tokens, and how many you mint is an authorisation-scope decision for your application rather than a fixed one per report, per user, per session — a single Generate Token call can cover multiple reports, datasets and target workspaces. Tokens expire; Microsoft's embed token documentation covers generation and its limits, and you own the refresh loop in the browser so long sessions don't die mid-drill-down.
2. Service principal and workspace configuration. A Microsoft Entra ID service principal (or a master user account, which we'd avoid for anything customer-facing) needs tenant-level settings enabled, admin rights on each workspace, and a secret rotation story.
3. Row-level security roles mapped to tenant identity. The RLS role and effective identity in the token has to be derived from your app's own session, not from anything the client sends. Get the mapping wrong and one customer sees another's rows.
4. Theming and white-labelling. The JavaScript client software development kit (SDK) gives you layout and theme hooks, plus the ability to hide default chrome. Matching your product's typography, spacing, and interaction patterns is ongoing work, not a one-off.
5. Report lifecycle across environments. Promoting reports from dev to staging to production, rebinding datasets, and keeping parameters correct. This is where embedded BI projects quietly slow down, because reports are artefacts in a service rather than files in your repo.

None of this is exotic engineering. It's just permanent. Every one of those five items needs an owner, a test, and a runbook, and it all has to keep working while your product ships around it.

That's the real cost line. Not the licence.

What Power BI Embedded Analytics Costs as You Add Customers

In the "embed for your customers" scenario you buy capacity, not seats. Your bill is decoupled from how many customers you have and coupled instead to how much compute they use at the same moment.

Here are the live paths and what each one actually commits you to:

• Power BI Embedded A SKUs, bought through Azure. Billed hourly and pausable; you're not charged while the capacity is paused (Azure pricing). Useful when load is predictable and off-hours are genuinely quiet.
• Microsoft Fabric F SKUs, pay-as-you-go. Also pausable, with billing stopping for the paused period (pause and resume). This is the path most new builds land on.
• Fabric F SKUs, reserved. A one-year commitment at a lower rate. Pausing doesn't help you; you pay regardless.
• Premium P SKUs. Retiring. Microsoft no longer sells new P SKUs, and each existing subscription retires at the end of its current agreement term rather than on one blanket date — customers with expiring Enterprise Agreements or Microsoft Cloud Agreements can't add or renew P SKU capacity through their agreement (Microsoft Learn), so the real choice is A SKUs or F SKUs.
• The F64 line. At F64 and above, viewers with a free licence can consume content in the Power BI service. Below it, internal viewers still need Pro (Microsoft Fabric licences). This matters more for "embed for your organization" than for customer-facing apps, but it's the threshold people trip over.

What forces the next tier isn't your customer count. It's concurrency: how many report renders and dataset queries land in the same window, plus refresh jobs competing for the same capacity units. Sign 200 low-usage tenants and nothing moves. Sign four enterprise tenants whose ops teams all open dashboards at 9am Monday and you'll see throttling before you see a revenue bump.

Microsoft publishes the SKUs, the F64 threshold and a capacity-planning guide. What it doesn't publish is your tenant-growth cost curve. We think modelling that curve, peak concurrency per tenant tier, refresh windows, what you'd pause and when, belongs in the decision before the roadmap slot, not after.

When Power BI Embedded Is the Right Choice, and When a Customer-Facing Analytics Layer Fits Better

Power BI Embedded is a sound choice when the audience is your own organisation, or when you're already committed to Microsoft Fabric with Power BI skills in the building. The modelling depth is real, DAX is genuinely powerful, and if your data already lives in OneLake you'd be inventing reasons not to use it.

The calculus changes when the dashboards are a feature your customers pay for. Then the ownership list from earlier (token minting and refresh, service principal setup, row-level security roles mapped to tenant identity, theming, environment promotion) is no longer plumbing you do once. It's a runtime your team operates forever, alongside the product.

Our view: that runtime belongs to a vendor whose product is customer-facing embedding. Several platforms are purpose-built for exactly that, Embeddable among them — and it's ours, so treat that as disclosure rather than neutrality; Sigma Embedded is another example. Either way you're choosing whose layer it is, not whether there is one. It's never between a vendor and no vendor at all.

Related Reading

• Embeddable vs Power BI
• Powerbi Embedded Alternatives
• Embedded Analytics for Multi Tenant Database Architectures