Power BI Embedded can make analytics feel native inside a SaaS product, customer portal, or managed-service application. It also places the application team between the end user and Power BI authorization. A wrong customer-to-profile mapping, missing effective identity, overprivileged service principal, reusable token leak, shared capacity overload, or incomplete offboarding can expose data or break every customer's reporting at once.
Datrick assesses the full product path: application authentication, authorization, token service, Power BI identities, workspaces, semantic models, RLS, data sources, capacity, frontend embedding, lifecycle automation, monitoring, and support. AI can classify telemetry, summarize configuration, group failures, and propose tests. Deterministic authorization and named engineers control token claims, customer mapping, deployments, security decisions, and production changes.
Are you embedding Power BI for external customers, adding the next hundred tenants, or unsure whether RLS and token generation fail closed? Test the architecture before scale amplifies the risk.
Define the customer-isolation contract
Identify customer types, data sensitivity, supported regions, authentication providers, user and admin personas, content customization, authoring, export, embedding surfaces, performance objectives, onboarding volume, customer deletion, legal hold, support hours, and incident authority. Define whether separation must be logical, workspace-based, capacity-based, tenant-based, or regional.
| Architecture domain | Evidence to review | Failure to prevent |
|---|---|---|
| Application identity | User authentication, customer membership, roles, session, authorization source, admin path, impersonation, and offboarding. | A valid user requests another customer's report, role, export, or administrative operation. |
| Power BI identity | Service principals, profiles, managed identities, secrets, certificates, permissions, ownership, rotation, and deletion recovery. | One credential exposes all customers, profile mapping is lost, or deleted identity breaks every workspace. |
| Content isolation | Workspaces, semantic models, reports, RLS roles, effective identities, data sources, regions, deployments, and customer mapping. | Cross-customer data access, wrong model binding, unrestricted token, or content published to the wrong workspace. |
| Token service | Server-side generation, claims, resource IDs, identity and roles, lifetime, caching, logging, authorization, rate limit, and errors. | Client-controlled claims, token replay, overbroad resources, silent fallback, or sensitive token logging. |
| Capacity and experience | SKU, model memory, concurrency, cold load, refresh, background work, peak demand, latency, throttling, scaling, and cost. | Noisy customer, slow first render, refresh starvation, overload, uncontrolled cost, or no graceful degradation. |
| Operations | Provisioning, update, backup, restore, monitoring, customer support, deployment, rollback, incident, audit, retention, and deletion. | Partial onboarding, failed upgrade, orphaned content, unrecoverable mapping, or no evidence during an incident. |
Choose the isolation model from risk and scale
A shared semantic model with RLS can simplify content maintenance and customer onboarding, but all customer data shares one model, capacity, refresh design, and security boundary. It requires correct effective identity on every embed token and strong negative tests. Microsoft notes that when service-principal token generation lacks required RLS identity information, token generation fails; do not build application fallback that converts this failure into unrestricted access.
Customer-specific workspaces and semantic models managed with service principal profiles create stronger logical containers and can distribute customers across capacities and regions. Microsoft describes profiles as first-class Power BI security principals that can own workspaces, semantic models, and credentials. The application must maintain an authoritative customer-to-profile and workspace mapping and protect profile lifecycle.
Separate service principals or Power BI tenants can create stronger blast-radius or regional boundaries at greater operational cost. Choose deliberately. Do not claim physical isolation from a workspace-based design, and do not adopt thousands of duplicated models without automation for deployment, connection updates, refresh, schema change, monitoring, and recovery.
Make the token service a security boundary
Generate embed tokens only on a trusted backend after application authorization. Derive customer, profile, workspace, report, semantic model, identity, and RLS role from server-controlled mapping, not browser input. Validate that the requesting user belongs to the customer and is allowed the requested product capability before calling Power BI APIs.
Use short-lived tokens and avoid logging token values, secrets, connection strings, or sensitive effective identities. Log safe request identifiers, customer and resource references, policy decision, profile, roles, duration, result, and correlation IDs. Rate-limit token creation, distinguish dependency failure from authorization denial, and alert on unusual cross-customer or administrative patterns.
Build an automated customer-content control plane
| Control-plane function | Responsibility | Production control |
|---|---|---|
| Customer registry | Stores authoritative customer, region, tier, profile, workspace, capacity, model, connection, content version, and lifecycle state. | Unique constraints, encryption, audit, idempotency key, state transitions, and reconciliation with Power BI. |
| Provisioning | Creates profile and workspace, assigns capacity, deploys content, sets connections, refreshes, validates, and activates the customer. | Idempotent steps, least privilege, partial-failure recovery, secret handling, readiness tests, and no activation before acceptance. |
| Token service | Authorizes user and customer, resolves resources, supplies effective identity, generates token, and returns embed configuration. | Server-side policy, fail closed, short lifetime, safe logs, rate limit, correlation, and negative tests. |
| Content delivery | Promotes report and model versions, applies customer configuration, updates bindings, refreshes, validates, and rolls back. | Source-controlled artifact, version compatibility, staged rollout, canary customers, rollback, and customer communication. |
| Capacity operations | Monitors queries, memory, refresh, overload, latency, errors, customer demand, scale, and cost. | Per-customer attribution, SLO, alert action, workload isolation, scaling policy, budget, and post-change validation. |
| Offboarding and recovery | Revokes product access, expires tokens, archives or deletes content and data by policy, removes mappings, and validates closure. | Approval, hold check, retention, recoverability, dependency check, immutable evidence, and no orphan profile or workspace. |
Operate capacity as part of the product SLO
Size from measured workloads, not registered users. Capture concurrent sessions, query and render latency, semantic-model memory, cold-load behavior, refresh duration and overlap, background jobs, peak customer patterns, report complexity, exports, and growth. Load-test representative reports with realistic filters and customer distributions.
Monitor capacity metrics alongside application telemetry so a slow embed can be traced through browser, token service, Power BI render, semantic model, DirectQuery source, gateway, or capacity. Attribute consumption to customers and workloads where architecture permits. Define overload protection, scaling, customer-tier policy, and cost guardrails before a launch event creates uncontrolled spend.
Test isolation with prohibited actions
For every representative customer and role, test allowed reports, rows, objects, exports, authoring, and administrative actions. Then attempt another customer's report ID, semantic model, workspace, profile, effective identity, role, and cached embed configuration. Test missing identity, empty role, malformed customer mapping, disabled user, offboarded customer, expired token, deleted profile, secret rotation, partial provisioning, and rollback.
Verify that authorization fails closed and produces an actionable internal event without leaking customer or infrastructure detail to the browser. Re-run negative tests after content, model, token-service, SDK, identity, workspace, and profile changes. A successful demo with two friendly users is not a multi-tenant security test.
Run performance and resilience tests for cold models, concurrent first load, refresh overlap, capacity throttling, source latency, token-service failure, Power BI service incident, deployment regression, and regional dependency. Record objective, load, configuration, result, threshold, owner, and remediation.
Run a three-to-five-week embedded architecture assessment
- Define customer, data, region, authentication, isolation, customization, scale, performance, support, and compliance requirements.
- Inventory application, token service, identities, profiles, workspaces, models, RLS, sources, capacities, deployments, monitoring, and lifecycle automation.
- Trace user-to-data authorization and customer-to-profile mapping with evidence from code, configuration, APIs, and production-like requests.
- Model isolation alternatives and quantify blast radius, automation, capacity, region, customization, and cost trade-offs.
- Run negative cross-customer, missing-identity, role, token, provisioning, offboarding, and recovery tests.
- Load-test representative customer and report patterns with refresh and background workloads.
- Validate one controlled remediation or architecture improvement with rollback and post-change testing.
- Deliver the architecture decision, threat and failure model, findings, test evidence, capacity baseline, prioritized backlog, runbooks, and target operating model.
Frequently asked questions
How do you build multi-tenant Power BI Embedded analytics?
Choose an isolation model based on security, scale, cost, regional, and operational requirements. Common patterns include a shared semantic model protected by RLS or customer-specific workspaces and semantic models managed with service principal profiles. Build a server-side token service, authoritative customer-to-profile mapping, automated onboarding and offboarding, capacity monitoring, deployment controls, and negative tests that prove one customer cannot access another customer's content or data.
Are Power BI service principal profiles required for multi-tenancy?
No. A smaller solution can use one semantic model with RLS, while service principal profiles support customer-specific workspaces and stronger logical separation at larger scale. Profiles are first-class Power BI security principals and can own content and credentials. The correct pattern depends on customer count, model size, customization, data residency, isolation, automation, and operational capability.
How do you test Power BI Embedded row-level security?
Test the complete server-side identity and token path, not only the report. For each representative customer and persona, generate an embed token with the expected identity and roles, verify allowed rows and objects, attempt prohibited cross-customer and cross-role access, test exports and downstream reports, and confirm that missing or malformed identity input fails closed. Retain token-request metadata without logging reusable secrets or tokens.
How do you size Power BI Embedded capacity?
Measure concurrent users, query and render latency, semantic-model size and memory, cold-load behavior, refresh concurrency, background work, peak customer patterns, customization, and growth. Load-test representative reports and onboarding scenarios, monitor capacity metrics, isolate noisy workloads where required, and define scaling, throttling, and cost guardrails rather than sizing from viewer count alone.
What is included in a Power BI Embedded architecture assessment?
The assessment covers authentication, authorization, service principals and profiles, customer mapping, workspaces, semantic models, RLS and effective identity, token generation, secrets and managed identity, APIs, onboarding, deployment, data sources, capacity, performance, observability, failure handling, backup and recovery, incident response, cost, regional requirements, and evidence from production-like security and load tests.
Official implementation references
- Microsoft service principal profiles for Power BI Embedded multi-tenancy
- Microsoft scalable multi-tenancy guidance for Power BI embedding
- Microsoft security guidance for Power BI Embedded analytics
- Microsoft cloud RLS guidance for embedded content
- Microsoft Power BI Embedded capacity planning guidance
Start with the authentication-to-data path and one representative customer lifecycle. Datrick can test isolation, capacity behavior, automation, and operational recovery before the next scale milestone.