Power BI Embedded Analytics: The Enterprise Guide to Pricing, Architecture, and Multi-Tenant Implementation

What Is Power BI Embedded Analytics?

Power BI Embedded takes the full power of Power BI — interactive reports, dashboards, paginated reports, Q&A natural language queries, and AI-powered insights — and renders them inside your own applications. Your users interact with analytics as a seamless part of your product experience, not as a separate Microsoft tool.

The business case is compelling: instead of building custom charting and analytics from scratch (which takes months and produces inferior results), you leverage Power BI's mature visualization engine and embed it into your application in weeks. SaaS companies use it to provide analytics dashboards to their customers. Healthcare organizations embed clinical dashboards into their EHR portals. Financial institutions embed risk analytics into their trading platforms. At EPC Group, our Power BI consulting practice has delivered over 200 embedded analytics projects for enterprise clients.

Key Capabilities

• Interactive reports: Full Power BI report interactivity — filters, slicers, cross-highlighting, drill-through, drill-down, bookmarks, and tooltips — all rendered within your application.
• Paginated reports: Pixel-perfect, print-ready reports for invoices, statements, regulatory filings, and other formatted outputs. Export to PDF, Excel, Word, and PowerPoint.
• Q&A visual: Natural language query capability that allows users to ask questions about their data in plain English and receive instant visualizations.
• Real-time streaming: Push datasets for real-time dashboards showing live operational data (factory floor, call center, IoT telemetry).
• White-labeling: Custom themes, hidden Power BI branding, your own navigation and layout. Users never see the Power BI brand unless you choose to show it.
• No per-user licensing: End users accessing embedded content do not need Power BI Pro or Premium Per User licenses. The application owner pays for capacity, not per-user seats.

Embedding Models: App Owns Data vs. User Owns Data

The first architectural decision for any embedded analytics project is the embedding model. This determines how authentication works, who pays for licensing, and what level of control you have over the user experience.

Pricing Deep Dive: Azure A-SKUs vs. Fabric F-SKUs

Power BI Embedded pricing is capacity-based — you purchase compute resources (v-cores and memory) rather than per-user licenses. The cost depends on the SKU tier, usage duration, and whether you pause capacity during off-hours.

Azure Power BI Embedded (A-Series)

Microsoft Fabric Capacities (F-Series)

Fabric F-series capacities are the future of Power BI Embedded. They offer unified billing with other Fabric workloads, Direct Lake mode for dramatically faster performance, and all Power BI Premium features at F64 and above.

Capacity Planning and Sizing

Under-sizing capacity causes slow report loads and failed renders. Over-sizing wastes budget. Proper capacity planning uses real workload data to right-size the SKU. EPC Group follows a structured approach refined across 200+ embedded analytics projects.

Sizing Factors

• Concurrent users: The number of users actively viewing reports at the same time. A report load consumes capacity units (CUs). Peak concurrent users determines the minimum capacity needed. 50 concurrent users on moderately complex reports requires approximately F32/A3 capacity.
• Dataset size and complexity: Larger datasets consume more memory. Complex DAX measures consume more CPU during query execution. A 5 GB dataset with time intelligence calculations requires significantly more capacity than a 500 MB dataset with simple aggregations.
• Report complexity: Reports with 20+ visuals, complex filters, and cross-report drill-through require more rendering capacity than simple single-page reports with 5-6 visuals.
• Refresh frequency: Scheduled dataset refreshes consume capacity. Hourly refreshes of a 2 GB dataset require more capacity than daily refreshes of a 200 MB dataset. Plan refresh windows during off-peak user hours.
• Number of workspaces and datasets: Each active dataset loaded into memory consumes RAM. Many small datasets can exceed a single large dataset in aggregate memory consumption.

Sizing Methodology

1. Baseline measurement: Deploy reports to a dev/test capacity (F2 or A1). Use the Microsoft Fabric Capacity Metrics app to measure CU consumption per report load, per refresh, and per user session.
2. Load testing: Simulate expected concurrent users using the Power BI Embedded Load Testing tool or custom load tests with Playwright. Record peak CU consumption and render latency at target concurrency.
3. Size selection: Choose a capacity where peak load consumes no more than 60% of available CUs (leaving 40% headroom for spikes). If peak load requires 40 CUs, select F64 (64 CUs) rather than F32 (32 CUs).
4. Autoscale configuration: Configure Fabric autoscaling to handle temporary spikes beyond the base capacity. Set a maximum scale-up limit to control costs.
5. Monitor and adjust: Use the Capacity Metrics app in production to track utilization trends. Right-size quarterly based on actual usage data.

Enterprise Architecture Patterns

Enterprise embedded analytics requires a robust architecture that handles authentication, embed token generation, report rendering, and data refresh across multiple environments. The architecture varies based on the embedding model (App Owns Data vs. User Owns Data) and the application technology stack.

App Owns Data Architecture

User Browser
│
├── Your Web Application (React, Angular, Next.js, etc.)
│   ├── Report container (div element)
│   └── Power BI JavaScript SDK (powerbi-client)
│       └── Calls: embedReport(config) with embed token
│
├── Your Backend API (Node.js, .NET, Python, etc.)
│   ├── Authenticates the user (your auth system)
│   ├── Determines which report/dataset the user can access
│   ├── Calls Power BI REST API to generate embed token
│   │   ├── Includes RLS identity (tenant ID, role)
│   │   └── Sets token expiry (1 hour default)
│   └── Returns embed URL + embed token to frontend
│
└── Power BI Service / Fabric
    ├── Workspace(s) with reports and datasets
    ├── Service principal authentication (certificate)
    ├── Capacity (A-SKU or F-SKU)
    └── Data sources (Azure SQL, Synapse, OneLake, etc.)

Embed Token Management

Embed tokens are the security credentials that authorize report rendering in the client browser. Token management is critical for both security and performance. Our Power BI implementation guide covers the broader governance considerations.

• Server-side generation: Always generate embed tokens on your backend server, never in client-side JavaScript. The service principal credentials must never be exposed to the browser.
• Token caching: Cache embed tokens on the server for their validity period (default 1 hour). Multiple users accessing the same report with the same RLS identity can share a cached token, reducing API calls to the Power BI REST API by 80-90%.
• Token refresh: The Power BI JavaScript SDK supports automatic token refresh. Register a token expiration handler that calls your backend for a new token before the current one expires, providing seamless user experience without page reloads.
• Scoped tokens: Generate tokens with the minimum required permissions. A view-only user should receive a token without edit or create permissions. A report editor should receive a token scoped to a specific workspace.

Multi-Tenant SaaS Embedding

Multi-tenant embedding is the most architecturally complex and commercially valuable Power BI Embedded pattern. SaaS companies embed analytics into their product to differentiate from competitors, increase customer stickiness, and generate additional revenue. The two primary approaches are RLS-based isolation and workspace-per-tenant isolation.

Approach 1: Single Workspace with Row-Level Security

• Architecture: One workspace, one dataset, one set of reports. All tenants' data lives in the same dataset. RLS filters data to the current tenant based on a TenantID column in every fact and dimension table.
• Pros: Simple to manage (one dataset, one refresh schedule), cost-effective (shared capacity), easy to deploy new reports to all tenants simultaneously.
• Cons: All tenants share the same data model and reports (limited per-tenant customization), dataset size grows with tenant count, one large tenant can impact refresh performance for all tenants.
• Best for: Up to 50 tenants with similar data structures and report requirements.

Approach 2: Workspace-Per-Tenant

• Architecture: Each tenant gets their own workspace with isolated datasets and reports. A provisioning pipeline creates new workspaces from templates when new tenants onboard.
• Pros: Complete data isolation (required by some compliance frameworks), per-tenant customization of reports and data models, independent refresh schedules, no noisy-neighbor dataset impact.
• Cons: Higher operational complexity (managing hundreds of workspaces), higher capacity requirements (each workspace loads datasets independently), more complex deployment pipeline for report updates.
• Best for: 50+ tenants, strict compliance isolation requirements (HIPAA, SOC 2), tenants requiring unique data models or report customizations.

Power BI JavaScript SDK Integration

The Power BI JavaScript SDK (powerbi-client) is the client-side library that renders embedded reports in the browser. It provides programmatic control over the embedded report's behavior — applying filters, navigating pages, capturing events, and controlling the user experience.

Key SDK Capabilities

• Embed configuration: Control report settings at embed time — show/hide filter pane, navigation pane, toolbar buttons. Set the default page, apply initial filters, and choose the visual layout mode (fit-to-page, fit-to-width, actual size).
• Event handling: Listen for user interactions — report loaded, page changed, data selected, visual clicked, button clicked. Use these events to trigger application actions (navigate to a detail page when a user clicks a data point, update application state when filters change).
• Programmatic control: Apply filters, set slicer state, navigate pages, export data, print, and enter/exit full screen from your application code. Build custom navigation and filter panels that drive the embedded report.
• Phased embedding: Bootstrap the report container immediately (shows loading skeleton), then load data in a second phase. This technique improves perceived performance by showing UI structure before data is ready.

Security: RLS, OLS, and Embed Tokens

Security is the most critical aspect of embedded analytics. A misconfigured RLS role or improperly generated embed token can expose one customer's data to another — a catastrophic breach for SaaS companies and compliance-regulated organizations. EPC Group applies the same security rigor to embedded analytics that we bring to our data governance practice.

Row-Level Security (RLS) for Embedding

RLS in embedded analytics works differently than RLS in the Power BI service. In the Power BI service, RLS uses the signed-in user's identity to determine the role. In App Owns Data embedding, the application specifies the user's identity and role in the embed token generation request. The service principal authenticates to Power BI, but the embed token carries the effective identity that the RLS rules evaluate against.

• Effective identity: When generating the embed token, specify the RLS username (e.g., the tenant ID or user email) and the roles to apply. The Power BI engine evaluates DAX RLS filters using this identity.
• Static RLS: DAX filter expressions are defined in the data model and evaluate against the effective identity. Example: [TenantID] = USERNAME() where USERNAME() returns the effective identity from the embed token.
• Dynamic RLS: A security table maps users to their allowed data scope. The DAX filter joins the security table to the fact tables, enabling complex permission structures (one user can access multiple tenants, regional restrictions, etc.).

Object-Level Security (OLS)

OLS hides entire tables or columns from specific roles. This is valuable when different customer tiers should see different data dimensions — a basic tier sees revenue and units, while a premium tier also sees cost and margin columns. OLS is defined in the data model using Tabular Model Scripting Language (TMSL) and enforced through the embed token's role assignment.

Microsoft Fabric and Direct Lake

Microsoft Fabric represents the future of Power BI Embedded. Fabric F-series capacities unify Power BI with data engineering, data science, and real-time analytics on a single platform. For embedded analytics, the most impactful Fabric feature is Direct Lake mode. See our Fabric vs. Databricks comparison and our Fabric consulting services for broader Fabric guidance.

Direct Lake Mode

Direct Lake combines the performance of Import mode with the real-time freshness of DirectQuery. Instead of importing data into Power BI's in-memory engine (which requires scheduled refreshes and duplicates data), Direct Lake reads Parquet files directly from OneLake storage. There is no data copy, no refresh schedule, and no import delay. When the underlying data in OneLake updates, reports reflect the changes immediately.

• Performance: Direct Lake achieves 80-90% of Import mode performance (compared to DirectQuery which is typically 5-10x slower than Import). For most embedded analytics workloads, the performance difference is imperceptible to users.
• No refresh needed: Eliminates the need for scheduled refreshes, which consume capacity and introduce data latency. This is particularly valuable for embedded analytics where customers expect near-real-time data.
• Cost savings: No data duplication between the data lake and Power BI means lower storage costs. No refresh cycles mean more available capacity for report rendering.

Performance Optimization

Embedded report performance directly impacts user experience and customer satisfaction. A report that takes 8 seconds to load loses users. A report that renders in under 2 seconds drives engagement. Performance optimization operates at multiple layers.

• Data model optimization: Use star schema design with proper relationships. Reduce cardinality on columns used in filters and slicers. Remove unused columns from the model. Use measures instead of calculated columns for aggregations. See our Power BI best practices guide.
• Report design: Limit visuals per page to 8-12 (each visual generates a separate query). Use bookmarks for different analytical views instead of cramming everything on one page. Defer visual loading for below-the-fold visuals.
• DAX optimization: Avoid FILTER() on large tables (use CALCULATE with filter arguments instead). Minimize use of SUMX and other iterator functions on large datasets. Use variables to avoid redundant calculations. Test with DAX Studio and Performance Analyzer.
• Embed configuration: Use phased embedding (bootstrap then load). Set tokenType to Embed (not Aad) for App Owns Data. Preload embed tokens before user navigates to the report page. Cache embed config on the client to avoid backend round trips on subsequent loads.
• Capacity tuning: Schedule dataset refreshes during off-peak hours. Ensure sufficient memory headroom for dataset loading. Monitor the overload metric in the Capacity Metrics app — sustained overload causes report throttling and slow rendering.

Partner with EPC Group

EPC Group has delivered over 200 Power BI Embedded analytics projects for enterprise organizations and SaaS companies. Our Power BI consulting team designs and implements embedded analytics solutions that handle millions of monthly report views with sub-second rendering performance. We specialize in multi-tenant SaaS embedding, HIPAA-compliant healthcare analytics, and financial services dashboards with complex security requirements. From architecture design through production optimization, EPC Group delivers embedded analytics that becomes a competitive advantage for your product.