Power BI Embedded: Adding Analytics to Your Application

Every SaaS application eventually needs analytics. Users want dashboards showing their usage patterns, performance metrics, and business outcomes. Building a custom analytics layer from scratch --- charting libraries, data pipelines, caching, export functionality, drill-down interactions --- takes 6-12 months of engineering effort and ongoing maintenance. Power BI Embedded offers an alternative: enterprise-grade analytics capabilities embedded directly into your application, backed by Microsoft's infrastructure.

Power BI Embedded is not simply "putting an iframe on a page." It is a full platform for delivering interactive, secure, multi-tenant analytics experiences within your own application's UI. Your customers interact with analytics that look and feel native to your product while you leverage Power BI's mature visualization engine, DAX calculation layer, and data connectivity infrastructure.

This guide covers the architecture, authentication models, multi-tenant security, capacity planning, SDK integration, and pricing considerations for embedding Power BI in your application. If you are planning an embedded analytics implementation, explore our Power BI embedded analytics services for architecture guidance and development support.

Key Takeaways

• Power BI Embedded supports two scenarios: "embed for your customers" (app owns data) and "embed for your organization" (user owns data)
• Service principal authentication is recommended for multi-tenant SaaS applications; master user accounts are simpler but create single points of failure
• Row-level security (RLS) is the primary mechanism for ensuring tenant data isolation in shared datasets
• Fabric F SKUs provide the most cost-effective capacity for embedded scenarios, starting at F2 for development
• The JavaScript SDK enables deep programmatic control: applying filters, capturing events, controlling navigation, and customizing themes
• Capacity sizing depends on concurrent users, query complexity, and data volume --- not just total user count
• Custom themes and hidden chrome make embedded reports feel native to your application

---

Embedding Scenarios: Customers vs Organization

Embed for Your Customers (App Owns Data)

The "app owns data" scenario is the primary use case for SaaS applications. Your application authenticates with Power BI using a service principal or master user account, generates an embed token, and serves the embedded report to your end users. Your customers never interact with Power BI directly and do not need Power BI licenses.

Architecture flow:

1. Your customer logs into your application using your authentication system.
2. Your application backend calls the Power BI REST API to generate an embed token, scoped to the specific report, dataset, and RLS role for that customer.
3. The backend returns the embed token and embed URL to the frontend.
4. The frontend initializes the Power BI JavaScript SDK with the embed token and renders the report in a designated container element.
5. The embed token expires after a configurable period (default 1 hour), and your application refreshes it transparently.

Key characteristics:

• Customers do not need Power BI Pro or Premium Per User licenses
• All capacity costs are borne by you (the application provider) through Fabric/Embedded SKUs
• You have full control over what users see through RLS and programmatic filtering
• Authentication is entirely within your application's auth system
• Embed tokens provide scoped, time-limited access to specific artifacts

This is the model used by ISVs, SaaS platforms, and internal portals where the analytics consumer should not know or care that Power BI is the underlying technology.

Embed for Your Organization (User Owns Data)

The "user owns data" scenario is for embedding Power BI content within internal applications where users already have Power BI licenses (Pro or PPU). The embedded experience uses the user's own Power BI identity and permissions.

Architecture flow:

1. The user authenticates with Azure AD through your application.
2. Your application acquires an access token on behalf of the user using the OAuth 2.0 on-behalf-of flow.
3. The application calls the Power BI REST API with the user's token to get embed configuration.
4. The report renders with the user's full Power BI permissions.

Key characteristics:

• Each user must have a Power BI Pro or Premium Per User license
• Users see content based on their own Power BI permissions and RLS assignments
• No additional Fabric/Embedded capacity is required (uses the user's Pro/PPU license allocation)
• Less control for the application developer, more autonomy for the user
• Simpler architecture but higher per-user licensing cost

This model is typically used for intranet portals, SharePoint integrations, and internal applications where users already have Power BI licenses and should retain their existing access permissions.

Choosing Between Scenarios

For most SaaS applications targeting external customers, "app owns data" is the correct choice. The remainder of this guide focuses primarily on this scenario.

---

Authentication: Service Principal vs Master User

Service Principal Authentication

A service principal is an Azure AD application identity that Power BI trusts to access resources programmatically. It is the recommended authentication method for production embedded applications.

Setup requirements:

1. Register an application in Azure AD.
2. Create a client secret or certificate for the application.
3. Create an Azure AD security group and add the service principal to it.
4. In the Power BI admin portal, enable service principal access for the security group under Tenant Settings > Developer Settings.
5. Grant the service principal access to the specific Power BI workspaces containing your embedded content.

Advantages:

• No dependency on a specific user account (eliminates single point of failure)
• Client secrets and certificates can be rotated without service interruption
• Service principals can be scoped to specific workspaces (least privilege)
• Works with Azure AD managed identities in Azure-hosted applications
• Supports certificate-based authentication for higher security

Limitations:

• Cannot access "My Workspace" (personal workspaces)
• Cannot call certain admin APIs
• Requires Azure AD Premium for some advanced features
• Initial setup is more complex than master user

Master User Authentication

A master user is a regular Azure AD user account with a Power BI Pro or PPU license that your application uses to authenticate with Power BI. The application logs in as this user to generate embed tokens.

Advantages:

• Simpler initial setup (create a user, assign a license, grant workspace access)
• Can access all Power BI features including admin APIs
• No Azure AD application registration required

Disadvantages:

• Single point of failure: if the user account is locked, password expires, or MFA is triggered, your application loses access to analytics
• Cannot use conditional access policies that require interactive sign-in
• Password rotation requires application updates
• Violates security best practice of not using human accounts for machine processes
• License cost for the user account

Recommendation: Use service principal authentication for all production deployments. Master user accounts are acceptable for proof-of-concept and development environments where simplicity matters more than reliability.

Token Generation and Management

Regardless of authentication method, your application generates embed tokens through the Power BI REST API. The token encapsulates the permissions for the embedded session.

Embed token considerations:

• Token lifetime: Default is 1 hour, configurable up to 24 hours. Shorter lifetimes are more secure but require more frequent refresh.
• Token scope: Each token is scoped to specific reports, datasets, and workspaces. Generate the narrowest scope possible.
• RLS identity: When using row-level security, the RLS identity (username and roles) is embedded in the token. This is how you ensure tenant isolation.
• Token refresh: Your frontend should monitor token expiration and request a new token before it expires. The JavaScript SDK provides events for this.

Token generation example flow:

POST https://api.powerbi.com/v1.0/myorg/GenerateToken
{
    "datasets": [{"id": "dataset-guid"}],
    "reports": [{"id": "report-guid"}],
    "identities": [{
        "username": "[email protected]",
        "roles": ["TenantRole"],
        "datasets": ["dataset-guid"]
    }]
}

The response contains an embed token and expiration timestamp. Your backend caches this token (respecting expiration) and serves it to authenticated frontend requests.

---

Multi-Tenant Row-Level Security

Why RLS Is Critical for Embedded

In a multi-tenant SaaS application, multiple customers' data often resides in the same Power BI dataset. Without row-level security, an embed token grants access to all data in the dataset. RLS ensures that each customer sees only their own data, even though the underlying dataset is shared.

RLS is not optional for multi-tenant embedded scenarios. A failure in tenant isolation is a data breach. Design RLS as a foundational security control, not an afterthought.

Static RLS

Static RLS defines fixed filter rules using DAX expressions in Power BI Desktop. Each role has a set of table filters that restrict which rows are visible.

Example:

A "TenantRole" with this filter on the Customers table:

[TenantId] = USERNAME()

When generating an embed token, your application sets the USERNAME() value to the current tenant's identifier. The DAX filter restricts all queries to rows where TenantId matches.

Static RLS is simple and effective for straightforward tenant isolation. It works well when:

• Tenant isolation is based on a single column (TenantId) that propagates through relationships
• All tenants see the same report structure, just filtered to their data
• The number of RLS roles is small and stable

Dynamic RLS

Dynamic RLS uses DAX expressions that evaluate at query time based on the user's identity. This enables more complex security scenarios without creating separate roles for each tenant.

Common dynamic RLS patterns:

USERPRINCIPALNAME() pattern:

[Email] = USERPRINCIPALNAME()

The embed token sets the effective identity's username to the user's email. The filter matches against an Email column in a security mapping table.

Security table pattern: Create a dedicated security table mapping users to the data they can access:

Apply RLS filters that join this security table to your fact tables through relationships. This pattern supports user-level permissions within a tenant, not just tenant-level isolation.

RLS Testing and Validation

Pre-deployment testing:

1. In Power BI Desktop, use "View As" to test each RLS role with sample usernames.
2. Verify that cross-filtering between tables respects RLS boundaries.
3. Test edge cases: users with no matching rows (should see empty reports, not errors), users with multiple roles, and null values in filter columns.
4. Verify that DAX measures using ALL() or REMOVEFILTERS() do not bypass RLS (they should not, but verify).

Production validation:

• Automate RLS testing as part of your deployment pipeline
• Generate embed tokens for test tenant identities and verify query results match expected data
• Monitor for RLS bypass attempts in capacity metrics (unusual query patterns, unexpected data volumes)
• Conduct quarterly security reviews of RLS configurations

---

Capacity Sizing and Fabric SKUs

Understanding Capacity

Power BI Embedded requires dedicated capacity --- compute resources reserved for your embedded workloads. Capacity is measured in Capacity Units (CUs), which determine the processing power available for rendering reports, executing queries, and refreshing datasets.

Capacity is not per-user. It is a shared pool of compute that all your embedded sessions draw from. This means that pricing scales with concurrency and query complexity, not with total user count.

Fabric F SKU Options

Microsoft Fabric F SKUs are the current pricing model for Power BI Embedded capacity. They replaced the legacy A SKUs with a more flexible, pause-capable model.

Important notes:

• Concurrent users does not mean total users. It means users actively querying at the same moment. A typical ratio is 5-10% of total users are concurrent at any given time.
• These are approximate guidance numbers. Actual capacity depends heavily on query complexity, model size, and visualization count per report.
• F SKUs can be paused when not in use (unlike legacy P SKUs), which is valuable for development and seasonal workloads.
• F64 and above include Power BI Premium features (paginated reports, AI, deployment pipelines) at no additional license cost.

Capacity Sizing Methodology

Step 1: Estimate concurrent users.

Concurrent users = Total users x Peak concurrency ratio

For SaaS analytics dashboards accessed during business hours: 5-10% concurrency ratio. For operational dashboards checked frequently throughout the day: 15-25% concurrency ratio. For event-driven dashboards (real-time monitoring, alerts): 30-50% concurrency ratio.

Step 2: Assess query complexity.

Simple reports (5-10 visuals, basic aggregations, single fact table): 1x baseline. Medium reports (10-20 visuals, time intelligence, multiple fact tables): 2-3x baseline. Complex reports (20+ visuals, complex DAX, large datasets, cross-source queries): 4-6x baseline.

Step 3: Calculate required capacity.

Start with the SKU that matches your concurrent user estimate from the table above. Multiply by your complexity factor. If the result exceeds the SKU's concurrent query capacity, move to the next tier.

Step 4: Validate with load testing.

Theoretical sizing is a starting point. Before production launch, conduct load testing with realistic data volumes, query patterns, and concurrency levels. Microsoft provides a Power BI Embedded capacity load testing tool for this purpose.

Step 5: Plan for growth.

Add 30-50% headroom above your current peak to accommodate growth over the next 6-12 months. F SKUs can be upgraded without downtime, so you can right-size incrementally.

Cost Optimization Strategies

• Pause development capacities during non-working hours. F SKUs billed per-second when active, free when paused. Automating pause/resume with Azure Automation or Logic Apps can reduce development costs by 60-70%.

• Optimize models before scaling capacity. A well-optimized model on F8 often outperforms a poorly optimized model on F32. Invest in model optimization before throwing compute at performance problems.

• Use aggregation tables for large datasets. Pre-aggregating data at common granularities (daily, weekly, monthly) reduces query processing by 80-90% for summary-level visuals while preserving drill-down capability for detail.

• Implement report-level caching through the Power BI REST API. For dashboards with infrequent data updates, cached results reduce capacity consumption per user session.

• Consider separate capacities for different workloads. Isolating refresh operations from interactive queries prevents refresh spikes from degrading user experience. This is particularly important if you have large datasets that refresh during business hours.

---

JavaScript SDK Integration

Basic Embedding

The Power BI JavaScript SDK (powerbi-client) provides the programmatic interface for embedding and controlling Power BI content in your web application.

Installation:

npm install powerbi-client

Basic embed flow:

import * as pbi from 'powerbi-client';

const powerbi = new pbi.service.Service(
    pbi.factories.hpmFactory,
    pbi.factories.wpmpFactory,
    pbi.factories.routerFactory
);

const embedConfig = {
    type: 'report',
    id: reportId,
    embedUrl: embedUrl,
    accessToken: embedToken,
    tokenType: pbi.models.TokenType.Embed,
    settings: {
        panes: {
            filters: { visible: false },
            pageNavigation: { visible: true }
        },
        background: pbi.models.BackgroundType.Transparent,
        layoutType: pbi.models.LayoutType.Custom,
        customLayout: {
            displayOption: pbi.models.DisplayOption.FitToWidth
        }
    }
};

const reportContainer = document.getElementById('report-container');
const report = powerbi.embed(reportContainer, embedConfig);

Programmatic Control

The SDK exposes extensive programmatic control over the embedded report:

Applying filters:

const filter = {
    $schema: "http://powerbi.com/product/schema#basic",
    target: {
        table: "Sales",
        column: "Region"
    },
    operator: "In",
    values: ["North", "South"],
    filterType: pbi.models.FilterType.BasicFilter
};

await report.setFilters([filter]);

Capturing events:

report.on('loaded', function() {
    console.log('Report loaded successfully');
});

report.on('dataSelected', function(event) {
    const data = event.detail;
    // Handle user selection — navigate to detail page, update other UI, etc.
});

report.on('pageChanged', function(event) {
    const pageName = event.detail.newPage.displayName;
    // Track page navigation in your analytics
});

Token refresh:

report.on('tokenExpired', async function() {
    const newToken = await fetchNewEmbedToken();
    await report.setAccessToken(newToken);
});

Navigation control:

// Navigate to a specific page
const pages = await report.getPages();
const targetPage = pages.find(p => p.displayName === 'Revenue Analysis');
await targetPage.setActive();

// Set a specific slicer value
const visuals = await targetPage.getVisuals();
const slicer = visuals.find(v => v.type === 'slicer');
await slicer.setSlicerState({
    filters: [{
        $schema: "http://powerbi.com/product/schema#basic",
        target: { table: "Date", column: "Year" },
        operator: "In",
        values: [2026],
        filterType: pbi.models.FilterType.BasicFilter
    }]
});

Phased Rendering for Performance

For complex reports with many visuals, phased rendering improves perceived performance by rendering above-the-fold content first:

const embedConfig = {
    // ... standard config
    settings: {
        // ... other settings
        commands: [{
            visualRendered: {
                phase: 1,
                visualNames: ['revenue-kpi', 'trend-chart', 'summary-table']
            }
        }]
    }
};

report.on('visualRendered', function(event) {
    if (event.detail.phase === 1) {
        // Hide loading spinner, show report
        document.getElementById('loading').style.display = 'none';
    }
});

---

Custom Themes and Branding

Why Custom Themes Matter

Default Power BI visuals use Microsoft's color palette and styling. In an embedded context, this creates visual inconsistency with your application. Custom themes align the embedded analytics with your product's design system, making the experience feel native rather than bolted on.

Theme JSON Structure

Power BI themes are defined as JSON files with control over colors, fonts, visual defaults, and element styling:

{
    "name": "MyApp Theme",
    "dataColors": [
        "#2563EB", "#7C3AED", "#059669", "#D97706",
        "#DC2626", "#0891B2", "#4F46E5", "#65A30D"
    ],
    "background": "#FFFFFF",
    "foreground": "#1E293B",
    "tableAccent": "#2563EB",
    "textClasses": {
        "callout": {
            "fontSize": 28,
            "fontFace": "Inter, sans-serif",
            "color": "#0F172A"
        },
        "title": {
            "fontSize": 14,
            "fontFace": "Inter, sans-serif",
            "color": "#1E293B"
        },
        "header": {
            "fontSize": 12,
            "fontFace": "Inter, sans-serif",
            "color": "#475569"
        },
        "label": {
            "fontSize": 11,
            "fontFace": "Inter, sans-serif",
            "color": "#64748B"
        }
    },
    "visualStyles": {
        "*": {
            "*": {
                "border": [{
                    "color": {"solid": {"color": "#E2E8F0"}},
                    "radius": 8
                }],
                "background": [{
                    "color": {"solid": {"color": "#FFFFFF"}},
                    "transparency": 0
                }]
            }
        }
    }
}

Applying Themes Programmatically

Themes can be applied at embed time or dynamically switched (useful for dark mode support):

// Apply theme at embed time
const embedConfig = {
    // ... standard config
    theme: { themeJson: customThemeJson }
};

// Switch theme dynamically (e.g., light/dark mode toggle)
await report.applyTheme({ themeJson: darkThemeJson });

Hiding Power BI Chrome

For a fully native appearance, hide Power BI's built-in UI elements and replace them with your own application controls:

const settings = {
    panes: {
        filters: { visible: false },      // Hide filter pane
        pageNavigation: { visible: false } // Hide page tabs
    },
    bars: {
        actionBar: { visible: false },     // Hide action bar
        statusBar: { visible: false }      // Hide status bar
    },
    background: pbi.models.BackgroundType.Transparent,
    visualRenderedEvents: true
};

Then build custom navigation, filtering, and export controls in your application's UI framework. Use the JavaScript SDK to programmatically apply filters, change pages, and trigger exports when users interact with your custom controls.

This approach requires more development effort but produces a seamless experience where users cannot distinguish between your application's native features and the embedded Power BI content.

---

Performance Optimization for Embedded

Frontend Performance

• Lazy load the SDK. The Power BI JavaScript SDK is approximately 300KB. Load it asynchronously and only when the user navigates to an analytics page.
• Preload embed tokens. Generate embed tokens before the user requests the report. If your application knows the user will likely view analytics (based on navigation patterns), preload the token during page transitions.
• Use bootstrap embedding. The SDK supports a bootstrap pattern that initializes the iframe before the embed token is available, reducing perceived load time by 200-500ms.

// Bootstrap first (fast — creates iframe immediately)
const report = powerbi.bootstrap(container, { type: 'report' });

// Load later when token is available
const embedConfig = { /* full config */ };
report.load(embedConfig);

• Implement report caching. Once a report is loaded, the iframe retains it in memory. If the user navigates away and returns, reuse the existing iframe instead of re-embedding. This eliminates the load time entirely for return visits within the same session.

Backend Performance

• Cache embed tokens. Embed tokens are valid for their full lifetime (default 1 hour). Cache them in Redis or in-memory and reuse across requests for the same report/identity combination.
• Batch token generation. If a user's dashboard contains multiple embedded reports, generate all embed tokens in a single API call using the GenerateToken endpoint's multi-resource capability.
• Monitor API rate limits. The Power BI REST API has rate limits per service principal. Monitor 429 responses and implement exponential backoff. For high-scale applications, distribute load across multiple service principals.

Report Design for Embedded

Reports designed for embedded consumption should prioritize performance over visual complexity:

• Limit visuals to 8-12 per page (each visual generates a separate query)
• Use Import mode instead of DirectQuery when possible (10-100x faster)
• Pre-aggregate data at the appropriate granularity
• Avoid complex DAX measures on landing pages (save them for drill-through details)
• Use bookmarks for pre-computed views instead of dynamic calculations
• Test report load times at your expected concurrency level, not just single-user

For organizations implementing embedded analytics, ECOSIRE provides architecture consulting and development services to ensure optimal performance from day one.

---

Security Considerations for Embedded

Token Security

Embed tokens grant access to Power BI content. Treat them as sensitive credentials:

• Never expose embed tokens in client-side source code or URL parameters
• Generate tokens server-side and deliver them through authenticated API endpoints
• Use the shortest practical token lifetime (default 1 hour is reasonable for most applications)
• Implement token refresh logic rather than generating long-lived tokens
• Monitor token generation patterns for anomalies (unusual volume, unexpected report IDs)

Tenant Isolation Validation

For multi-tenant applications, validate tenant isolation continuously:

• Automated tests that generate embed tokens for Tenant A and verify Tenant B's data is not accessible
• Query logging to detect cross-tenant data access attempts
• Regular RLS configuration audits (RLS roles can be modified in Power BI Desktop and accidentally weakened)
• Alerting on RLS filter errors (which might indicate misconfiguration)

Network Security

• Restrict Power BI REST API access to known IP ranges using Azure AD Conditional Access
• Use private endpoints for gateway connections to on-premises data sources
• Enable audit logging in the Power BI admin portal to track all API calls and embed token generation
• Implement Content Security Policy headers to restrict iframe embedding to your application's domain

---

FAQ

How much does Power BI Embedded cost for a SaaS application with 10,000 users?

The cost depends on concurrent users, not total users. If 5% of your 10,000 users are concurrent at peak (500 concurrent users), you would need approximately F32 capacity at roughly $8,200 per month (pay-as-you-go). With a reservation (1-year commitment), this drops to approximately $5,500 per month. Your actual cost could be higher or lower depending on report complexity, dataset size, and usage patterns. Start with F8 for a pilot, load test with realistic concurrency, and scale based on actual measurements.

Can I use Power BI Embedded without Azure?

Power BI Embedded requires Azure AD for authentication and Fabric/Embedded capacity provisioned through Azure. Your application itself can be hosted anywhere (AWS, GCP, on-premises), but the Power BI resources must be in Azure. The service principal or master user account must be in Azure AD, and the capacity must be an Azure resource. For organizations with no existing Azure footprint, the setup adds approximately 2-4 hours of Azure configuration work and minimal ongoing Azure management beyond the capacity itself.

What is the difference between Power BI Embedded A SKUs, EM SKUs, and Fabric F SKUs?

A SKUs were the original Power BI Embedded capacity, provisioned through Azure. EM SKUs were a licensing option for internal embedding with Office 365. Both have been superseded by Fabric F SKUs, which provide a unified capacity model for all Power BI and Fabric workloads. F SKUs offer per-second billing, pause/resume capability, and a simpler pricing structure. For new implementations, use F SKUs exclusively. Existing A SKU customers should plan migration to F SKUs for better pricing and capabilities.

Can users export data from embedded reports?

Yes, but you control this through the embed settings. The JavaScript SDK allows you to enable or disable export capabilities (Export to Excel, PDF, PowerPoint) per report. You can also implement custom export functionality through the Export API, which gives you more control over format, filters applied, and audit logging. For sensitive data, disable built-in export and provide your own export mechanism that applies additional authorization checks and watermarking.

How do I handle report development in an embedded scenario?

Report development follows the standard Power BI workflow: build reports in Power BI Desktop, publish to a development workspace, test with sample embed tokens, promote to production through deployment pipelines. The key difference is that embedded reports need additional testing for RLS behavior, performance under concurrency, responsive layout across screen sizes, and interaction with your application's UI. Establish a CI/CD pipeline that includes automated RLS validation and performance regression testing as part of every report deployment.