The Trade-Off You're Actually Making
Power BI handles internal sharing well, anyone inside the organization with a license sees reports without much friction. Clients, contractors, and other outside parties are a different problem, since buying each of them a Power BI license just to view a dashboard rarely makes sense.
Three approaches solve this without requiring a license for every external viewer: a secure Power Pages portal, a public link, or scheduled PDF exports. None of them is universally correct. Each one sits at a different point on the same line, with data security at one end and low cost and setup effort at the other, and picking between them is really about deciding where on that line a given report actually needs to sit.
Comparing the Three Paths
Before getting into how each one works, it's worth seeing all three side by side. The shape of the trade-off becomes obvious quickly.
| Public Link | Export to PDF | Power Pages | |
|---|---|---|---|
| Setup effort | Minutes | Minutes, or a quick Power Automate flow for scheduling | Around 30 working hours of development |
| Security | Low: links are guessable, forwardable, and often indexed by search engines | Low: PDFs can be forwarded freely and never expire | High: data stays secure, access is authenticated |
| Interactivity preserved | Yes, full interactive report | No, static file only | Yes, full interactive report |
| Licensing required | Power BI Pro | Power Automate Cloud Flow | Power Pages license, plus Microsoft Fabric if row-level security is needed |
| Typical monthly cost | Around $14 | Around $15 | $180 to $340 or more |
Cost and security move in opposite directions here, more of one almost always means less of the other. The rest of this guide walks through each method, starting with the fastest and ending with the most secure.
Public Link: The Fastest Way Out the Door
Generating a public link is the path of least resistance, and it requires nothing beyond a Power BI Pro license. Once a report is published to the Power BI service, opening it and going to File, Embed Report, Publish to Web (Public) brings up a shareable link and matching HTML code, the link can go straight into an email, and the HTML code works for embedding the report into a web page or portal.
The appeal is obvious: a fully interactive report, live in someone's inbox, in a couple of clicks. The catch is that none of the usual access controls apply once that link exists. Search engines index these links, and a fair number of Power BI consultants who've shared sample work this way have ended up ranking for searches like "financial Power BI dashboard" without intending to. Anyone holding the link can forward it freely, and a viewer can export the underlying data straight out of any visual into Excel. None of that matters much for genuinely public information. For anything sensitive, it's worth treating this option with real caution.
Export to PDF: Same Idea, Less Interactive
Exporting to PDF solves a slightly different problem: distributing a snapshot rather than a live, browsable report. A manual export, through the Power BI service's Export to PDF option, covering either a single page or the full report, takes a couple of clicks and produces a file that can be emailed out immediately.
Automating that process with a scheduled Power Automate flow turns it into something closer to a recurring report delivery, triggered on a schedule or off an event like a semantic model refresh, for the cost of a single Power Automate Cloud Flow license, generally cheaper than provisioning multiple Power BI licenses just for viewing.
What's lost in the trade is the report itself. A PDF has no cross-filtering, no bookmarks, no drill-through, just whatever the page looked like at export time. PDFs also travel freely once sent, anyone holding the file can forward it indefinitely, and unlike a public link, there's no way to revoke access after the fact. Once it's out, it's out.
Power Pages: Built for When Security Actually Matters
Power Pages takes considerably more setup than the other two options, but it's the only one of the three built around genuine access control rather than working around the absence of it. Three technologies work together here: Power BI builds the report itself, Power Pages provides the client-facing portal for registration, login, and report access, and Microsoft Purview, formerly Azure Active Directory, manages user identity and can apply row-level security.
What You'll Need Before Starting
- A Power Pages license, roughly $180 a month, which covers up to 100 authenticated users.
- A Power BI license appropriate to how access gets restricted: a standard Power BI Pro license is enough if access roles will be set manually, while row-level security specifically requires a Microsoft Fabric license, $160 a month or more.
- Access to the Azure portal, needed to manage the cloud resources, including Power BI Embedded capacity and resource groups, that the portal depends on.
The benefit this buys is real: full interactivity preserved, genuine authentication, and a portal that can be branded completely, users interact with what looks like your own product, with no visible sign that Power Pages or Power BI sits underneath it. The cost is mostly time, around 30 working hours of development on top of the ongoing licensing.
Building the Portal
A new Power Pages site starts from the New Site button after signing in. Ready-made web parts cover a fast setup, or the portal can be built more precisely through Visual Studio for teams that want finer control. At minimum, a portal needs a sign-in screen and a page to display the embedded Power BI report. Visitors hit a registration screen first, and only once they're authenticated do they reach anything past it, with their details landing in a Dataverse contact table that later powers access control.
With pages built, the Power BI report itself goes into the portal through a Power BI web part: generate a public embedded link from the report and drop it into the web part as an iframe. Once a user signs in successfully, the portal sends them straight to that report page.
Choosing How Access Gets Restricted
Restricting what each logged-in user can see comes down to a choice between two approaches, and the right one depends mostly on how many clients need separate access.
Web roles in Power Pages work well for a smaller, fairly static set of clients. A new role gets created manually for each one, and that role controls which content, including which embedded Power BI dashboard, a given user can reach. It's manual work, but it avoids Microsoft Fabric licensing entirely, a real savings at $160 a month or more.
Row-level security in Power BI takes a different approach: instead of separate roles per client, a single report gets filtered dynamically based on who's signed in. Setting this up means opening the report in Power BI Desktop, loading the Dataverse contacts table that holds every registered user, and building a security rule that filters the report data down to whatever's relevant for the signed-in user specifically. Getting that running requires a working path through Azure:
- Confirm Azure portal access. An active subscription is the baseline requirement for everything that follows.
- Provision Power BI Fabric capacity. Creating this resource in Azure is what upgrades the relevant Power BI workspace to premium, the prerequisite for sharing with unlicensed external users at all.
- Assign that capacity to the workspace hosting the report that's being embedded. A diamond icon appears on the workspace once this is done, confirming premium capability is active.
- Create a resource group tied to the Portal ID, and authorize that resource group to use Power BI APIs through the Power BI admin portal, the step that actually lets the automated, embedded connection function.
Bringing Users In
Once the portal and access model are both working, adding a new external user is an administrative task rather than a technical one. From the Portal Management app, an administrator creates a contact entry for the new user and generates a registration key tied to that contact. That key gets sent to the user directly.
On their end, the user opens the portal's registration screen, selects Redeem Invitation, and enters the key they were given. From there they set up their own login credentials and personal details, completing their own account without needing anyone else involved past that initial key.
Picking the Right One
None of these three methods is the default right answer, the right one depends entirely on what's actually being shared and with whom. A public link is fine for genuinely public information where forwarding and search indexing don't matter. A scheduled PDF export suits a recurring report where a static snapshot is genuinely enough and interactivity isn't the point. Power Pages is worth the setup time the moment the data is sensitive enough that uncontrolled forwarding or accidental public indexing would actually be a problem.
The honest version of the advice: don't pick based on which one's easiest to set up first. Pick based on what happens if the report ends up somewhere it shouldn't, and let that answer decide how much setup time and licensing cost is actually worth spending.
