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 🙂
Advocate IApp 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 🙂
MarkPalmbergBarbaraC I thought I'd update you here, since you were so generous with your reply.
We set up a number of configurations last week.
- My ReportViewer user has app BUT NOT workspace access to my RW. I confirmed that members of that group are able to access my app in the RW.
- The ReportViewer has Read;Build access to the thin semantic model underlying my paginated report.
- There's now a workspace identity on the RW. That identity is used in the cloud connections on the semantic model. There is no workspace identity on the DW.
With the settings above in place, a member of my ReportViewer group gets this error when trying to load the paginated report:
and this error when trying to load a Power BI report in the same app that's also accessing data in DW:
My ReportViewer is NOT an authorized user of the workspace identity in RW; I don't know if this is a requirement.
So, this is where I'm currently stuck. I think the way forward at this point is to use a service account instead of a Workspace Identity for my data connections, since Workspace Identities can't be used with Direct Lake semantic models.
- BarbaraC
HI MarkPalmberg Thanks for the update, the detail helps a lot. Moving to a service principal makes sense, I'd go that route too. Quick note though: Workspace Identity is actually supported with Direct Lake (it's listed in the authentication requirements alongside OAuth and SPN), so that wasn't strictly blocking you. SPN is still the better call for a setup like yours, just for other reasons:
- portable across workspaces
- plays nicer with deployment pipelines
- integrates with Key Vault
- pairs better with embedded scenarios if you ever go that way
But here's the thing, switching to SPN by itself won't fix what you're seeing. The two errors are telling slightly different stories and the SPN switch won't address either of them on its own.
On the paginated error ("Failed to resolve name ''. It is not a valid table, variable, or function name"): the empty name in quotes is the giveaway. Microsoft actually documents that exact error pattern ("Failed to resolve name", "Not a valid table, variable, or function name") as a symptom of missing object permissions when OneLake Security roles are applied. Same root cause family: the model is reachable but the effective identity can't resolve the underlying tables. Consistent with the fixed identity not being able to read DW.
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.
Either way, both point back to the same gap. You mentioned "there is no workspace identity on the DW", but the DW doesn't need its own workspace identity. What matters is that the fixed identity on the RW cloud connection (whether that stays as your current WI or becomes an SPN) is granted permissions as a consumer on the DW artifacts, and that SSO is disabled on the cloud connection so all reads go through the fixed identity rather than the end user's credentials. Per the permission requirements for the "users can query the semantic model but not the lakehouse" scenario, the fixed identity needs:
- Read on the source artifact in DW
- SELECT on the MLV tables (Direct Lake on SQL), or ReadAll or membership in a OneLake security role (Direct Lake on OneLake)
End users get nothing on DW, preserving the isolation between the two workspaces.
One more thing that often catches people out: Direct Lake also checks the semantic model owner's permissions during framing, not just the connection identity. If the model owner doesn't have DW access, you'll see framing errors regardless of how the cloud connection is set up. Cleanest pattern is to take over ownership with the SPN itself once you create it, so it's both the connection identity and the owner. That actually fits the paginated error pretty well, if framing fails silently because the owner can't read DW, Analysis Services ends up serving an empty schema and you get exactly that "failed to resolve name" message.
Last small thing: Build isn't needed for view-only consumption, only Read is. You can drop it from ReportViewer once the rest is sorted.
So in practice:
- Whichever identity you keep on the cloud connection (WI or SPN), grant it Read on the DW artifact + SELECT on the MLVs
- Make sure SSO is disabled on the cloud connection
- Take over model ownership with the SPN
- Check that any other report connection in the app does the same. If the PBI report turns out to have its own DW connection, that one needs its own fixed-identity setup, configured for whatever connection type it's using
Hope this helps!
- MarkPalmberg
Thanks 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.
Great article Barbara... sometimes the small things are what gives us the biggest headaches 🙂