Power BI Embedded: Putting Analytics Inside Your SaaS Product
Your customers keep asking for reporting, and hand-building charts has become a permanent side-quest. Here's an honest look at whether embedding Power BI in your product is the better answer.
- Reporting is the feature request that never ends. At some point hand-building charts stops being a sprint and becomes a permanent team competing with your roadmap.
- Power BI Embedded lets your app show real reports to customers who have no Power BI login of their own - the app-owns-data pattern - and lets analysts, not engineers, change those reports.
- It is not always the right answer. Pixel-perfect bespoke visuals, public unauthenticated pages, an unready data model, or thin unit economics at your customer count all argue against it.
It starts politely. A customer asks whether they can export a table to Excel. You add a CSV button. A few months later the same customer asks for "a dashboard", and their account is big enough that you say yes. So an engineer picks a charting library, writes a few aggregate endpoints, and ships three charts.
Then the requests keep coming. Can we filter by region. Can we compare to last quarter. Can we schedule this monthly. Can we see it by product line instead. Each one is small, none of them is on your roadmap, and collectively they have created a reporting product inside your product that nobody owns and nobody planned for.
That is the moment product teams start looking at embedded analytics, and Power BI Embedded is one of the usual candidates. This post is about the decision - build it yourself or embed - rather than how to write DAX. If you want the fundamentals of Power BI itself first, our Power BI dashboards guide covers that ground.
What Power BI Embedded Actually Is
Stripped of the marketing, the idea is simple. Reports are built and published through the ordinary Power BI development process. Your application then requests an embed token from Microsoft's service on the server side, hands that token to a small JavaScript component in your front end, and the report renders inside your own UI - your navigation, your page, your product.
The important distinction is who the viewer is. There are two broadly different patterns, and mixing them up is the most common early mistake:
- User-owns-data - the people viewing the report are members of your own organisation and hold their own Power BI licences. This is the pattern for internal tools and staff dashboards.
- App-owns-data - the viewers are your customers. They have no Power BI account, no licence, and ideally no idea Power BI is involved. Your application holds a single service identity, authenticates on their behalf, and controls exactly what each viewer is allowed to see.
For a SaaS product sold to external customers, app-owns-data is the pattern that matters. If a vendor demo or a blog post shows people signing into Power BI to view the report, it is answering a different question than the one you are asking.
The Commercial Shape, Without The Price Tag
Embedding for external customers is backed by dedicated capacity that you buy and size to your expected load, rather than a per-viewer licence for every one of your customers' users. That is the structural difference worth understanding: your cost is driven mainly by how much compute you reserve and how heavily it is used, not by how many end users you have. For a product with thousands of light-touch viewers, that shape is usually favourable. For a product with a handful of customers on thin margins, it may not be.
We are deliberately not quoting figures here, because capacity SKUs, tiers and names have changed more than once and anything we print will age badly. Check Microsoft's current pricing page before you build a business case, and note that Microsoft has been consolidating its analytics products under the Fabric umbrella, so the capacity you buy and the product names attached to it may look different from older documentation you find. Treat any third-party article quoting a monthly figure, including this one, as a starting point for your own verification rather than a quote.
Build It Yourself Or Embed: The Honest Comparison
Hand-building means a charting library, your own aggregation endpoints, and your own filter and export logic. Embedding means Power BI content rendered inside your app. Neither is universally right, and the trade-offs are fairly predictable:
| Dimension | Hand-built charts | Power BI Embedded |
|---|---|---|
| Time to first useful thing | Fast for three charts, slow for thirty | Slower to set up, then fast to add reports |
| Ongoing maintenance | Every new chart, filter and export is engineering work | Report changes move off the engineering backlog |
| Pixel control | Total - it is your components | Constrained to theming and layout options |
| Cost shape | Engineering time, recurring and open-ended | Capacity fees plus a smaller build effort |
| Analytical depth | Whatever you build - drill and slice cost real effort | Drill, slice, filter and export come with the platform |
| Who can change a report | An engineer, via a release | An analyst, without a deploy |
That last row is the one teams underrate. When a report change needs a developer, a ticket and a release, reporting requests queue behind features forever. When an analyst can adjust a report and publish it, the queue mostly disappears.
When Embedding Is The Wrong Call
It is worth being blunt about this, because the failure mode is expensive. Embedding is typically a poor fit when:
- You need pixel-perfect bespoke visuals woven deeply into your interface - custom interactions, charts that drive application state, visuals that are part of your product's identity. You will spend the project fighting the platform.
- The charts need to appear on a public page with no authenticated user. Some publish-to-web style options exist, but they are designed for genuinely public data and are not an appropriate way to serve customer data.
- Your data model is not ready. If reporting numbers currently come from ad-hoc queries against your transactional database, embedding will expose that inconsistency to customers rather than fix it.
- The capacity cost does not fit your unit economics at your current customer count. Run the arithmetic per customer before you commit, not after.
- Reporting is genuinely core intellectual property and a reason people buy your product. Then it deserves to be built, owned and differentiated.
The Hard Parts Nobody Warns You About
Getting a report to appear in your app is a day or two of work. Getting it right for a multi-tenant product is a different exercise. These are the parts that consume the schedule:
Multi-Tenant Data Isolation
This is the big one. Your report sits on a data model that typically contains every tenant's data, and row-level security is what ensures customer A sees only customer A. The filtering rules live in the dataset, and the identity used to apply them is supplied by your backend when it requests the embed token.
The consequence of getting this wrong is not a bug report, it is an incident: one customer seeing another customer's numbers. Treat the tenancy rules as security-critical code. Test them the way you would test authentication - with automated checks per tenant, and a review whenever the model changes.
Performance Under Real Concurrency
A report that opens in two seconds on your laptop behaves differently when four hundred customer users open it on the first working day of the month. Concurrency, model size, query complexity and refresh schedules all interact. Load-test with realistic concurrency and realistic data volumes before you promise anything in a renewal call.
Capacity Sizing And What Happens At The Ceiling
Capacity is a finite pool. Push past what you have reserved and the effect is felt as slow reports and throttled operations rather than a clean error - which is worse, because it looks like your product is broken. Monitor utilisation from day one, know your headroom, and know how quickly you can scale up.
Theming, Tokens And Environments
Three smaller items that reliably take longer than estimated. Theming so reports look like part of your product rather than a Microsoft page pasted into an iframe. Embed token lifecycle - tokens are short-lived, so you need clean refresh handling for the customer who leaves a tab open all afternoon. And environments, because your dev, staging and production workspaces need a deployment path just like your application code does.
You Still Need A Data Model
Embedding does not exempt you from modelling. Relationships, consistent measure definitions, and a refresh strategy still have to exist, and they still determine whether the numbers are correct. Embedding changes who renders the chart, not who is responsible for the truth behind it. This is the same discipline behind any serious Power BI development work, and the same discipline behind our NGO finance dashboard project.
A Sensible Implementation Order
If you decide to go ahead, the sequence below tends to surface the expensive surprises early rather than late:
- Model the data first. Decide where reporting data lives, how it gets there, and how each metric is defined. Do not build this on top of your live transactional tables by default.
- Decide the tenancy approach. How does a tenant identity flow from your application into row-level security, and how will you prove isolation holds?
- Prove it with one report. Pick the single report customers ask for most, embed it end to end for two real tenants, and get it in front of users.
- Wire authentication and token issuance server-side. Build a small service that authenticates, resolves the tenant, and issues short-lived embed tokens.
- Theme it. Match your product's colours, typography and density so it reads as your feature, not a bolted-on window.
- Load-test at realistic concurrency. Model your busiest hour, not your average one, and size capacity from what you observe.
- Roll out in stages. A pilot cohort, then a broader release, with utilisation and error monitoring in place before the wide launch.
Security note: embed tokens must be issued server-side, and the tenant filter must be decided by your backend from the authenticated session. Never accept a tenant id, customer id or filter value sent from the browser as the basis for what data a report shows - a client-supplied identifier is a request, not a fact, and treating it as a fact is how one customer ends up looking at another's revenue.
Making The Call
The decision usually comes down to two questions. Is reporting something your customers need but not something they buy you for? And is your team spending more time on chart requests than the feature is worth? If both answers are yes, embedding is worth costing properly. If reporting is your differentiator, or your visuals need to be genuinely bespoke, build it and own it.
Either way, the data model underneath is the part that decides whether it works. If you want a second opinion on which route fits your product, our Power BI developers are happy to walk through your data and your customer count before you commit to anything.
Weighing Up Embedded Analytics For Your Product?
We help product teams decide between building analytics and embedding Power BI - then model the data, handle multi-tenant security and ship it inside your app. Start with a short technical conversation, not a proposal.
Frequently asked questions
What is the difference between Power BI Embedded and normal Power BI sharing?
Normal sharing assumes every viewer has their own Power BI account and licence, which suits internal teams. Embedding for a SaaS product uses the app-owns-data pattern: your application authenticates with a single service identity and shows reports to customers who have no Power BI login at all. The customer never sees a Microsoft sign-in screen.
Do our customers need Power BI licences to see embedded reports?
Not under the app-owns-data pattern. Your application holds the identity and requests an embed token on the customer's behalf, so the viewer needs nothing beyond a login to your product. Instead of per-viewer licences, you buy and size capacity, which is why the cost model works better for products with many light-touch users.
How do we stop one customer seeing another customer's data?
Row-level security in the dataset, driven by an identity your backend supplies when it issues the embed token. The critical rule is that the backend decides which tenant the session belongs to - never the browser. Test isolation automatically for every tenant and re-test whenever the data model changes, because this is the one failure mode that is genuinely existential.
How long does it take to embed Power BI in a SaaS product?
Getting a single report rendering inside your app is typically a matter of days. Getting to a production-ready multi-tenant rollout - a proper data model, tested row-level security, token issuance, theming, load testing and environments - commonly runs to several weeks, and the data model is usually the longest pole. Timelines depend heavily on how ready your reporting data already is.
What does Power BI Embedded cost?
Cost is driven by the capacity you reserve rather than the number of end users, so it scales with load rather than headcount. We are deliberately not quoting figures because tiers and product names change - check Microsoft's current pricing page, and note that Microsoft has been consolidating analytics products under Fabric. Model the cost per customer at your actual customer count before committing.