Power BI Embedding for Multi-Tenant Apps - Service Principal Profiles Explained
If you're building a SaaS product that needs embedded analytics, or you're an enterprise with dozens of internal business units that each need their own reporting, Power BI embedding is probably on your radar. And if you've started down that path, you've likely hit the question that trips up almost every team we work with - how do you scale this to hundreds or thousands of tenants without everything falling over?
The answer, as of the last couple of years, is service principal profiles. But the documentation around this feature is dense, and the architecture decisions you make early on will either save you or haunt you for years. Let me walk through what actually matters.
The Two Embedding Scenarios
Before anything else, you need to understand which embedding model you're using, because it changes everything.
Embed for your organisation is when your users already have Microsoft 365 or Power BI licences. They sign in with their organisational account, and Power BI handles the authentication. This is the simpler model - you're basically embedding Power BI reports inside your own app, but the users are known to Microsoft Entra ID. Microsoft calls this "User owns data."
Embed for your customer is the ISV model. Your users don't have Power BI licences and don't sign in with Microsoft accounts. Your application handles authentication entirely, and behind the scenes you use an embedding identity (a service principal or master user account) to call the Power BI APIs and serve up the reports. Microsoft calls this "App owns data."
Service principal profiles are designed specifically for the second scenario - Embed for your customer. If you're doing Embed for your organisation, this whole article is probably not relevant to you. But if you're building a product that serves external customers - or even internal business units that you treat as separate tenants - read on.
Why Service Principals Alone Aren't Enough
Here's the thing nobody tells you early enough. A service principal in Power BI has a soft limit of 1,000 workspaces. Not a hard technical limit - Power BI won't stop you from adding workspace 1,001. But once you pass about 1,000, API performance starts degrading. Microsoft considers anything above that number as "unsupported," which means if things go sideways, good luck getting help from their support team.
The reason is architectural. Power BI maintains an access control list (ACL) for each identity. Every time your service principal makes an API call, Power BI checks that identity's ACL to confirm it has access to the target workspace. The time it takes to walk that ACL grows as you add more workspaces. It's not linear growth either - a service principal with 100 workspaces is noticeably faster than one with 1,000.
Microsoft's own guidance puts it bluntly: from a performance perspective, the optimal number of workspaces per service principal is exactly one.
So if each customer tenant gets its own workspace (which is the standard pattern), and you've got 5,000 customers, you'd need 5,000 service principals. That's obviously unmanageable. Nobody wants to register 5,000 app registrations in Microsoft Entra ID.
This is the problem service principal profiles solve.
Service Principal Profiles - The Architecture
A service principal profile is a lightweight identity that inherits permissions from a parent service principal. You create one parent service principal (one app registration in Entra ID), and then programmatically create as many profiles as you need - one per customer tenant.
Each profile acts as a separate identity from Power BI's perspective. It gets its own ACL, its own workspace memberships, and its own semantic model ownership. But from your Entra ID perspective, you're still managing a single app registration.
The practical result: each profile is a member of only one workspace (or however many that specific tenant needs), so ACL lookups are fast. You get the isolation benefits of separate identities without the management overhead of thousands of Entra app registrations.
To set up a new customer tenant, your provisioning code:
- Creates a new Power BI workspace via the REST API
- Creates a new service principal profile
- Adds that profile as an admin of the workspace
- Imports your template .pbix file into the workspace
- Updates data source parameters and credentials
- Configures scheduled refresh
All of this is automatable through the Power BI REST API, which is the whole point. When a new customer signs up to your platform, your backend provisions their entire analytics environment without any manual steps.
Tenant Isolation - Why It Actually Matters
Isolation isn't just a nice-to-have. In multi-tenant analytics, a configuration mistake that shows Customer A's data to Customer B is a career-ending event. Service principal profiles give you isolation at the identity level, not just the workspace level.
Each profile owns its own semantic models. Data source credentials are scoped to the profile that set them up. Even if you somehow misconfigure workspace permissions, the profiles themselves can't see each other's workspaces because they're separate identities.
Compare this to the old approach of using a single master user account that's an admin on every workspace. One misconfigured report parameter and you're showing the wrong data to the wrong customer. We've seen this happen at organisations that outgrew their initial embedding setup.
There's also the semantic model ownership angle. Every Power BI semantic model has a single owner. If you use a shared service principal as the owner of all semantic models across all tenants, you create a single point of failure. If that service principal's credentials expire or get misconfigured, every tenant breaks at once. With profiles, credential issues affect only the specific tenant that uses that profile.
When You Should and Shouldn't Use Profiles
Microsoft recommends service principal profiles when you have many workspaces and more than 1,000 users. That's a reasonable threshold. Below that, a single service principal is simpler and works fine.
Where profiles become essential:
- ISVs with hundreds or thousands of customers
- Enterprise platforms with separate business units
- Any scenario where you expect to grow past a few hundred tenants
Where profiles add unnecessary complexity:
- Internal dashboards for a single organisation
- Small-scale embedding with under 50 tenants
- Embed for your organisation scenarios (profiles aren't designed for this)
The complexity isn't trivial. Your provisioning code needs to manage profile lifecycle - creation, credential rotation, cleanup when tenants are deprovisioned. Your embedding code needs to acquire tokens on behalf of the correct profile for each request. And your monitoring needs to track API performance per profile, not just per service principal.
Don't adopt profiles because they sound impressive. Adopt them because your scale demands it.
Practical Tips From Real Deployments
We've helped several Australian ISVs and enterprise teams build multi-tenant Power BI embedding solutions. Here's what we've learned that isn't in the documentation.
Start with a provisioning script, not a manual process. Even if you only have five tenants today, automate from the start. The provisioning flow (workspace, profile, import, configure) should be a single API call from your backend. Manual workspace setup doesn't scale and introduces inconsistency.
Template .pbix files should be version-controlled. When you update your report template, you need to roll that change out across all tenant workspaces. If you don't have a clean deployment pipeline for this, updates become a nightmare once you pass a few dozen tenants.
Monitor API call latency per tenant. If one tenant's API calls suddenly slow down, it usually means something is wrong with that specific profile's workspace - a failed refresh, a broken data source connection, or a semantic model that's grown too large. Aggregate monitoring hides these problems.
Plan for credential rotation. Service principal secrets expire. If you're running hundreds of profiles off a single parent service principal, and that secret expires without your ops team noticing, every tenant goes dark at once. Set up alerts well before expiry, and automate rotation if possible.
Test with realistic tenant counts. A lot of teams build their proof of concept with three tenants and then panic when they try to onboard their first hundred. Load test your provisioning pipeline and your embedding latency with the number of tenants you expect to have in 12 months, not the number you have today.
The Capacity Question
All of this runs on Power BI Embedded capacity or Fabric capacity. The size of capacity you need depends on the number of concurrent users, the complexity of your reports, and how often data refreshes. This is genuinely hard to predict upfront - I'd rather not give you a formula that sounds precise but is actually wrong.
What I will say is: start with a smaller capacity than you think you need and scale up based on actual usage data. Power BI lets you change capacity size without downtime, so there's no reason to over-provision from day one. Monitor the capacity metrics (CPU utilisation, memory pressure, query duration) and right-size as you go.
Getting Started
If your team is planning a multi-tenant Power BI embedding solution and you're not sure about the architecture, we run data and BI consulting engagements that cover exactly this kind of design work. Getting the architecture right before you write code saves a lot of painful refactoring later.
For broader data platform questions - like whether your analytics layer should sit in Power BI, Fabric, or a combination - our AI and data strategy sessions are a good starting point. And if you need hands-on development help building out the embedding integration, our .NET consulting team has done this type of work across several ISV clients.
The official Microsoft documentation on service principal profiles goes into detail on the API calls and code patterns. It's worth reading end to end if you're serious about building at scale. But talk to someone who's done it before you commit to an architecture - the theoretical patterns and the practical gotchas are two very different things.