Fabric permissions framework

[MarkPalmberg]

Here's our setup:

DataWorkspace (DW)

ReportingWorkspace (RW)

DW is permissioned very tightly. Our ReportAdmin user has DW access to build entities there.

The RW has a single, direct lake, "thin" semantic model that's built off MLVs created in DW; we're trying to avoid landing any sensitive data from DW in RW or giving report users access there.

I have a paginated report in RW that runs a DAX query against the semantic model in RW. It's sitting in an app on the RW workspace.

My ReportViewer user has View access to the RW workspace but is unable to render the paginated report.

My question:

• What's the bare minimum level of access I need to give my ReportViewer user to be able to execute this paginated report?
  • Do they need ReadAll access to the semantic model in RW?
  • Do they have to have RW workspace access if they have access to the app in the RW workspace?
  • Do they need Read access to the entities on which my MLVs are built back in the DW workspace?

Thanks in advance for any guidance you can provide.

[v-shchada-msft]

Hi @MarkPalmberg,
Thank you for reaching out to the Microsoft Fabric Community Forum.

Just checking in, were you able to resolve the issue? If not please feel free to share an update, and we'll be happy to assist further.
Your feedback will also help others facing similar challenges.

Thank you.

[BarbaraC · Accepted solution]

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 🙂

[Andrew_Farmer]

Great article Barbara... sometimes the small things are what gives us the biggest headaches 🙂

[MarkPalmberg]

@BarbaraC 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:

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!

[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.

[BarbaraC]

Glad 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.

[v-shchada-msft]

Hi @MarkPalmberg,
Thank you for posting your query in the Microsoft Fabric Community Forum and also for the update.

After trying the suggested configuration and permission changes, could you please let us know whether the issue has been resolved or if you are still running into any problems? We would be happy to assist further if needed. Sharing an update on the outcome could also help other community members facing similar cross-workspace Direct Lake scenarios.

Thanks and Regards.

[MarkPalmberg]

@v-shchada-msft , I was able to implement the permissions model set out by @BarbaraC, above. I'm still waiting for my IT department to add our Workspace identity to the Azure Entra user that has read access to my data workspace, so I'm using my user at the moment.

[v-shchada-msft]

Hi @MarkPalmberg,

Thank you for the update. If you have any more questions, please feel free to create a new post. We're always happy to help.

Thank you.