Sharing Dashboards With Clients and Contractors Safely

In facility management the reporting problem is rarely the report. It is the sharing. You run a service contract, you build a clean SLA dashboard, and then a client or a subcontractor asks for access. The moment you grant it, you are one careless click away from showing them a slicer that also lists your other clients, a measure that reveals your labour margin, or a bookmark that jumps to the internal commentary page. This guide walks the five realistic ways to distribute a Power BI report to someone outside your organisation, the risk and cost of each, and the four controls I apply every single time before an external person sees anything.

The scenario, and what must never leak

Picture a hard-services contractor reporting to three clients from one workspace. Each client should see reactive response times, PPM compliance and open work orders for their own sites only. What must never cross the boundary: another client's sites, the internal cost or margin columns the operations team uses to price jobs, and the "notes for the account manager" page that lives one tab away from the client view. The failure mode is almost never a hacker. It is a filter that was not applied, an export that was left on, or a link that was pasted into the wrong email. Safe sharing is mostly about closing those three gaps by design rather than by memory.

Five distribution routes, compared

There is no single correct channel. The right one depends on how many external people there are, whether they have a Microsoft account, and how much interactivity they need. Here is how the five options I actually use compare on risk and cost.

Why publish to web is never for client data

Publish to web deserves its own warning because the name sounds harmless and the button is right there. It creates a public URL that anyone can open, anonymously, with no sign-in and no row-level security applied. Search engines can index it. The link can be forwarded to anyone. Microsoft's own documentation is explicit that it is for content you are happy to share with the entire internet. I treat it as banned for anything operational, and on tenants I manage I ask that the publish-to-web tenant setting be disabled outright so it cannot be turned on in a hurry. If you want the reference, it is here Power BI publish to web .

The guest-user reality that catches teams out

Guest access through Azure AD (Entra) B2B is the most common route, and the one that surprises people most, because it involves two tenants, not one. A few realities to plan for. Microsoft's canonical write-up is worth reading before you invite anyone distribute Power BI content to external guest users with B2B .

• Licensing for the external user. A guest still needs a Power BI Pro licence to view Pro content. Either their own organisation assigns them one, you assign one from your tenant, or the content sits on Premium / Fabric capacity so the licence requirement is covered for viewers. This is exactly the trade-off I unpack in licensing and capacity planning.
• Tenant settings that must be enabled. External sharing and guest access are governed by admin tenant settings. If "invite external users" or "guests can access Power BI content" is off, or scoped to a security group the client is not in, your share silently fails. Confirm these before you promise a date.
• Conditional access interactions. Your conditional access policies can apply to guests too. A policy that requires a compliant device or a specific MFA method can block a client who is perfectly legitimate. Test with a real external account, not just your own.
• What the guest sees in their tenant switcher. Once invited, the client signs in with their own account and switches into your tenant using the profile or tenant switcher in the Power BI service. New guests find this genuinely confusing, so I send a two-line instruction with a screenshot every time. It removes most of the "I can't see anything" support tickets.

Four controls to apply before any external share

Whatever route you choose, these four go on before an outsider sees a pixel. None is optional and none takes long once it is habit.

1. Verify RLS with View As, for that specific account. Do not trust that a role exists. Use View As and impersonate the actual security context, then confirm the visuals show only the sites and rows that account is entitled to. The mechanics of getting the roles right are covered in row-level security for multi-site reporting.
2. Decide export and download permissions deliberately. Export to Excel, download the .pbix and "export data" from a visual each punch a hole in your careful filtering if left on by default. Decide per share whether the client may export at all, and turn the rest off rather than assuming.
3. Apply sensitivity labels. A Microsoft Purview sensitivity label travels with the file and can enforce encryption and block onward sharing even after the data leaves Power BI. Label client-facing content so protection follows the data, not just the workspace.
4. Set an access review with an expiry date. External access should never be permanent by default. Attach an expiry and a recurring review so that when the contact changes jobs or the contract ends, access lapses on its own instead of lingering for years.

Worked example: a client-facing SLA pack

Here is how the pieces fit together for the three-client contractor from the top of the article. The goal is a monthly SLA review each client can open live, filtered to their own contract, with no way to reach anyone else's data or your internals.

• Delivery route: a Power BI app with one audience per client. The internal margin and notes pages are simply not included in the app; they stay in a separate operations workspace.
• RLS: dynamic security on a Contract Code column. A mapping table joins the signed-in user's email to the contract codes they own, so one role definition scales to every client without editing DAX per account. Each guest is added to the audience that matches their contract.
• Exports: disabled. This is a read-and-review pack, so export to Excel and export data are turned off at the report and tenant scope, closing the "filtered on screen, unfiltered in the download" gap.
• Access review: quarterly recertification with an expiry. Every three months the account owner confirms each external contact is still correct; anyone not recertified drops off automatically.
• Sensitivity label: a "Client Confidential" label applied so encryption and sharing restrictions follow any content that does leave the service.

The final piece is proof. When a client asks "who on our side has been looking at this," or when your own auditor asks the same about the whole app, you answer from the activity log rather than from memory. A simple pull looks like this.

That returns who viewed which report and when, which is enough to satisfy both the client's question and your own governance. If you want to turn that log into a live picture of who actually uses what, that is the subject of measuring BI adoption with usage data.

Putting it together

Safe external sharing is not one setting, it is a sequence: pick the channel that matches how the client will actually use the report, never reach for publish to web on operational data, plan for the guest-user realities of licensing, tenant settings and conditional access, and apply the four controls of verified RLS, deliberate exports, sensitivity labels and a reviewed expiry before anyone outside sees anything. Do that and the accidental leak stops being a matter of remembering. It becomes something the design simply does not allow.

Independence note: I am a practitioner, not affiliated with Microsoft. Product names and links belong to their owners, tenant settings and licensing change over time, and nothing here is a substitute for your own security and compliance review. Verify against current Microsoft documentation before you configure external access.