How to Share a Power BI Report

 April 15, 2026 · Deloc 

You built a Power BI report. Someone wants to see it. The obvious assumption is that you just send them a link, they click, and they see the report. In practice, it is never that simple.

Power BI has seven different ways to share a report, and each one trades off something: licensing costs, security, customization, ecosystem lock-in, or all four. This post walks through every option, what it actually costs, and what to do when none of them quite fit.

TL;DR: the seven ways, in one table

Method	Best for	Cost per viewer	Biggest caveat
Publish to Power BI Service	Internal colleagues with Microsoft accounts	~$14/mo (Power BI Pro)	Every viewer needs a Pro license
Publish to Web	Public dashboards, marketing, press	Free	Data is 100% public on the internet
Embed in Teams / SharePoint	Teams already in Microsoft 365	~$14/mo	Same licensing, limited to MS ecosystem
Power BI Apps	Distributing to large groups	~$14/mo per viewer	Same licensing, more setup overhead
Export to PDF or PowerPoint	Executive one-pagers, board decks	Free	Static snapshot, no interactivity
Email subscriptions	Scheduled snapshots	Free (with Pro)	Static image, report not interactive
Power BI Embedded	Embedding in your own SaaS product	Capacity pricing, from ~$735/mo	Developer work required

If the licensing costs or the public-vs-private tradeoff in that table give you pause, skip to the end. There is an eighth option Microsoft does not advertise, and it is what a growing number of teams are picking instead.

Method 1: Publish to the Power BI Service

This is the default path. From Power BI Desktop, click File → Publish → Publish to Power BI, pick a workspace, and your report lands in app.powerbi.com where you can share it.

How viewers access it:

You add them to the workspace, or you share a direct link.
They sign into app.powerbi.com with their Microsoft work account.
They see the report.

The catch: every viewer needs a Power BI Pro license (roughly $14/user/month as of this writing) unless your organization has Power BI Premium capacity. If you are sharing with five colleagues, that is $70/month in licenses for them to view a single report. If you want to share with 50 colleagues, it is $700/month.

Power BI Premium Per User (~$24/user/month) removes the requirement on the viewer side for some content types, but now the viewer is paying more. Premium capacity pricing (the “P” SKUs) starts around $5,000/month and makes Pro licenses optional for viewers within the capacity, but it is enterprise pricing with an enterprise commitment.

When this is the right answer: internal reporting within a company that already has Microsoft 365 E5 or equivalent, where Pro licenses are bundled and nobody is individually paying. If that describes you, use this. If it does not, keep reading.

Method 2: Publish to Web (the public option)

Power BI has a feature called Publish to Web that generates an iframe you can embed anywhere — a blog post, a company site, a Confluence page, an email. Viewers do not need Microsoft accounts. Anyone with the link sees the report.

From the report, go to File → Embed report → Publish to web (public). Power BI generates an embed code and a direct link.

The catch is in the name. Public means public. Anyone on the internet can see the data, including search engines that happen to index the iframe URL. Microsoft warns you about this in a pop-up that most people click through without reading.

When this is the right answer: marketing dashboards, press pages, open data projects, demos — anything that is already meant to be public. Do not use this for revenue numbers, customer data, HR information, or anything you would not be comfortable posting on Twitter.

Admins at most organizations disable the Publish to Web feature entirely because of how often it gets misused. If the menu option is greyed out in your copy of Power BI, that is why.

Method 3: Embed in Microsoft Teams or SharePoint

If your audience already lives in Microsoft 365, you can embed a Power BI report directly into a Teams tab or a SharePoint page.

Teams: add a new tab in a channel, pick Power BI, point it at your report.
SharePoint: use the Power BI web part on any page.

Authentication is handled via the user’s existing M365 session, which feels seamless. Your colleague opens Teams, clicks the tab, the report loads.

The catch: same licensing story as Method 1. Each viewer still needs a Pro license or Premium capacity coverage. Embedding the report in Teams does not bypass the license requirement, it just changes where the report is displayed.

When this is the right answer: internal teams that already pay for Pro and live in Teams all day. Useful as a distribution surface, not a licensing workaround.

Method 4: Power BI Apps

For distributing a set of reports to a larger audience inside your organization (tens to hundreds of viewers), Power BI has the concept of Apps — curated collections of dashboards and reports published from a workspace.

You build your reports in a workspace, you publish the workspace as an App, you grant access to security groups or individual users, and they install the App from app.powerbi.com.

Apps add some governance niceties — a clean landing page, a single “publish new version” workflow, audit logs — but the viewer licensing requirement is identical. Each installer needs a Pro license.

When this is the right answer: large organizations with existing Pro licensing and a need for structured report distribution. If your team is under 20 people, the overhead usually is not worth it.

Method 5: Export to PDF or PowerPoint

Sometimes the viewer does not need interactivity. They just need the numbers, once.

Power BI exports to PDF, PowerPoint, and PNG directly from the report view. You get a static snapshot at a specific moment in time. You attach it to an email, a board deck, a customer proposal.

The catch: it is static. No filtering, no drilldown, no hover tooltips, no freshness. The numbers age the moment you export. If the person you send it to wants to see this quarter’s data next month, you export again.

When this is the right answer: one-off executive summaries, board meetings, compliance packets. Anything where “the numbers at this point in time” is the deliverable, not the ongoing dashboard.

Method 6: Email subscriptions

Power BI Pro users can subscribe recipients to scheduled email updates. The recipient gets a PNG of the report dashboard in their inbox every morning, afternoon, week — whatever cadence you pick.

Recipients do not need Power BI licenses for this particular delivery method, because they are getting an image, not the interactive report.

The catch: they are getting an image. They cannot click into the underlying data. They cannot filter or drill down. If the report has ten visualizations, all ten get crammed into the email. On mobile, it is illegible.

When this is the right answer: a daily “here are the top numbers” briefing that executives skim on their phone. Useful as a complement to a real dashboard, not a replacement.

Method 7: Power BI Embedded (the developer option)

If you are building a SaaS product and you want Power BI visualizations embedded inside your own application — not inside Power BI’s shell, but inside your app — Microsoft offers Power BI Embedded.

You buy capacity (the A-SKUs start around $735/month for the smallest tier), you use the Power BI REST API to render reports in your app, you pass user context via row-level security.

The catch: it is a full engineering project. You need an authentication bridge, you need to handle session tokens, you need to size the capacity correctly (under-size and things queue; over-size and you pay for idle). The cheapest capacity tier cannot host production workloads at scale. Realistic monthly spend for a small SaaS embedding Power BI is several thousand dollars, plus the engineering time.

When this is the right answer: large software vendors who have already committed to Power BI as their BI layer and want to expose it to their customers. For everyone else, the overhead is prohibitive.

Pick the row in the table that describes your situation:

Internal sharing, team is already on M365 with Pro licenses bundled: use Method 1 or 3. You are paying for the licenses regardless, so the sharing is effectively free at the margin.

Public-facing data, no sensitivity: Method 2. Just read the warning dialog carefully.

One-off exports for executive audiences: Method 5.

None of those fit: keep reading.

There are four common situations where the options above stop being enough.

1. The per-viewer licensing cost is too high. If you want 100 people to see a dashboard and they are not all on Microsoft 365 E5, you are looking at $1,400/month in Power BI Pro licenses. For some organizations that is a rounding error. For most it is a real budget item.

2. You need selective access without full publishing. “Publish to Web” makes data public to the entire internet. “Publish to Power BI Service” requires every viewer to have a Microsoft account and a Pro license. There is no middle ground: share with these specific 50 people who are outside my company, none of whom have Power BI accounts. That’s a use case Power BI handles poorly.

3. The design is not good enough. You know “Power BI blue.” Reports look the way Microsoft designed the templates to look. Matching your brand, adjusting typography, using a specific color palette, controlling spacing, adding an animated transition — these are either not possible or require workarounds that consume more time than just building the thing.

4. You want to embed the dashboard somewhere that is not a Microsoft product. Your company’s public website. A customer portal. A client’s Notion page. An iframe inside a document. Every Power BI sharing method assumes either the Microsoft ecosystem or the fully-public web. Anywhere in between is hard.

If any of these hit, it is worth considering option number eight.

The alternative most teams migrate to — for the specific reports where Power BI’s tradeoffs hurt — is a custom-built dashboard, typically in React, hosted on a static site service.

In 2026 this is a very different proposition than it was five years ago. AI coding tools like Claude Code and Cursor can write production-quality React dashboards from a prompt. Static hosting services like Deloc let you deploy that dashboard with one command and share it as a URL, with optional authentication, no per-viewer licensing, and unlimited viewers included.

Here is what the end-to-end flow looks like:

Build the dashboard in Claude Code or Cursor. You describe the layout, charts, and data shape. The AI produces a React project.
Deploy it to Deloc with one command: npx @deloc/cli deploy. Total time: under 30 seconds.
Share the URL. Anyone with the link can view the dashboard — or you can restrict access to specific email domains (visitors sign in with Google or Microsoft, Deloc checks the domain, no code changes needed).
Update the data automatically. A small scheduled script queries your warehouse (BigQuery, Snowflake, Postgres) and pushes fresh JSON to Deloc on a cadence. The dashboard loads current numbers on every page load.

Cost comparison

A concrete scenario: 5 analysts building dashboards, 50 internal viewers, mix of internal and external audiences.

Power BI path:

5 Power BI Pro licenses for the builders: $70/month
50 Pro licenses for the viewers: $700/month
Total: $770/month, or ~$9,240/year
External sharing still requires either Premium Per User or Publish to Web (public)

Deloc + React path:

Deloc Pro Unlimited for the 5 builders: $25/month per publisher, or $125/month total for the team
50 viewers (or 500, or 5,000): free, no licensing
Optional warehouse refresh costs: roughly $2/month on Cloud Run
Total: ~$127/month, or ~$1,524/year
External sharing with domain restriction or public: no extra cost

That is an 83% reduction in ongoing cost, and the 50 viewers do not have to be internal employees with Microsoft accounts — they can be customers, partners, vendors, or contractors.

When to stick with Power BI

If your organization already has Microsoft 365 E5 licensing that includes Power BI Pro for every employee, and all your reports go to internal viewers, Power BI is the path of least resistance. The licenses are sunk cost. The sharing works. Do not rebuild anything.

When to switch

If any of these are true, at least consider the custom-dashboard path for your next new report:

You are paying per-viewer license fees out of a specific team’s budget
You want to share outside your company without making data public
The report aesthetic matters (customer-facing, marketing, board-facing)
You need to embed in a non-Microsoft surface
You want mobile-first design
You are tired of waiting for Power BI’s render times

The math only gets more favorable as viewer count grows.

The bigger picture

Power BI was designed for a world where building a custom dashboard required a frontend team, a backend team, a DevOps team, and six weeks. In that world, a drag-and-drop tool that gave you 80% of a dashboard for 20% of the effort was a reasonable trade, even with the licensing tax.

That world has changed. AI coding tools can produce the other 20% in an afternoon. Static hosting has eliminated the infrastructure work. The drag-and-drop speed advantage is largely gone. What remains is the licensing tax, the design ceiling, and the ecosystem lock-in — and those are increasingly hard to justify.

For the deeper argument including specific cost breakdowns versus Tableau and Looker, see You Don’t Need Tableau Anymore. For the step-by-step technical setup including automatic data refresh from BigQuery or Snowflake, see Build an Auto-Refreshing Dashboard with React, BigQuery, and Deloc. For the specific workflow of taking a dashboard you built with Claude and turning it into a shareable URL, see How to Share a Dashboard Built with Claude.

Summary

Seven built-in ways to share a Power BI report, each with tradeoffs: licensing cost, ecosystem lock-in, or a binary “internal-or-fully-public” choice with no middle ground. For the reports where those tradeoffs are painful, an eighth option has emerged — build a custom dashboard in React, deploy it as a URL with npx @deloc/cli deploy, and skip both the per-seat licensing and the all-or-nothing sharing model entirely.

Pick the method that matches your situation, and stop paying for licenses you do not need.

← Back to blog