Embed Power BI in your SaaS app or portal

Two embedding models, and which one you need

Power BI supports two distinct embedding scenarios, and choosing correctly shapes everything else. Embed for your customers — often called app-owns-data — is the model for external-facing software. Your application authenticates to Power BI with a single service principal, owns the content, and decides who sees what. Your users never sign in to Power BI and do not need individual licenses; from their perspective the analytics are simply part of your product. This is the right model for a SaaS feature, a client portal, or any white-label dashboard you sell or give to customers.

Embed for your organization — user-owns-data — is the model for internal applications where every viewer already has a Power BI account. Each person signs in with their own identity and their existing permissions apply. It suits an internal portal or intranet where you simply want reports surfaced in a convenient place rather than re-architecting access. Most of the projects we are asked to build are customer-facing, so the rest of this page focuses on app-owns-data, but we will tell you plainly which fits your case on the first call.

Capacity and SKUs: the engine behind the embed

Customer-facing embedding runs on dedicated capacity — a reserved pool of compute that renders and queries your reports. There are two ways to buy it. Classic Power BI Embedded A SKUs are provisioned in Azure and can be paused when idle, which suits predictable or bursty workloads. Microsoft Fabric F SKUs are the newer unified option and also carry the embedding workload, with the added benefit of the wider Fabric platform if you grow into it. In both cases you size capacity to concurrency and report complexity, not to a headcount of viewers — adding customers does not add license cost, it adds load that a correctly sized SKU absorbs.

We do not quote capacity figures here because Microsoft adjusts them, and the right SKU depends on your usage pattern. We help you estimate concurrency, pick the SKU family, and plan pause-and-scale so you are neither overpaying nor throttled. For current rates, see Microsoft’s Power BI pricing page (opens in new tab) and the embedded capacity documentation (opens in new tab).

Multi-tenant security: every customer sees only their data

When one report serves many customers, data isolation is the requirement everything hinges on. We implement row-level security in the data model, defining roles whose filters scope the data to a tenant. At runtime your back end passes the viewer’s identity and role into the embed token, and the capacity applies those filters server-side before any data leaves Microsoft’s infrastructure. Because the filtering happens on the server, a browser cannot request rows it is not entitled to — there is no client-side rule to bypass. We treat isolation as something to prove, not assume, so we test it by impersonating multiple tenants and confirming each one sees strictly its own slice. For platforms with many tenants we can also use dynamic RLS driven by a mapping table, so onboarding a new customer does not mean editing the model.

The embedding toolkit: REST API and the JavaScript client

Two Microsoft technologies do the heavy lifting. The Power BI REST API is how your server talks to Power BI: it provisions workspaces, deploys report content, manages datasets and refresh, and — critically — generates the embed tokens that authorize each session. We build a small, secure server-side service around it so the service principal credentials and tokens stay on your back end and never touch the browser. The powerbi-client JavaScript library then renders the report in your page, where we control layout, page navigation, filters, bookmarks, and which controls are visible, and listen for events so the embedded report can interact with the rest of your UI. Together they let analytics behave like a first-class feature: filtered by context, styled to your brand, and driven by your application’s own logic.

Where embedded analytics fit best

The strongest use cases share a shape: many viewers, each entitled to a slice of the same model, who should never see Power BI itself. A SaaS analytics feature turns reporting into a differentiator — or a paid tier — without your team building a charting engine. A client or customer portal lets each account log in and see its own performance, usage, or billing in real time. A white-label dashboard lets agencies, franchises, or platforms deliver branded analytics to their own clients. In every case embedding spares you from rebuilding what Power BI already does well, and lets your engineers spend their time on the product instead.

Deliverables, pricing, timeline, and support

You receive the full working integration: the data model with its RLS roles, the server-side token service, the front-end embedding code, your applied theme, and documentation plus a capacity runbook so your developers can add reports and operate the system without us. Like all our work this runs on prepaid Flex hours — you buy a block of senior-led hours, we scope the integration into tasks, and hours are deducted only for work you approve. On a short call we clarify your app, tenancy, and reports, then send a written scope and an estimate of the hours each task needs. Most individual tasks are delivered within 3–5 business days of your approval; a focused first integration is a small set of those tasks, and broader rollouts get a clear timeline up front. Your prepaid Flex hours cover this, and they never expire — see Flex pricing. After launch you can run everything yourself, or keep drawing on your hours for ongoing support as you add reports and scale. If you are still deciding how embedding fits your broader BI plan, our Power BI consulting sets direction, dashboard development builds the reports you will embed, and how it works explains our process and pricing end to end. Where the data platform underneath needs work too, our Microsoft Fabric consulting covers lakehouse, pipelines, and Direct Lake.