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.
- Power BI Embedded uses the app-owns-data pattern, so your customers see reports inside your product with no Power BI login of their own and analysts, not engineers, change those reports.
- The core decision is build vs embed: hand-built charts give total pixel control, while embedding moves ongoing report changes off the engineering backlog.
- Multi-tenant isolation via row-level security is the security-critical part - your backend, never the browser, decides which tenant a session is allowed to see.
- Embedding is the wrong call for pixel-perfect bespoke visuals, public unauthenticated pages, an unready data model, or thin unit economics at your customer count.
- Cost scales with reserved capacity and load rather than headcount, which favours products with many light-touch viewers and works against a few customers on thin margins.
Power BI Embedded lets a SaaS product show real, interactive reports to its own customers without giving each customer a Power BI account. The pattern that matters for external customers is app-owns-data: your application holds a single service identity, authenticates on the viewer's behalf, requests a short-lived embed token from Microsoft, and renders the report inside your own UI. The viewer never sees a Microsoft sign-in screen. The practical payoff is that report changes move off your engineering backlog and onto an analyst, and your customers get drill, slice, filter and export for free.
It is not always the right answer. Pixel-perfect bespoke visuals, public unauthenticated pages, an unready data model, or thin unit economics at your current customer count all argue against it. This post is about that decision - build it yourself or embed - rather than how to write DAX. If you want the fundamentals of Power BI first, our Power BI dashboards guide covers that ground.
What Power BI Embedded Actually Is
Power BI Embedded is Power BI content rendered inside your own application rather than in Microsoft's portal. 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 navigation, your page, your product.
The requests usually start politely. A customer asks to export a table to Excel, so 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. Then the requests keep coming: filter by region, compare to last quarter, schedule it monthly, break it down by product line. Each one is small, none 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 teams start looking at embedded analytics.
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 a SaaS product is asking. For external customers, the app-owns-data pattern is the one that matters.
Two Embedding Patterns, And Why The Difference Matters
There are two broadly different embedding patterns, and mixing them up is the most common early mistake. The distinction is simply who the viewer is: a member of your own organisation who holds a Power BI licence, or an external customer who has no Power BI account at all.
| User-owns-data | App-owns-data | |
|---|---|---|
| Who views | Your own staff, with Power BI licences | Your customers, with no Power BI account |
| Identity | Each viewer signs in to Power BI | One service identity acts on the viewer's behalf |
| Sign-in screen | Microsoft sign-in is visible | No Microsoft sign-in, only your product login |
| Best fit | Internal tools and staff dashboards | Customer-facing SaaS analytics |
| Licensing shape | Per-user Power BI licences | Reserved capacity you size to expected load |
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 and publish, the queue mostly disappears.
When Embedding Is The Wrong Call
Embedding is the wrong call when reporting is core to your product or when the platform will fight your interface. 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 custom software development route, not an embed.
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, and a few areas reliably 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 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.
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.
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.
What Drives Cost And Timeline
Cost is driven mainly by the capacity 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, because capacity SKUs, tiers and names have changed more than once, and Microsoft has been consolidating its analytics products under the Fabric umbrella. Check Microsoft's current pricing page before you build a business case, and treat any third-party article quoting a monthly figure, including this one, as a starting point for your own verification.
| Factor | Lighter effort and cost | Heavier effort and cost |
|---|---|---|
| Data model readiness | Clean warehouse with defined metrics | Reporting off ad-hoc transactional queries |
| Tenant isolation | One clear tenant identity per session | Sharing, hierarchies, cross-tenant roles |
| Report volume | A handful of core reports | Dozens of bespoke reports per segment |
| Concurrency | Light, spread-out usage | Month-end spikes with many simultaneous viewers |
| Theming depth | Light branding is enough | Pixel-level match to your design system |
Common Mistakes Teams Make
Most embedded-analytics trouble traces back to a small set of avoidable mistakes rather than a platform limitation. The patterns below come up again and again:
- Trusting the browser for tenancy. Accepting a tenant id or filter from the client instead of resolving it server-side from the authenticated session. This is the mistake that ends with one customer seeing another's revenue.
- Confusing the two patterns. Building against user-owns-data examples when the product needs app-owns-data, then discovering customers are being asked to sign in to Microsoft.
- Embedding on top of an unready data model. Pointing reports at live transactional tables so customers see inconsistent numbers, then blaming the tool.
- Sizing capacity for the average hour. Testing with light usage, then throttling on the first working day of the month when everyone opens their report at once.
- Skipping the per-customer arithmetic. Committing to capacity before checking whether the cost fits your unit economics at your actual customer count.
- Treating theming and token refresh as afterthoughts. Shipping a report that looks pasted in, or that silently fails for the customer who left a tab open all afternoon.
Conclusion
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, Power BI Embedded 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. Embedding changes who renders the chart, not who is responsible for the truth behind it. 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, or you can get in touch before you commit to anything.
Frequently asked questions
What is Power BI Embedded and how does it work in a SaaS product?
Power BI Embedded renders Power BI reports inside your own application. For a SaaS product it uses the app-owns-data pattern: your backend authenticates with a single service identity, requests a short-lived embed token from Microsoft, and hands it to a front-end component that renders the report in your UI. The customer sees your product, never 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. 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.
When should we build our own charts instead of embedding Power BI?
Build your own when reporting is core intellectual property, when you need pixel-perfect bespoke visuals woven into your interface, when charts must appear on public unauthenticated pages, or when capacity cost does not fit your unit economics. Embed when reporting is needed but not a reason people buy you, and when moving report changes off the engineering backlog is worth more than total pixel control.