Power BI Embed for Your Customers - Planning It Properly Before You Build

A lot of Australian software companies get to the same point. They've built a decent product, customers are happy, and then the requests start: "Can we get a dashboard?" "Can we export this to Excel and build our own charts?" "Our board wants a monthly view." At some point someone in the product team says "why don't we just embed Power BI?" and it sounds like a two-week job.

It's not a two-week job. It's not a six-month job either, if you plan it well. But the embed for your customers scenario has a handful of decisions that are very expensive to change later, and most of the pain we see on projects comes from teams that started building before making them.

Microsoft's implementation planning guidance has a usage scenario dedicated to this, and it's worth reading in full: Power BI usage scenarios - Embed for your customers. What follows is my take on it after doing this for a range of clients, including a few where we had to unpick earlier attempts.

What "embed for your customers" actually means

There are two broad ways to embed Power BI content into an application.

Embed for your organisation (sometimes called "user owns data") is for internal users. Everyone viewing the report signs in with their own Microsoft Entra ID account and needs an appropriate licence. Think of a staff intranet or an internal line-of-business app.

Embed for your customers ("app owns data") is the one this post is about. Your application authenticates to Power BI on behalf of the user. The person looking at the report never signs in to Power BI, doesn't need a Power BI licence, and frankly doesn't need to know Power BI is involved at all. They log in to your app with whatever authentication you already have, your backend generates an embed token, and the report renders inside your UI.

That second model is what makes Power BI viable for SaaS products, customer portals, supplier portals and anything else where the audience is outside your tenant. A logistics company we worked with uses it to give freight customers a self-service view of shipments, delivery performance and invoicing. None of those customers have a clue it's Power BI, and that's the point.

The moving parts

Here's the shape of a typical build:

1. Content is authored in Power BI Desktop by your BI team, the same way they'd build any report.
2. It's published to a workspace that sits on dedicated capacity.
3. Your application has an identity (ideally a service principal) with access to that workspace.
4. When a user opens a page in your app, your backend calls the Power BI REST API to generate an embed token scoped to the specific report, semantic model and, if you're using row-level security, the effective identity of that user.
5. The front end uses the Power BI JavaScript client library to render the report inside an iframe using that token.

None of those steps is hard on its own. The hard parts are the decisions around them.

Decision one - service principal or master user

The application needs an identity to talk to Power BI. You can use a "master user" (a real Entra ID account with a Power BI Pro licence) or a service principal (an app registration).

Use a service principal. I'm not going to hedge on that. Master user accounts are a hangover from the early days of embedding. They need a licence, they're subject to password policies and MFA rules that will break your production app at 2am, and security teams rightly hate having a shared human account with broad access sitting in a config file. A service principal, ideally with a certificate rather than a client secret, is the way to go. You'll need a Fabric admin to enable the tenant setting that allows service principals to use Power BI APIs, scoped to a security group.

For larger multi-tenant products, look at service principal profiles as well. They let one service principal act as many separate identities, which helps with workspace isolation and API throttling when you've got hundreds of customers.

Decision two - capacity

Embed for your customers requires dedicated capacity. Shared capacity is fine for testing with a Pro licence, but you can't go to production on it.

Your realistic options today are a Power BI Embedded A SKU in Azure, or a Microsoft Fabric F SKU. For new projects we mostly recommend F SKUs, because you get the full Fabric workload alongside Power BI and you can pause and scale them in the Azure portal. A SKUs still make sense if you only ever want Power BI and you're comfortable with the narrower feature set.

What catches people out is sizing. Report rendering, refreshes and DAX queries all burn capacity units, and an embedded app can be much spikier than internal reporting. Picture a customer portal where every client logs in at 9am Monday to check last week's numbers. We've seen an F8 that ran fine through testing fall over in the first week of production because nobody had modelled that Monday peak. My advice is to load test with realistic concurrency before go-live, use the Fabric Capacity Metrics app from day one, and keep separate capacities for dev/test and production so a developer running a heavy refresh doesn't slow down paying customers.

On cost, remember the bill is in USD-pegged Azure pricing and it runs 24/7 unless you pause it. For an Australian SaaS business with customers who mostly use the product during business hours, scripted pause and resume or scaling down overnight can make a real difference to the monthly number.

Decision three - how you separate customers

This is the one that's most painful to change later, so spend time on it.

There are two broad patterns.

Workspace per customer. Each customer gets their own workspace and their own semantic model, often pointing at their own database. Isolation is strong and easy to explain to a security reviewer. Deploying a report change to 300 workspaces is not easy though, so you need automation (deployment pipelines, the REST APIs, or Fabric Git integration plus scripts) or you'll drown.

Shared model with row-level security. All customers share one semantic model, and RLS filters data based on a tenant ID passed in the effective identity when you generate the embed token. Far simpler to maintain, one model to refresh, one set of reports to update. The trade-off is that a mistake in your RLS rules exposes one customer's data to another, which in most industries is a career-ending incident.

Most of our clients end up with something in between. Smaller customers share a model with RLS, and a handful of large enterprise customers who demand isolation (or have data residency requirements) get their own workspace. That hybrid works, but only if you design for it from the start.

Whichever you choose, write automated tests for your security. Generate embed tokens for test tenants and confirm they only see their own rows. I've reviewed implementations where RLS was configured correctly in Desktop and then the app passed the wrong username in the token. The rules were fine. The plumbing was wrong.

Things that are still a bit rough

Power BI embedding is mature, but it's not without friction.

Look and feel. You can theme reports, hide the filter pane and control navigation through the JavaScript API, but it will never look exactly like a native React component. If your product has a strong design system, accept that the embedded area will feel slightly different, or budget time for careful theming. Fighting it pixel by pixel is a losing game.

Load time. First render of an embedded report can take a few seconds, particularly on a cold capacity. Preloading the Power BI library, bootstrapping the embed before the token arrives and keeping models lean all help. Users of a SaaS product are much less patient than internal staff.

Self-service authoring. You can let customers edit and create reports in embedded mode, and it does work. But once customers are building their own content inside your app, you've signed up to support Power BI authoring for people who never asked to learn it. Think carefully before switching that on broadly.

Token management. Embed tokens expire. Your front end needs to refresh them before they do, or users get an error after sitting on a page for an hour. It's a small thing that we see missed constantly.

Governance doesn't go away

Because the audience is external, it's tempting to think of this as "just a feature of our app" rather than a BI deployment. That's a mistake. You still need the usual Power BI disciplines:

• Source control and a proper release process for reports and models
• A clear owner for the semantic model and its business logic
• Monitoring of capacity health and refresh failures
• Documentation of which customers see which content

The difference is that failures are now visible to paying customers rather than an internal finance team. A broken refresh that an internal user would grumble about becomes a support ticket and maybe a churn risk.

Who should own it

In our experience the best outcomes come when the product engineering team and the BI team work as one squad for the build. Developers own authentication, token generation, the front end integration and the deployment automation. BI people own the model, the DAX, the reports and the performance tuning. When either side does the whole thing alone, you get either beautiful reports wrapped in fragile plumbing, or solid plumbing wrapped around reports that nobody wants to use.

If your app is built in .NET and React, which a lot of Australian SaaS products are, the Power BI client libraries fit in pretty naturally. Our Power BI consultants and software development team regularly work on exactly this combination, and it's usually the integration seams where the real work is.

Is it the right choice?

Power BI embedding for customers makes sense when:

• You need rich, interactive analytics, not just three charts on a dashboard
• Your BI team already knows Power BI and you want to reuse those skills
• You're happy paying for dedicated capacity
• Your customers will value filtering, drilling and exporting

It's probably overkill when you only need a few simple charts. A charting library in your front end, fed by your own API, will be faster, cheaper and look more native. I've talked more than one client out of Power BI Embedded for that reason, and they were better off for it.

There's also a newer angle worth thinking about. Customers increasingly want to ask questions of their data in plain English rather than click through report pages. Copilot in embedded scenarios is still limited compared with the full service, so if conversational analytics is a key requirement, look at whether a custom AI layer over your semantic model fits better. We've written more about that in our AI for business intelligence work.

Where to start

If you're at the "should we embed Power BI?" stage, I'd suggest a short discovery before anyone writes code. Agree on the tenancy model, pick your capacity approach, confirm your identity setup with your security team, and build one end-to-end slice with a real customer's data and RLS. That slice will surface most of the surprises in a couple of weeks instead of a couple of months.

And read Microsoft's embed for your customers usage scenario. It's one of the better pieces in the implementation planning series, and it gives you a sensible checklist to argue over before the build starts.