A common assumption is that Power BI customer report delivery means sending a report link to an outside user. The correction is important: secure external access is a delivery architecture, not a single sharing feature. The right design connects Power BI licensing, Microsoft Entra ID identity, workspace or app permissions, Row-Level Security, tenant settings, and the customer experience. For some audiences, that means guest access to a Power BI app. For others, it means a customer portal with Power BI Embedded. Email subscriptions and exported files serve different purposes and should not be treated as equivalent to interactive report access.
The delivery method determines who can view the report, which data they can see, how they authenticate, how licenses are assigned, and how access is removed. A report that works for an internal analyst may fail for a customer because the customer has a different identity, license, tenant, browser session, or permission path.
What Does Power BI Customer Report Delivery Include?
Power BI customer report delivery is the process of giving external customers access to interactive reports, scheduled snapshots, exports, or embedded analytics while preserving data separation and administrative control. It includes more than publishing a report. We need to define the audience, choose the delivery channel, configure identity and permissions, validate the data model, and establish an operating process for onboarding and offboarding customers.
The core components are:
Power BI content: Reports, dashboards, semantic models, apps, and subscriptions.
Identity: Internal users, Microsoft Entra B2B guest users, customer identities, or application-managed users.
Authorization: Workspace roles, app permissions, item permissions, and Row-Level Security.
Capacity and licensing: Pro, Premium Per User, Power BI capacity, Microsoft Fabric capacity, or an embedded model.
Delivery experience: Power BI Service, a customer portal, an embedded page, email, PDF, PowerPoint, or another export.
Governance: Approval, monitoring, access reviews, audit records, and removal procedures.
These components interact. For example, Row-Level Security filters the data returned by a semantic model, but it does not automatically give a customer permission to open a report. Likewise, putting a report in a workspace does not automatically create a polished customer-facing experience.
Customer reporting also has a content ownership question. Someone must maintain the semantic model, review customer mappings, monitor refresh failures, and respond when a customer changes employees or domains. That operating model matters as much as the initial Power BI report design.
Which Power BI Delivery Method Fits External Customers?
The best method depends on whether customers need interactive analysis, a branded experience, simple notifications, or a controlled document. Power BI Service sharing is appropriate for some external audiences, while embedded analytics is better when the report must live inside an application or portal.
| Delivery method | Best fit | Identity and access pattern | Main control to validate | Important limitation |
|---|---|---|---|---|
| Power BI app with guest access | A small or moderate set of known customer users | Microsoft Entra B2B guest accounts | Tenant settings, app access, guest permissions, and RLS | Customers interact with a Microsoft-facing experience and may need appropriate licensing |
| Workspace sharing | Controlled collaboration with a limited external group | Named users with workspace permissions | Workspace role assignment and least privilege | Broad workspace access exposes more content and administrative surface |
| Power BI Embedded in a portal | A branded customer portal or product experience | Application-managed identity and portal authentication | Token generation, customer-to-data mapping, and tenant isolation | Requires application development and careful backend security |
| Scheduled email subscriptions | Customers who need recurring reminders or snapshots | Recipient email identity and subscription settings | Recipient list, attachment behavior, and data sensitivity | Email is not a substitute for interactive authorization |
| PDF or PowerPoint exports | Formal reporting, archiving, or offline review | File distribution controls | Storage location, encryption, expiration, and recipient handling | Exports may contain more data than the viewer should receive |
| Secure link to a report | Quick access for a known, authenticated audience | User authentication through Microsoft identity | Link permissions and sign-in behavior | A link alone does not enforce customer-level data separation |
The distinction between Power BI sharing and Power BI Embedded is especially important. Sharing gives a user access through Power BI. Embedding places analytics inside an application and lets the application manage much of the surrounding customer experience. Embedded analytics still requires a secure method for generating access tokens and connecting the authenticated customer to the correct data scope.
Our Power BI image hosting guidance covers a related issue that teams sometimes overlook: external report delivery also depends on how report images and other assets are hosted. A report may have correct viewer permissions while an image URL remains inaccessible, public, stale, or dependent on an internal session.
When Should We Use Guest Access Instead of Power BI Embedded?
Use guest access when customers are known people who can authenticate with Microsoft Entra ID and the Power BI experience itself is acceptable. Use Power BI Embedded when customers need a branded portal, application-level navigation, a unified login experience, or access for users who should not manage Power BI permissions directly.
With guest access, the customer is represented as a guest user in the organization’s directory. The external user may sign in with a work account, school account, Microsoft account, or another identity supported by the configured cross-tenant access policies. The organization remains responsible for determining whether external collaboration is allowed and which users or domains qualify.
This approach works well when:
Customers need interactive filtering and drill-through.
The number of users is manageable through directory-based administration.
Customers accept opening reports through Power BI.
The organization wants to use app audiences, security groups, and Microsoft Entra governance.
The licensing and capacity model supports the intended audience.
Embedded analytics takes a different route. The customer signs in to the business application, and the application requests an embed token or uses an appropriate embedding architecture. The application then determines which customer account is viewing the report and passes the permitted scope into the reporting experience.
That creates more design responsibility. The portal must prevent one customer from requesting another customer’s report or token. The backend must validate the customer’s authorization on every relevant request. Frontend parameters alone are not a security boundary.
Power BI Embedded also does not remove the need for a well-designed semantic model. The report still needs a reliable customer key, a relationship strategy, and tested Row-Level Security or another valid isolation mechanism.
How Does Row-Level Security Protect Customer Data?
Row-Level Security, or RLS, restricts the rows returned from a Power BI semantic model based on the viewer’s identity or assigned security context. It is the primary data-isolation mechanism for many multi-customer reports, but it only works when the model, identity mapping, and test process are aligned.
A common pattern uses a security table with fields such as:
| Field | Purpose |
|---|---|
| Customer ID | Identifies the customer or account |
| User principal name | Maps a signed-in user to an allowed identity |
| External object ID | Provides a stable directory-based identity reference |
| Role name | Supports different access policies when needed |
| Active status | Prevents inactive assignments from returning data |
The security table connects to the customer or account dimension in the semantic model. A role then filters the security table using the signed-in user identity, commonly through the USERPRINCIPALNAME() DAX function in Power BI. The relationship must propagate that filter to the fact tables that supply report values.
RLS needs deliberate testing. We should test an internal user, an external guest user, a user assigned to multiple customers, an unassigned user, and an offboarded user. Testing only as the report owner is not enough because the owner often has elevated permissions that bypass the behavior ordinary viewers experience.
RLS also does not protect every artifact automatically. Exported files, paginated reports, dataflows, source systems, and image repositories require their own review. A report might filter its visible rows correctly while a downloadable file, tooltip image, or linked document reveals information through a separate path.
If an external customer needs a distinct report design or completely separate model, separate semantic models may be safer and easier to govern than one highly complex model. A single multi-tenant model improves reuse, but it increases the importance of relationship direction, filter propagation, role definitions, and automated testing.
What Licensing and Capacity Issues Affect External Report Access?
Licensing affects whether a customer can open an interactive report, not merely how the report is delivered. The exact requirement depends on the workspace capacity, the report type, the user’s identity, and the embedding approach.
Power BI Pro and Premium Per User licensing are user-based options. They typically matter when users need to publish, share, collaborate, or consume content in licensing scenarios that do not provide capacity-based consumption. Power BI capacity and Microsoft Fabric capacity shift more of the consumption model toward dedicated capacity, but they do not eliminate the need to evaluate the specific audience and feature requirements.
Power BI Embedded introduces another architecture. In an application-owned experience, the customer may authenticate through the application rather than directly through Power BI. The application still needs the appropriate capacity, token flow, and authorization model. It also needs a plan for report authors and administrators, who may have different licensing requirements from external viewers.
Before selecting a delivery model, document these questions:
Are customers viewing reports through Power BI or through a separate application?
Does each customer have a named identity, or does the application manage the user session?
Are reports hosted in a workspace with the required capacity?
Do report creators, administrators, and support users have the access they need?
Are subscriptions, exports, mobile access, and paginated reports part of the requirement?
What happens when a customer changes domains, contacts, or licensing arrangements?
Licensing guidance changes as Microsoft updates Power BI and Fabric capabilities. We should validate the current Microsoft licensing terms before committing to a customer-facing design, especially when the audience spans multiple organizations or countries.
How Should External Customer Access Be Secured?
Secure external access starts with identity and ends with lifecycle management. A customer should not receive an anonymous URL to sensitive report content unless the content is intentionally public and the organization has accepted the exposure.
The security design should include:
Authenticated access: Require a verified identity for confidential reports.
Least privilege: Give customers access to the report or app they need, not the entire workspace.
Tenant controls: Review external sharing, guest access, cross-tenant access, and export settings.
RLS validation: Test the actual customer identity and customer-to-data mapping.
Link discipline: Treat report links as entry points, not as authorization by themselves.
Export controls: Decide whether customers may export data, copy visuals, print, or receive email attachments.
Offboarding: Remove access when a user leaves, changes role, or no longer represents the customer.
Monitoring: Review sign-in events, audit activity, sharing changes, refresh failures, and unusual access patterns.
Microsoft Entra B2B collaboration provides a practical foundation for many known external users. Cross-tenant access settings add another policy layer by controlling how collaboration works with specific external organizations. Those controls should be considered alongside Power BI tenant settings rather than configured in isolation.
A secure architecture also limits sensitive fields in the semantic model. RLS is not a reason to load every column into a report. Remove unnecessary personal information, restrict exportable fields, and separate operational identifiers from values intended for customer viewing.
We should also distinguish authentication from authorization. Authentication proves who the user is. Authorization determines which report, page, row, export, or customer account that user can access. Both must succeed.
How Do Customer Portals Improve Power BI Report Delivery?
A customer portal improves Power BI report delivery when the reporting experience needs to feel like part of a product or service rather than an internal analytics workspace. The portal can provide customer navigation, help content, account settings, document access, support workflows, and embedded reports in one place.
The portal still needs a clear security boundary. The application should retrieve the customer identity from its authenticated session, query the server for the customer’s permitted report context, and generate the embed configuration only after authorization succeeds. It should not trust a customer ID supplied by a browser form or URL parameter without server-side validation.
A portal also helps with lifecycle tasks. Administrators can connect customer accounts to approved users, suspend access without editing multiple Power BI workspaces, and present a consistent offboarding process. For organizations delivering several report types, the portal can separate operational, financial, and executive content while keeping the customer’s navigation simple.
Portal design has tradeoffs. It requires development, hosting, authentication integration, monitoring, and maintenance. It also creates responsibility for handling session expiration, token renewal, browser behavior, responsive layouts, and accessibility.
A branded portal is not automatically more secure than Power BI Service sharing. Its security depends on the implementation. The portal adds control and flexibility, but it also adds application code that must be reviewed and tested.
How Should We Handle Scheduled Reports and Exports?
Scheduled reports and exports should be treated as separate delivery channels with separate controls. A customer who is authorized to view a filtered interactive report is not automatically authorized to receive every export format or email attachment.
Email subscriptions work well for reminders, recurring summaries, and low-friction communication. They are less suitable for highly sensitive data because email forwarding, mailbox compromise, incorrect recipients, and uncontrolled local storage remain risks. Confirm whether the subscription sends a link, an image, or an attachment, and test the output with the intended external identity.
PDF and PowerPoint exports require a content review. A page that looks appropriately filtered in the interactive report might include hidden visuals, expanded details, or data that becomes visible through export behavior. Test the exact format customers will receive, not only the browser view.
For recurring delivery, define:
Who approves the recipient list.
Whether the message contains a link, image, or attachment.
Whether the export includes customer identifiers or sensitive fields.
How delivery failures are detected.
How a user is removed from future subscriptions.
Where downloaded files may be stored.
Our article on Power BI reporting applications for accountants discusses customer-facing reporting patterns such as subscriptions and branded access. The same design principle applies across industries: a recurring report should fit the customer’s operating workflow without weakening data controls.
What Should We Test Before Launching External Report Delivery?
A launch test should cover the complete customer journey, from invitation or portal login through report use, export, support, and offboarding. Testing only the report author’s view leaves the most important failure points unexamined.
The minimum test matrix should include:
A customer with access to one account.
A customer with access to multiple authorized accounts.
A user with no customer mapping.
An expired or disabled user.
A user from an unapproved external domain.
A customer attempting to open a copied report link.
A customer downloading or exporting an allowed format.
A customer using a mobile browser if mobile access is supported.
A failed dataset refresh before the customer opens the report.
A removed user attempting to reuse an old session.
Validate more than the visual output. Check the semantic model filters, drill-through behavior, bookmarks, tooltips, export contents, subscriptions, linked documents, and images. If the report depends on scheduled refresh, test what customers see when data is stale or a refresh fails.
Performance testing also matters. External users may connect from different networks and devices than internal analysts. Measure report opening time, page transitions, slicer behavior, and export duration under realistic concurrency. A report that loads acceptably for a small internal team may need model optimization or capacity planning before broader customer delivery.
For additional Power BI delivery context, we have documented a broader approach to analytics implementation without relying on a customer-facing sharing model as a substitute for security design. The practical lesson is straightforward: report development, access configuration, and validation belong in the same delivery plan.
Common Failure Patterns in External Power BI Sharing
The most serious problems come from treating a delivery shortcut as a security model. A link is not a permission policy, and a filtered visual is not proof that every export is filtered correctly.
Frequent failure patterns include:
Assigning RLS roles but not mapping external identities to the security table.
Testing only in Power BI Desktop and not in Power BI Service.
Giving external users workspace access when app access would be sufficient.
Assuming a customer’s Microsoft 365 permissions apply to Power BI content automatically.
Embedding a report while trusting a customer ID passed from the browser.
Allowing exports without reviewing the fields and pages included in the output.
Sending confidential report attachments through ungoverned email workflows.
Leaving subscriptions active after a customer contact is removed.
Using one broad role for every customer instead of testing customer-level filters.
Treating a portal login as proof that the user can access every report behind it.
The fix is not always a more complex architecture. A known audience with a small user population may be safer and easier to manage through guest access and a Power BI app. A large customer population with a branded application may justify embedding. The correct choice follows the identity, licensing, data isolation, and operational requirements.
How Do We Choose a Practical Delivery Architecture?
Start with the customer experience, then work backward to identity and data security. Do not choose embedded analytics simply because it looks more polished, and do not choose a shared link simply because it is quick to create.
A practical decision sequence is:
Define whether customers need interactive reports, scheduled summaries, exports, or all three.
Identify the customer identity source and whether users are known individually.
Map each customer to the data they are authorized to see.
Select Power BI Service sharing, guest access, a customer portal, or embedded analytics.
Confirm licensing, capacity, tenant settings, and export behavior.
Build RLS or separate models based on the required isolation level.
Test normal use, misuse, offboarding, and failure scenarios.
Document ownership for report changes, access reviews, refresh monitoring, and support.
Versich helps organizations evaluate Power BI environments, reporting architecture, data modeling, governance, and security as connected decisions. If you are defining an external reporting model, contact our team to discuss the requirements, constraints, and implementation path before customer access is enabled.
Plan the Next Step for Secure Customer Reporting
The most important decision is not whether to send a Power BI link or build a portal. It is whether the selected delivery path connects identity, licensing, authorization, customer-level filtering, exports, and lifecycle management into one controlled design.
Begin by documenting the customer audience, required experience, data boundaries, and access lifecycle. Then test the chosen architecture with real external identities, including users who should have no access. That next step turns external report delivery from a sharing task into a dependable reporting service.
