Share feedback directly with Fabric product managers, participate in targeted research studies and influence the Fabric roadmap.
Sign up nowGet Fabric certified for FREE! Don't miss your chance! Learn more
Hi, one of our more prolific users has set up an app, i think our first. And granted permissions to a number of users including Mrs X to use the app, ie to be be an audience member. I saw Mrs X in the audience list.
Some of the users also have various permissions in the WS where he devloped this app, WS Y. Mine for instance is NOW admin. Mrs X has NO permissions there. I had to get him to give me admin there eventhough i am already admin everywhere else.
the 2 reports he stood up there (and listed in the app) each have 2-3 pages. More importantly (i'll double check) they are sourced by a live connection to an ssas cube over which our AD Group Z has proper permissions. Everyone including Mrs X is a member of that group.
i think his semantic model is in one safe place (so nobody changes it) for both reports, possibly not WS Y.
Admittedly, I have to poke around in his development WS Y and wherever the semantic model is some more but here is what is happening...
Everyone except Mrs X can run reports in the app. Mrs X gets the error you see below. When i think about the purpose of apps it seems foreign to me to think we'll always need to give casual users permissions on WS Y also, in order for them to run reports.
Can the community get us started in the right direction? Except for my fabric license, we run with Pro only for every employee in the company. There could be some licesnses i dont know about.
Solved! Go to Solution.
Hi @db042190
This is almost always a dataset (semantic model) permission issue, not an app or workspace access problem, and your instinct is right: audience users should not need any permissions on the development workspace to consume an app. What’s happening with Mrs X is that, even though she can see the app and the reports, her identity cannot successfully authenticate against the underlying semantic model or the live SSAS connection at runtime. In app consumption, Power BI evaluates permissions in this order: app access → report access → dataset access → external source access (SSAS). If the dataset is stored in a different workspace than WS Y (which is very common for “locked-down” semantic models), Mrs X must explicitly have Build (or at least Read) permission on that dataset, even if she’s in the app audience. Being in the SSAS AD group alone is not sufficient if Power BI cannot pass her identity through because the dataset permissions are missing or misaligned. This is why everyone else works (they likely have dataset permissions indirectly via workspace roles), while Mrs X—who has no workspace access anywhere in that chain—fails. The fix is not to give her access to WS Y, but to locate the workspace that hosts the semantic model and grant her (or an AD group she’s in) Build permission on the dataset. Once that’s done, the app will work as expected without exposing the development workspace, which is exactly how apps are designed to be used.
thx all. i'll look but if our author's intention was to lock down the dataset, doesnt giving her build on that dataset's ws kind of defeat the purpose?
sorry, all along i thought we were talking about permissions on ws's. our author knew right away when i reported back to him (maybe before) that you guys were talking about sm's. he gave Mrs X permission on the sm itself and all worked out. Im starting to wonder if Mrs X wasnt in that specail AD group Z, but he had given her permissions this way, whether it would have worked as well. remember, it is a live connection to a cube.
Hi @db042190
This is almost always a dataset (semantic model) permission issue, not an app or workspace access problem, and your instinct is right: audience users should not need any permissions on the development workspace to consume an app. What’s happening with Mrs X is that, even though she can see the app and the reports, her identity cannot successfully authenticate against the underlying semantic model or the live SSAS connection at runtime. In app consumption, Power BI evaluates permissions in this order: app access → report access → dataset access → external source access (SSAS). If the dataset is stored in a different workspace than WS Y (which is very common for “locked-down” semantic models), Mrs X must explicitly have Build (or at least Read) permission on that dataset, even if she’s in the app audience. Being in the SSAS AD group alone is not sufficient if Power BI cannot pass her identity through because the dataset permissions are missing or misaligned. This is why everyone else works (they likely have dataset permissions indirectly via workspace roles), while Mrs X—who has no workspace access anywhere in that chain—fails. The fix is not to give her access to WS Y, but to locate the workspace that hosts the semantic model and grant her (or an AD group she’s in) Build permission on the dataset. Once that’s done, the app will work as expected without exposing the development workspace, which is exactly how apps are designed to be used.
Hi @db042190,
Are the semantic models that the report is built on in the same workspace as the report/app? If not, then granting access to the app is not enough, you also need to grant access on the semantic models.
Proud to be a Super User! | |
Seems like Mrs X is in the App audience but has no permission on the workspace that contains the semantic model.
For a user to view a report in an app, they must have:
Access to the App
Access to the semantic model the report uses
I believe best practise is to create security groups and govern permissions from there.
Create a security group for:
“App consumers – Dataset access”
Grant that group Viewer on the dataset workspace
Use that group for all app audiences
If you love stickers, then you will definitely want to check out our Community Sticker Challenge!
Check out the January 2026 Power BI update to learn about new features.
| User | Count |
|---|---|
| 20 | |
| 10 | |
| 9 | |
| 8 | |
| 7 |
| User | Count |
|---|---|
| 51 | |
| 42 | |
| 30 | |
| 27 | |
| 25 |