Forum Discussion
Power BI App Audiences vs Workspace Access – Recommended Microsoft Architecture for Production?
Hi everyone,
I'm looking for guidance on the recommended Microsoft approach for a production Power BI deployment.
Current Setup
We have a Production Power BI Workspace.
Reports are published from Power BI Desktop to this workspace.
We plan to distribute reports using a Power BI App with multiple App Audiences, for example:
Helpdesk Audience
SalesDesk Audience
Each audience should only see its assigned reports.
Problem
The report developer only has the Contributor role in the workspace.
Because of this:
He cannot access Manage Access.
He cannot see who already has workspace access.
He cannot verify whether business users already have Viewer, Member, or Contributor roles.
If business users already have workspace access, they can access content directly from the workspace instead of through the App.
Questions
Is Microsoft's recommended practice to keep business users completely out of the workspace and grant them access only through the Power BI App?
If the workspace is shared across multiple teams and we don't control workspace membership, can App Audiences still be considered a secure way to restrict report visibility?
If we cannot verify or manage workspace membership because we only have Contributor access, what is the recommended production architecture?
Should we request Member access?
Should we request a dedicated Production workspace?
Or is there another Microsoft-recommended approach?
How do organizations typically handle this in enterprise environments where report developers are not workspace administrators?
I'm looking for guidance based on Microsoft best practices or official documentation, especially from Microsoft MVPs or anyone who has implemented this architecture in production.
Thank you!
Yes, the recommended pattern is exactly that: keep business users out of the workspace entirely and give them access only through the Power BI App. Workspace roles (Admin, Member, Contributor, Viewer) are for the people who build and manage content. The App is the consumer-facing layer, and App Audiences are how you segment which reports each group sees.
If a business user has any workspace role, they can open reports directly from the workspace and completely bypass the App and its audience filters. That is why the separation matters.
On the Contributor visibility issue: Manage Access is only available to Admin and Member roles. It is by design, so a Contributor cannot see or manage membership. Either the workspace Admin owns membership review, or they temporarily promote the developer to Member so they can check.
Practical setup I use in production: Admin/Member for the dev team, no direct workspace access for business users, publish the App, and grant App access per Audience to security groups. Add RLS on the semantic model as a safety net so any audience misconfiguration cannot leak data.
If this helped, a thumbs up and marking it as the solution would be appreciated.
Best,
Shai Karmani
4 Replies
Yes, the recommended pattern is exactly that: keep business users out of the workspace entirely and give them access only through the Power BI App. Workspace roles (Admin, Member, Contributor, Viewer) are for the people who build and manage content. The App is the consumer-facing layer, and App Audiences are how you segment which reports each group sees.
If a business user has any workspace role, they can open reports directly from the workspace and completely bypass the App and its audience filters. That is why the separation matters.
On the Contributor visibility issue: Manage Access is only available to Admin and Member roles. It is by design, so a Contributor cannot see or manage membership. Either the workspace Admin owns membership review, or they temporarily promote the developer to Member so they can check.
Practical setup I use in production: Admin/Member for the dev team, no direct workspace access for business users, publish the App, and grant App access per Audience to security groups. Add RLS on the semantic model as a safety net so any audience misconfiguration cannot leak data.
If this helped, a thumbs up and marking it as the solution would be appreciated.
Best,
Shai KarmaniWorkspace roles control access, and app audiences only work when users have no workspace permissions, and business viewers stay out of the workspace while the admin removes any remaining roles. In production, developers use the Member role to verify workspace access or a dedicated production workspace run by admins, with business users reading only through the app.
Hi manoj_0911 - One additional consideration is Build permission on the semantic model. Even if users consume reports through the App, granting Build allows them to create their own reports against the semantic model. If self-service BI isn't intended, only grant Build to users who require it.
Also, App Audiences control content visibility, not data security. If different user groups should see different subsets of data within the same report, implement Row-Level Security (RLS) (or Object-Level Security where applicable) on the semantic model. App Audiences and RLS complement each other but serve different purposes.
Hope this helps!
Hi manoj_0911,
Thank you for posting your query in the Microsoft Fabric Community Forum, and thanks to rajendraongole1 & Kagiyama_yutaka & Shai_Karmani for sharing valuable insights.
Could you please confirm if your query has been resolved by the provided solutions? This would be helpful for other members who may encounter similar issues.
Thank you for being part of the Microsoft Fabric Community.
