Forum Discussion
I Can't Know Who Has Access To A Report Via APIs
Hello.
I'm an admin of a Power BI environment. We need to know exactly who has access to all reports through workspace membeship, shared links and Apps.
We have all the APIs that can show who has access through workspaces and shares, but there seems to be a huge flaw when it comes to App Audiences. For example:
An App has two reports (R1 and R2) and two audiences (A1 and A2)
A1 can see R1 but not R2
A2 can see R2 but not R1.
Although we will be able to list the members of A1 and A2, we won't be able to tell which audiences they were in and therefore won't know if they have access to R1 or R2.
All the aboove means we can't know for sure who has access to R1 or to R2.
Is there an API that will provide this information that I have missed?
You haven't missed an API, this is a genuine gap. The Apps admin APIs let you enumerate an app's audiences and their members, but they don't expose the audience-to-content mapping, so there's no supported call that tells you "audience A1 can see R1." That's exactly the piece you'd need to reconstruct per-report access, and it isn't surfaced today. The scanner (metadata) API doesn't fill it either.
So the airtight per-report answer isn't available purely from APIs right now. A couple of ways people work around it:
The audience-to-report mapping itself is static and low-volume, and you can read it from the app's configuration in the UI. If you capture that mapping once (A1 → R1, A2 → R2) and keep it current, you can join it to the audience membership the APIs do return, and that reconstructs who can see R1 vs R2. Not fully automated, but reliable as long as the app structure doesn't churn constantly.
If you need it to be fully API-driven and auditable, the cleaner structural fix is one audience per app, or separate apps per access boundary. Then access sits at the app/workspace level, which the APIs report on properly, and you lose the blind spot entirely.
Longer term it's worth logging on the Fabric Ideas site, since audience-level content visibility in the admin API is a real reporting gap for exactly the governance use case you're describing.
5 Replies
Hi RichMiles
Thank you for the detailed example.
Based on the currently documented Power BI REST APIs, there is no API that provides the complete user -> app audience -> report access mapping you are looking for.- Get App Users as Admin returns app users and their access rights, but no audience information.
- Get Apps as Admin returns app details, but not audience membership or audience-to-content mapping.
- Scanner API does not expose app audience information.
Therefore, in your A1/A2 example, the available APIs cannot reliably determine which user can access R1 or R2 through the respective audiences.
The List Item Access Details Fabric Admin API is worth testing, but it is currently in preview and its documented response does not indicate that it resolves app audience membership.
As a governance workaround, consider using dedicated security groups for each audience and maintaining the audience-to-content mapping separately.
If audience-level access reporting is required, I recommend submitting this as a Microsoft Fabric Idea with your user -> audience ->report scenario: https://community.fabric.microsoft.com/t5/Fabric-Ideas/idb-p/fbc_ideas
References:
- Get App Users as Admin: https://learn.microsoft.com/rest/api/power-bi/admin/apps-get-app-users-as-admin
- Get Apps as Admin: https://learn.microsoft.com/rest/api/power-bi/admin/apps-get-apps-as-admin
- Get Scan Result: https://learn.microsoft.com/rest/api/power-bi/admin/workspace-info-get-scan-result
- List Item Access Details (preview): https://learn.microsoft.com/rest/api/fabric/admin/items/list-item-access-details
- Publish an app in Power BI: https://learn.microsoft.com/power-bi/collaborate-share/service-create-distribute-apps
Thanks,
C Srikanth
Community Support TeamYou haven't missed an API, this is a genuine gap. The Apps admin APIs let you enumerate an app's audiences and their members, but they don't expose the audience-to-content mapping, so there's no supported call that tells you "audience A1 can see R1." That's exactly the piece you'd need to reconstruct per-report access, and it isn't surfaced today. The scanner (metadata) API doesn't fill it either.
So the airtight per-report answer isn't available purely from APIs right now. A couple of ways people work around it:
The audience-to-report mapping itself is static and low-volume, and you can read it from the app's configuration in the UI. If you capture that mapping once (A1 → R1, A2 → R2) and keep it current, you can join it to the audience membership the APIs do return, and that reconstructs who can see R1 vs R2. Not fully automated, but reliable as long as the app structure doesn't churn constantly.
If you need it to be fully API-driven and auditable, the cleaner structural fix is one audience per app, or separate apps per access boundary. Then access sits at the app/workspace level, which the APIs report on properly, and you lose the blind spot entirely.
Longer term it's worth logging on the Fabric Ideas site, since audience-level content visibility in the admin API is a real reporting gap for exactly the governance use case you're describing.
Thanks for this. I think this is the best we can offer but I will definitely add it to the ideas site
Hi RichMiles
We would like to inquire whether have you got the chance to check the solutions provided above in community to resolve the issue. We hope the information provided helps to clear the query. Should you have any further queries, kindly feel free to contact the Microsoft Fabric community.
Thank you,
C Srikanth
Community Support TeamHi RichMiles
We haven’t heard from you on the last response and was just checking back to see if you have a resolution yet. And, if you have any further query do let us know.
Thank you.
