Power BI Embedded: Build Analytics into Applications
Embed Power BI reports and dashboards directly into custom applications. Developer guide for tokens, SDKs, row-level security, and white-labeling.
Power BI Embedded lets you integrate interactive reports and dashboards directly into custom web applications, SaaS products, and internal portals. Instead of directing users to the Power BI Service, embedding brings analytics to where users already work—inside your application's interface with your branding and navigation.
Embedding Scenarios
Power BI supports two fundamentally different embedding approaches based on who consumes the analytics:
Embed for Your Organization (User Owns Data): End users authenticate with their own Azure AD credentials. Each user needs a Power BI Pro or Premium Per User license. The application acts as a portal that displays Power BI content the user already has access to. Best for internal applications, intranets, and portals where users are already licensed.
Embed for Your Customers (App Owns Data): The application authenticates using a service principal or master account. End users do not need Power BI licenses—capacity-based licensing covers all users. The app generates embed tokens that grant temporary access to specific reports. Best for SaaS products, customer-facing portals, and scenarios where external users should never interact with Power BI directly.
Architecture and Authentication
The embedding architecture involves three components: your application backend (generates embed tokens), the Power BI JavaScript SDK in the frontend (renders reports), and Power BI Service (hosts the reports and datasets).
Service Principal Setup: For App Owns Data scenarios, create an Azure AD app registration with Power BI Service permissions. Add the service principal to a security group enabled in the Power BI admin portal under tenant settings. The service principal needs access to the workspace containing the reports.
Embed Token Generation: Your backend calls the Power BI REST API to generate embed tokens. Tokens are short-lived (default 1 hour, configurable up to 24 hours) and scoped to specific reports, datasets, and workspaces. Always generate tokens server-side—never expose service principal credentials to the browser.
Token Lifecycle: Implement token refresh logic in your frontend. When a token approaches expiration, request a new token from your backend and update the embedded report without requiring a page reload. The JavaScript SDK provides events for handling token expiration.
JavaScript SDK Integration
The Power BI JavaScript SDK (powerbi-client) handles all rendering and interaction:
Basic Embedding: Load the SDK, create a configuration object with the embed URL, access token, and report ID, then call powerbi.embed(container, config). The SDK renders the report inside your specified DOM container.
Event Handling: Subscribe to events like loaded (report finished rendering), error (embedding failed), dataSelected (user clicked a data point), and pageChanged (user navigated to a different page). These events enable your application to respond to user interactions within the embedded report.
Filtering: Apply filters programmatically using the SDK. Set report-level, page-level, or visual-level filters based on application context. For example, automatically filter an embedded sales report to show only the logged-in customer's data without relying solely on RLS.
Row-Level Security for Multi-Tenant Embedding
RLS is critical for App Owns Data scenarios where multiple customers view the same report:
Effective Identity: When generating embed tokens, pass an effective identity that specifies the user's role and identity values. Power BI applies RLS rules based on this identity, ensuring each customer sees only their own data.
Dynamic RLS: Define RLS roles in the semantic model with DAX filters referencing USERNAME() or USERPRINCIPALNAME(). When generating embed tokens, pass the customer identifier as the effective identity. The DAX filter dynamically restricts data to that customer.
Testing: Always test RLS with the "View as Role" feature in Power BI Desktop before embedding. Verify that cross-filter interactions do not leak data between tenants. Test with edge cases like customers with no data and customers with large datasets.
Capacity Planning and Licensing
Embedded analytics requires dedicated capacity—either Power BI Embedded (A SKUs from Azure) or Power BI Premium (P SKUs):
| SKU | Cores | RAM | Concurrent Users | Monthly Cost (approx) | |---|---|---|---|---| | A1 | 1 | 3 GB | 5-25 | $750 | | A2 | 2 | 5 GB | 25-50 | $1,500 | | A4 | 4 | 10 GB | 50-200 | $3,000 | | A5 | 8 | 25 GB | 200-500 | $6,000 | | P1 | 8 | 25 GB | 500+ | $5,000 |
A SKUs vs P SKUs: A SKUs (Azure-billed) can be paused when not in use—ideal for development and testing or applications with predictable usage patterns. P SKUs (Office 365-billed) cannot be paused but include Power BI Service features for internal users. Many organizations use A SKUs for embedded customer-facing scenarios and P SKUs for internal analytics.
White-Labeling and Customization
Embedded reports can be customized to match your application's brand:
- Custom themes: Apply JSON themes that set colors, fonts, and visual defaults to match your brand
- Navigation control: Hide the default page navigation and build custom navigation in your app
- Filter pane: Hide the filter pane and build application-specific filtering UX
- Toolbar customization: Show or hide the embedded report toolbar, print, export, and bookmark controls
- CSS styling: Control the embed container dimensions, borders, and overflow behavior
Performance Optimization
- Pre-load the Power BI SDK and embed tokens before the user navigates to the analytics page
- Use phaseEmbedding to load report structure first, then render visuals progressively
- Implement dataset caching in Premium/Embedded capacity to reduce query latency
- Monitor capacity utilization with the Premium Capacity Metrics app
- Consider pagination for reports with many visuals—load one page at a time
Related Resources
Frequently Asked Questions
What is the difference between Power BI Premium and Power BI Embedded?
Power BI Premium (P SKUs) is designed for internal users within your organization. It includes full Power BI Service access, deployment pipelines, dataflows, and paginated reports. Users authenticate with Azure AD and need Pro licenses for content creation (consumers get included access through Premium capacity). Power BI Embedded (A SKUs) is designed for embedding analytics into customer-facing applications. It is billed through Azure, can be paused/resumed programmatically, and supports App Owns Data scenarios where end users do not need Power BI licenses. Key differences: P SKUs cannot be paused (always running), A SKUs can be paused (cost savings). P SKUs include admin portal features, A SKUs are managed through Azure portal. For SaaS applications serving external customers, use A SKUs. For internal portals serving employees, P SKUs are typically more cost-effective.
How do I handle embed token refresh without disrupting the user experience?
Embed tokens expire after their configured lifetime (default 1 hour). To avoid disruption, implement proactive token refresh: (1) Track token expiration time on the client side, (2) Request a new token from your backend 5-10 minutes before expiration, (3) Call report.setAccessToken(newToken) on the embedded report object—this refreshes the token without reloading the report or losing user state (filters, selections, scroll position). The JavaScript SDK also emits a tokenExpired event as a fallback—handle this event to request a new token and call setAccessToken. Never let tokens expire without refresh, as the embedded report will display an error. For high-availability scenarios, pre-fetch tokens and cache them server-side with appropriate TTL. Monitor token generation API calls to avoid throttling (limit of 50 token requests per workspace per minute).
What are the common performance problems with Power BI Embedded and how do I fix them?
Common embedded performance issues: (1) Slow initial load—report takes 5+ seconds to appear. Fix: use phaseEmbedding to show skeleton UI while loading, pre-warm capacity by keeping at least one report active, optimize the semantic model (reduce columns, implement aggregations). (2) Capacity throttling—high concurrent users cause slow queries. Fix: scale up the A/P SKU, implement query caching, reduce visual count per page (target under 8 visuals). (3) Token generation latency—backend takes 1-2 seconds per token. Fix: batch token generation for multiple reports, cache tokens with appropriate TTL, use connection pooling for API calls. (4) Cross-region latency—capacity and application in different Azure regions. Fix: co-locate capacity with your application backend. (5) Large dataset queries—DirectQuery reports slow under concurrent load. Fix: switch to Import mode or implement aggregations, use incremental refresh to keep dataset current without full reload. Monitor performance with the Premium Capacity Metrics app and Azure Application Insights integrated into your embedding application.