Power BI Embedded for SaaS: Architecture and Pricing Guide

1. Licensing and Capacity Options

Three capacity SKUs support embedding: Fabric F SKUs, legacy A SKUs (Azure Power BI Embedded), and Premium P SKUs. In 2026 the guidance is straightforward: use F SKUs for new deployments.

For more on P-to-F migration, see the Fabric vs Premium migration guide.

2. Reference Architecture

The standard SaaS embedding architecture has six components:

• SaaS front-end: React, Angular, or plain JavaScript using the Power BI JavaScript SDK.
• Token-issuance service: server-side endpoint that authenticates as a service principal and returns an embed token.
• Service principal: Microsoft Entra application with a client secret or certificate, granted Power BI Service Admin tenant role and Contributor on the target workspace.
• Workspace: container for datasets, reports, and dashboards. For most deployments, one or a few workspaces are sufficient.
• Dataset with dynamic RLS: semantic model with a UserSecurity bridge table filtered by a tenant_id claim passed through the embed token.
• Fabric F SKU capacity: Azure-provisioned capacity backing all customer-facing content.

3. Authentication Pattern: Service Principal + Embed Tokens

// Node.js token issuance example
import { ConfidentialClientApplication } from '@azure/msal-node';
import axios from 'axios';

const msal = new ConfidentialClientApplication({
  auth: {
    clientId: process.env.PBI_CLIENT_ID!,
    clientSecret: process.env.PBI_CLIENT_SECRET!,
    authority: `https://login.microsoftonline.com/${process.env.PBI_TENANT_ID}`,
  },
});

export async function generateEmbedToken(
  reportId: string,
  datasetId: string,
  tenantId: string
) {
  const accessToken = await msal.acquireTokenByClientCredential({
    scopes: ['https://analysis.windows.net/powerbi/api/.default'],
  });

  const response = await axios.post(
    `https://api.powerbi.com/v1.0/myorg/groups/${WORKSPACE_ID}/reports/${reportId}/GenerateToken`,
    {
      accessLevel: 'View',
      identities: [
        {
          username: `tenant-${tenantId}`,
          roles: ['TenantRole'],
          datasets: [datasetId],
        },
      ],
    },
    { headers: { Authorization: `Bearer ${accessToken!.accessToken}` } }
  );

  return response.data.token;
}

The identities array passes the effective identity for RLS enforcement. The username field feeds USERPRINCIPALNAME() in the RLS DAX expression and serves as the tenant key. Cache embed tokens for 55 minutes (tokens expire after 60 minutes) to minimize Entra round-trips.

4. Multi-Tenant Isolation

Option A: Dataset-per-tenant with dynamic RLS (recommended for most SaaS)

One shared dataset contains all tenants’ data. A UserSecurity table maps tenant IDs to row filters. The dynamic RLS expression filters every table by tenant ID based on the identity passed in the embed token. Scales to tens of thousands of tenants on a single dataset.

Option B: Workspace-per-tenant

Each customer gets their own workspace with their own dataset. Strongest possible isolation. Use for enterprise customers that require physical separation for compliance reasons. Does not scale beyond a few hundred workspaces due to operational complexity.

Option C: Hybrid

Default customers share a dataset with dynamic RLS. Enterprise tier customers get dedicated workspaces. The provisioning pipeline determines at signup time which pattern a customer uses based on their subscription plan.

5. Cost Model and Capacity Sizing

Capacity sizing depends on three variables: concurrent user load, query complexity, and refresh frequency. A useful starting point:

• F4 or F8: up to 100 concurrent users with simple report queries. ~$400 to $800 per month PAYG.
• F16: up to 500 concurrent users. ~$1,300 per month PAYG.
• F32: up to 2,000 concurrent users. ~$2,630 per month PAYG.
• F64: up to 10,000 concurrent users. ~$5,258 per month PAYG.

These numbers assume typical dashboard traffic (one or two visual interactions per user per minute during active sessions). Heavy analytic workloads can reduce user capacity by 30 to 50 percent. Monitor the Fabric Capacity Metrics app and scale up when sustained utilization exceeds 70 percent during peak hours.

6. Performance Best Practices

• Cache embed tokens server-side for 55 minutes. Do not request a new token on every page navigation.
• Use Direct Lake mode for large fact tables. It delivers Import-mode performance without refresh schedules.
• Pre-warm capacity before predictable traffic peaks (Monday morning, billing cycles) with synthetic queries.
• Separate development workspaces from customer-facing workspaces. Development refreshes should not contend with end-user queries.
• Enable auto-scale with a hard ceiling. Budget guardrails prevent runaway costs during anomalous traffic.
• Design visuals with paginated data (top 10 customers, last 30 days) rather than unbounded tables. Pagination dramatically reduces CU consumption.

Frequently Asked Questions