
Sharing Power BI reports with external users is a common but often misunderstood scenario. While it may seem simple on the surface, doing it properly and securely involves many moving parts. I’ve already published a video on this topic, which turned out longer than expected because of the number of details involved.
To make this blog easier to follow and more digestible, I’ve broken the content into a three-part blog series. Each part covers a focused area of the topic:
Part 1 (this blog): Understanding the Problem and Core Concepts This post explains why external sharing can be tricky, the key requirements to get it working, important terminology, user roles, and how the whole process fits together.
Part 2: Hands-On Guide to Setup and Sharing A step-by-step walkthrough of how to share reports across tenants, covering licensing, admin portal settings, inviting guest users, and how report access looks from the guest’s side.
Part 3: Sensitivity Labels, Encryption, and Secure Sharing An in-depth look at what happens when Microsoft Purview sensitivity labels are applied, including access control, encryption, and key admin settings you may need to adjust for secure collaboration.
If you are someone who prefers video over reading, you can watch the full walkthrough here 👇.
Introduction
Are you a Power BI developer or someone in a BI or finance team who needs to share reports with customers, partners, or vendors? If they are not part of your Microsoft 365 tenant, things get a bit more complex than just clicking the “Share” button.
This is a common need, especially in consulting scenarios, but doing it securely and correctly takes more than people often think. It involves both technical setup and a clear understanding of roles and terminology.
What About Power BI Apps?
In Microsoft Fabric, content sharing is usually done through Power BI apps. You create an app from a workspace, assign different audiences to it, and each audience sees only the content they are allowed to view. This approach is often recommended because it provides a clean user experience and makes it easier to manage access to multiple reports or dashboards in one place.
However, there are valid reasons why organisations may choose to share individual reports directly instead of using apps:
- When sharing with external users, some organisations prefer tighter control, only giving access to one report at a time.
- In simpler projects, there might be only one report to share, so creating an app might feel like extra effort.
- Some external users may not be familiar with app navigation. A direct report link sent by email can be easier to use.
- In sensitive scenarios, you might not want to expose any other content in the workspace even if access is restricted.
Regardless of which method you use, the underlying components are often the same. Guest access, user permissions, licensing, and data access all need to be configured correctly. The concepts and steps explained in this series apply to both methods, although we use the report sharing model to walk through the examples.
Requirements
Before we jump into the technical setup, we must understand the different types of requirements involved.
Access Requirements
You need to make sure the external users can be recognised by your Microsoft 365 environment. This is done by inviting them as guest users through Microsoft Entra ID. Only then can they access your content.
Permission Requirements
Once a guest user is added, they need the right permissions. This could be access to a specific report, a workspace, or even an app. Without the right access, they might see the report in their list but won’t be able to open it.
Underlying Data Access
The reports connect to a semantic model containing Row Level Security (RLS) or Object Level Security (OLS), the guest user also needs to be configured to properly access the semantic model, otherwise, even if they can open the report, the visuals won’t load. This part is often missed.
Licensing Requirements
Sharing content with external users requires proper licensing. Either the guest user should already have a Power BI Pro or Premium Per User (PPU) licence, or your organisation needs to assign a licence to them. This is something that should be checked in advance. Learn more about licensing here and here. This is an important point to be aware of that depending on users’ licenses you may not be able to successfully implement a working solution. The following table shows the licensing requirements for a report is shared from Tenant A with a user in Tenant B:
Tenant A (Workspace Type) | Tenant A (User Type) | Can Share | Tenant B (User Type) |
---|---|---|---|
All Workspaces | Free User | ❌ | Not Supported |
Pro Workspace | Pro/PPU/PPU Trial | ✅ | Pro/PPU/PPU Trial |
PPU Workspace | PPU | ✅ | PPU |
Fabric Capacity Workspace (Smaller than F64>) | Pro | ✅ | Pro |
Fabric Capacity Workspace ( From F64 and above) | Pro | ✅ | Pro/Free |
Terminologies
To make sure we are all aligned, here are some key terms used in this series.
- External User: Someone outside your organisation, such as a client or partner, with a different domain name in their email.
- Guest User: An external user who has been invited to access resources in your environment. These users appear in your Entra ID under “Guest users”.
- Microsoft Entra ID (Business-to-Business capability): This system allows external users to log in using their own email and credentials. They do not need to create a separate account.
Guest users often have a username like this:john_doe_example.com#EXT#@yourdomain.com
This means they come from another domain but were added to your tenant.
Roles
To make external sharing work securely, each of the following roles must play a part:
- Entra ID Global Administrator: To invite external users and manage them as guest users.
- Fabric Administrator: Controls tenant-level configuration in the Fabric Admin Portal that allow or restrict external sharing.
- Workspace Administrator: Grants access to reports or workspaces and manages who sees what.
Processes
Here is how an external user becomes a guest and gets access to a report:
- An administrator sends an invitation to the external user.
- The external user accepts the invitation and logs in with their own account.
- They may be asked to consent to permissions during login.
- Once confirmed, they appear as a guest in your Entra ID.
- A user with at least Reshare permission on the report can share the report with others.
When it comes to report sharing, you generally choose between two models:
- Workspace access: The guest user is given the Viewer role on the workspace which means they can see reports in the workspace.
- Specific report sharing: The guest user is given access to only one report or a limited set of reports.
Both methods require careful configuration to avoid accidental data exposure.
Conclusion
In this post, we looked at the challenges and core concepts behind sharing Power BI reports with external users. We explored the different types of requirements that must be met, clarified important terminology, and explained the roles involved in the process.
This is a critical foundation for anyone looking to share reports across organisations in a secure and manageable way. Whether you’re a developer, an admin, or someone supporting end users, understanding how the pieces fit together will save you a lot of confusion later on.
In the next post, we will go hands-on and show how to configure your tenant, invite guest users, and share reports step by step.
Follow me on LinkedIn, YouTube, Bluesky and X (formerly Twitter).
Discover more from BI Insight
Subscribe to get the latest posts sent to your email.