External Users Access to Report

Hi DPCCGF​,

Unfortunately, sharing a report with 750 external users is going to be a nightmare :(.

To share the report directly with them, you would need to add all users as B2B guests in your tenant, and then you can share the reports with them the same way you would share them with your colleagues. 

Another option would be switching to an embedded model. 

https://learn.microsoft.com/en-us/power-bi/developer/embedded/embedded-analytics-power-bi

In which you develop a custom portal/app for the external users to access, and embed your report into that app. 

The third option is to open the report to the public internet and let anyone who has the link access it. This is probably a very bad idea unless the data is public data. 

Hello DPCCGF​,

I would look at this as an identity and access design problem rather than trying to manage 750 individual report shares.

If the officers have Microsoft Entra accounts, B2B with security groups could work well. You can manage access by agency and use RLS if each agency should see different data.

If they do not have Entra identities, then Power BI Embedded with a controlled application or portal is another option.

I would rule out Publish to web for this type of data.

The main thing I would clarify first is whether all 750 officers should see the same data. If they do not, that requirement will drive the security design more than the number of users.

Hi DPCCGF​  , 

Before going into the solution, two things decide almost the entire architecture worth nailing these down first:

1. Is the data public, or restricted?
This is the big fork. If it's genuinely public/non-sensitive information, Publish to Web is a 30-second answer — anonymous link, zero per-user licensing, no accounts. But for anything law-enforcement/field-operational, that's almost certainly off the table, because Publish to Web makes the report fully public with no security whatsoever. If the data is restricted (my assumption), you're in authenticated territory and the real options below apply.

2. How complex is the RLS — do all 750 officers see the same data, or is it filtered per agency/officer?Everyone sees the same data → no RLS needed; distribution is purely a licensing/hosting question.Each agency or officer sees only their slice → you need RLS in the AAS model (static roles per agency, or dynamic RLS keyed on the officer's identity/UPN). Dynamic is what keeps this from becoming a "security nightmare by user" — one role, filtered by a lookup, instead of 750 hand-managed assignments.

Once those two are answered, it comes down to two viable distribution models for an audience this size (per-user Pro at 750 seats is the thing you're rightly trying to avoid):

Option A — Fabric F64+ capacity, viewed in the Power BI service.If the officers have Entra identities in your tenant, host the report + a connection to the AAS model in a workspace on F64 or above, where consumers need only a free Fabric license rather than Pro. RLS roles in AAS are honored automatically based on their signed-in identity. Cleanest if they're already in your directory.
Option B — Power BI Embedded (app-owns-data) on a Fabric capacity.
If the officers don't have Microsoft accounts, or you want to deliver this inside a field app/portal, this is the standard pattern: a service principal connects on behalf of all viewers, so individual officers never authenticate to Power BI directly and never need a license. Crucially for your RLS: row-level security is passed through the embed token, so each viewer sees only their own data — you set the effective identity/roles against the AAS model per token. This is the usual answer for large field audiences without directory accounts.

My assumption : restricted data + a large field workforce almost always lands on Option B with dynamic RLS, since it sidesteps both per-user licensing and per-user access management. If the officers are already Entra users in your tenant, Option A on F64 is simpler and cheaper to operate.

AAS is on Microsoft's long-term migration path toward Fabric/Power BI Premium semantic models, so if this is a new enterprise build it's worth confirming the current AAS + embedded guidance.

Thanks,
Natarajan M

If you found this helpful, please consider giving it a Kudos and marking it as the accepted solution — it goes a long way in helping others facing the same issue.

🏆Best Solution for Enterprise BI — 2026 Microsoft Fabric Semantic Link Developer Experience Challenge
👉Microsoft announcement · View the winning notebook

For more Power BI tips and discussions, let's connect on LinkedIn.

I have made use of an LLM to help me structure my answer better.
The technical diagnosis and advice were formulated by me according to my experience in troubleshooting and knowledge about the limitations.
The AI provided help with phrasing only, not with formulating the answer itself.
Should you find any parts that might be unclear or need clarification, feel free to contact me directly.

Hi. The tricky thing here is AAS. Sharing external could be a thing but many have configured, in your case the AAS make it an additional security configuration. The embedding escenario might be a good fit for you. In case you don't want to develop a custom platform for that, there are already third party tools that would handle it for you, for example https://pibi.com.ar/?lang=en

That way you share with the platform with a capacity license instead of going one by one the licenses. The AAS would be configured for only one user, the service principal (service account).

I hope that helps,

HI DPCCGF​,

Have you had a chance to review the solution shared by ibarrau​? If the issue persists, feel free to reply so we can help further.

Thank you.

Hi DPCCGF​ ,

For 750 external field users, the answer is app-owns-data embedding, not per-user access. You embed the report in a web app, authenticate the officers with your own auth, and the app connects to Power BI/AAS through a single service principal. The 750 never need Power BI licenses or guest accounts in your tenant, so you skip the whole per-user B2B security nightmare. If different agencies should only see their own data, you enforce that with AAS roles and effective identity in the embed token, so isolation is handled centrally rather than per user. (Skip Publish to Web here, it's fully public, which is a non-starter for law enforcement data.)

You can build this yourself with the powerbi-client SDK, but at 750 external users it's real infrastructure to stand up and maintain: capacity, embed token generation and refresh, and per-agency RLS. That's exactly the problem we solve at DataTako, an out-of-the-box embedding layer that handles the tokens, the licensing side, and the agency isolation for you, so you get the officers into the report without wiring it all up yourself. Happy to walk you through how it'd map to your AAS setup if useful.

Paco
Helping data analytics leaders distribute their reports

Hi DPCCGF​,

Checking in to see if your issue has been resolved. let us know if you still need any assistance.

Thank you.