Fabric permissions framework

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:

1. Whichever identity you keep on the cloud connection (WI or SPN), grant it Read on the DW artifact + SELECT on the MLVs
2. Make sure SSO is disabled on the cloud connection
3. Take over model ownership with the SPN
4. 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!