Forum Discussion
Kudo CommanderFabric permissions framework
App access doesn't automatically give Read on the semantic model. They're separate permissions, which is why you're seeing this.
1. Read on the semantic model in RW: yes, that's enough. Each user viewing the report needs Read at the dataset level (see Considerations and Limitations). ReadAll is a OneLake-level permission, not a semantic model one, and only matters for Direct Lake on OneLake bypassing the SQL endpoint. Build is not needed for view-only consumption.
2. Workspace access on RW: not required if they have the app. App membership is sufficient. Microsoft actually recommends managing app and semantic model permissions separately for consumers, rather than relying on workspace roles (see Report consumer security planning). You can grant Read on the model directly, or via the app's advanced settings at publish time.
3. Read on the DW entities: depends on how the Direct Lake model is configured. This is the part that matters for your isolation goal.
- SSO (default): the user needs Read on the source DW artifact plus SELECT on the tables (Direct Lake on SQL), or ReadAll / OneLake security role (Direct Lake on OneLake). Breaks the isolation you want.
- Fixed identity (cloud connection, SSO disabled): no DW access needed for end users. The fixed identity (service principal or workspace identity) holds the DW Read + SELECT, and the model fetches data through it. This is the documented "Users can query the semantic model but are denied querying the lakehouse or SQL analytics endpoint" scenario (see Direct Lake security integration).
So minimum for your ReportViewer role: app audience membership + Read on the semantic model. No workspace role, no DW access, assuming the model uses a fixed-identity connection.
First thing to try: just add Read on the semantic model. If the report still fails after that, the model is likely running under SSO and trying to auth the user against DW. Switching the connection to a fixed identity will resolve it without granting DW access to end users.
Best regards!
PS: If you find this post helpful consider leaving kudos or mark it as solution 🙂
Kudo CommanderThanks again, BarbaraC , for the thorough reply.
Re: On the PBI error ("contact the owner...to request access"): this is the standard missing-dataset-permissions message, which is where it gets interesting. If that report is bound to the same thin model, it shouldn't appear at all given you've granted Read. So either it has its own separate connection to DW (DirectQuery against the warehouse?), in which case the user is being asked to authenticate against DW directly and can't, or the Read isn't fully landing on the dataset, possibly an app publishing setting. Worth checking before assuming both errors share the same root cause.
The Power BI *is* using different data sources than the paginated report; I assume that resolving the more general issue of workspace data source access will enable me to modify this report's connections, too, and resolve that issue. Here's hoping.
Advocate IGlad things are pointing in the right direction.
Just a quick note since your phrasing made me wonder: each cloud connection is configured independently, so the PBI report's connections to DW will each need their own fixed-identity setup, but you can reuse the same identity across all of them. Curious to hear how it goes once you've applied the changes, and agree with Community Support that a confirmed working pattern would be useful for others hitting the same scenario.