Back to Blog

Power BI Embed for Your Organisation - Putting Reports Where Staff Already Work

October 24, 2026•7 min read•Michael Ridland

Here's a pattern I see in nearly every mid-sized Australian organisation we work with. They've spent real money building good Power BI reports. The data model is clean, the visuals are sensible, the numbers reconcile. And then usage data shows that half the intended audience has opened the report twice. Not because the report is bad, but because nobody wants to leave the system they work in all day, find a bookmark, log into the Power BI portal and hunt for the right workspace.

Embedding for your organisation is Microsoft's name for fixing that. Instead of making staff go to Power BI, you put Power BI content inside the apps they already use: an internal portal, a line-of-business web app, a SharePoint page, a Teams channel. Microsoft covers this in its implementation planning guidance as the embed for your organisation usage scenario. It's worth reading. What follows is the version with the consulting scars attached.

The key difference from embedding for customers

Power BI Embedded has two distinct flavours, and people confuse them constantly.

Embed for your customers (sometimes called "app owns data") is for external users who don't have Power BI licences or even Entra ID accounts in your tenant. Your app authenticates to Power BI with a service principal and generates embed tokens on their behalf. I wrote about that one recently in planning Power BI embed for your customers.

Embed for your organisation ("user owns data") is for internal users. Each person signs in with their own Entra ID account. Power BI knows exactly who they are, applies their permissions and row-level security as normal, and the report behaves just like it does in the Power BI service. The custom app is basically a frame around content the user already has rights to.

That distinction drives everything else: licensing, security, how much code you write, and what can go wrong.

Ways to do it, from easiest to most work

You don't always need developers for this. In rough order of effort:

Teams tabs. Add a Power BI report as a tab in a Teams channel. Zero code. If your organisation lives in Teams, this is often the single biggest win for adoption and it takes about two minutes.

SharePoint Online web part. The Power BI web part drops a report onto a SharePoint page. Good for intranet-style landing pages, like a "Sales hub" page that has the dashboard alongside policy documents and contact lists.

Secure embed links. Power BI generates an iframe snippet you can paste into any web page. Users still sign in and need permissions. It's quick, but you get very little control over the experience.

Power BI JavaScript SDK in a custom app. This is the "real" embed for your organisation. Your web app acquires an Entra ID token for the signed-in user, calls the Power BI REST APIs, and uses the JavaScript client library to render reports, dashboards, tiles or visuals inside your own UI. You can set filters, respond to events, hide panes and build navigation that suits your app.

Power Apps and other platforms. Power Apps has a Power BI tile control, and plenty of third-party portals have connectors that use the same underlying mechanism.

My honest view: most organisations should exhaust the first two options before writing a line of JavaScript. Custom embedding earns its keep when the report is genuinely part of a workflow. Think of a claims processing app where the assessor sees the customer's history report right next to the claim form, filtered to that customer automatically. That's where the SDK shines. If you just want "a page with the dashboard on it", Teams or SharePoint will do.

Licensing - the part that catches people

Because users sign in as themselves, normal Power BI licensing rules apply. Every viewer needs either:

  • a Power BI Pro or Premium Per User licence, or
  • the content needs to sit in a workspace backed by Fabric capacity (F64 or above) or legacy Premium capacity, in which case free-licence users can view it.

This is where I've had awkward conversations. A client builds a lovely embedded experience in their staff portal for 1,500 frontline workers, then discovers that only 80 of them have Pro licences. At Australian Pro pricing, licensing the remaining 1,420 isn't a rounding error. An F64 capacity may well be the cheaper option at that scale, but it's a decision that should happen during planning, not the week before go-live.

Do the maths early. Count your viewers honestly, including the ones who'll only open the report once a month. Somewhere around a few hundred viewers, capacity usually starts winning over per-user licences, though your exact break-even depends on your Microsoft agreement.

And a common misunderstanding: embedding in your own app doesn't get you around licensing. Power BI still sees a named user viewing content. If you want to serve content to people without licences and without capacity, you're in "embed for your customers" territory, and that has its own licensing terms. Using that pattern for your own employees to dodge per-user costs is not something Microsoft's licensing terms allow, and I wouldn't recommend testing it.

Security just works, mostly

The nice thing about user owns data is that you don't rebuild security. Row-level security defined in the semantic model applies automatically because Power BI knows the user's identity. Workspace roles, app audiences and sharing permissions all carry across. Sensitivity labels from Microsoft Purview follow the content too.

A few things to watch:

Permissions still need to exist. If a user can see the embedding app but hasn't been given access to the underlying report, they get an error inside your app rather than a polite message. Build in handling for that, and ideally sync access through Entra ID security groups so the app and the report share one source of truth.

Conditional access policies apply. If your organisation requires compliant devices or MFA for Power BI, those rules hit the embedded experience too. That's correct behaviour, but it surprises people when a report won't load on a personal tablet that can open the app itself.

Token handling in custom apps. With the SDK, your app requests delegated permissions to the Power BI service. Keep the scopes tight (Report.Read.All rather than everything) and get your Entra ID admins involved early, because consent for those permissions often needs admin approval.

The developer experience

For teams building custom apps, the Power BI JavaScript SDK is mature and reasonably well documented. We've done this in React and in Blazor-based .NET apps without much drama. A few practical tips from those projects:

  • Use MSAL for token acquisition and handle silent refresh properly. Reports that go blank after an hour because the token expired are a classic first-release bug.
  • Set filters and slicers programmatically from your app context rather than making users pick the same customer twice.
  • Turn off panes and navigation the user doesn't need. An embedded report that still shows the full filter pane looks unfinished.
  • Load performance depends on the report, not the embedding. If the report is slow in the Power BI service, it'll be slow in your app. Fix the model first.

On the rough edges: mobile layouts in embedded scenarios are still fiddly, and some features that work in the service (certain export options, subscriptions, some Copilot experiences) either don't exist in embedded contexts or behave differently. Check the specific features your users rely on before you promise them.

When we'd recommend it

Embed for your organisation is the right call when:

  • the people who need the data spend their day in another app and won't leave it
  • the report makes more sense in context, filtered to the record they're looking at
  • you want Power BI's security model rather than building your own

It's probably not worth it when the audience is a small group of analysts who are perfectly happy in the Power BI service, or when the "app" you'd embed into is something nobody really uses either. Embedding a report into a neglected intranet doesn't fix adoption. It just moves the empty room.

If you're planning something like this, our Power BI consultants can help with the licensing maths, security design and the build itself, and our React consultants handle the custom app side when it gets to that. If the bigger question is how to get your people actually using data day to day, have a look at our work on AI for business intelligence.