Forum Discussion
Issues with Semantic Model sharing
We're trying to share a report with business users at my organization. We've done this before, but now users are unable to see the data from the semantic model. We've isolated the issue to the semantic model sharing, but can't figure out how to fix the permissions.
- Data is in a Fabric warehouse. The users have connect & read access to the warehouse & the schema with the underlying data.
- We've confirmed their permissions to the warehouse work via a connected SQL query in Excel - users are able to refresh the data, without issue
- We've created a semantic model in our Fabric workspace. The storage mode is Direct Lake, and connects to the warehouse tables.
- We've shared the model with business users, with read and build permissions during troubleshooting. Ideally, users will just have read access.
- To test the semantic model connection, we had users try to connect to it in Excel. They can see the semantic model, but can't see any of the underlying tables. With the semantic model that is working, with Read & Build permissions users are able to see both the model & the tables.
- We've shared the Power BI report with users. When they open the report, all visuals fail. Power BI says the issue is that users can't don't have permissions to the underlying data.
Any suggestions on how to fix this, or other troubleshooting we can try? We've tried recreating the semantic models with both live link & direct query, nothing seems to work.
6 Replies
Verify the semantic model's cloud connection. Go to the semantic model settings in the Fabric workspace → Data source credentials. The cloud connection determines the "effective identity" used for data access. If it uses SSO (Single Sign-On), the end user's identity is passed through to the warehouse. If it uses a fixed identity, that fixed identity must have the required permissions. Make sure the connection is set to OAuth 2.0 and that SSO is enabled if you want per-user access.
The cloud connection is set to SSO, which is what we want to have happen - that the user credentials are passed through to the warehouse. The one thing that is different between an older model that's working as intended and this one that is broken is that the first has SQLServer as the data source, and the second has AzureDataLakeStorage as the data source mapping to SSO. They both point to the same warehouse, and as far as I can remember were set up in the same manner.
Hi knoah,
Open the Fabric workspace → find your semantic model
Click the "..." menu → Settings
Under Gateway and cloud connections, look for the Direct Lake section
Set "Single sign-on" to use a Fixed Identity (a service principal or workspace identity with warehouse access)
Save and re-test
In newer Fabric tenants, this is labeled "Fixed identity" explicitly in semantic model settings.
The semantic model itself needs its own authorized identity to access the Delta tables in OneLake, user credentials are not delegated in Direct Lake mode.
Additional Checks
- Workspace role: Users need at least Viewer on the workspace, OR the model must be shared explicitly, you've done this, so that's fine.
- "Build" permission alone is not sufficient for Direct Lake data passthrough, the Fixed Identity issue overrides it.
- If you don't want to use Fixed Identity, switching to DirectQuery mode (not Direct Lake) will pass user credentials through, and your existing warehouse permissions would work natively.
I want users to use their own credentials, so the data source is already set to SSO. Changing it to DirectQuery mode didn't fix the issue.
Digging further, it seems like when it's a DirectLake connection, I'm able to set it to SSO with AzureDataLakeStorage as the data source. When the connection is DirectQuery, it's changing the data source to AnalysisServices, and mapping it to a Personal Cloud Connection. I can't change the connection to SSO.
Direct Query:
Direct Lake:
Original DirectLake that's working (has a second, composite model for the measures that's DirectQuery to this one):
Hi knoah
Thank you for performing all the validation steps and sharing the detailed findings.
Based on the troubleshooting completed so far, the core Warehouse access and SSO configuration appear to be working correctly:
- users can directly access/query the Fabric Warehouse,
- SSO authentication is functioning and the semantic model itself is visible to users.
However, the issue still persists specifically at the semantic model consumption layer, where:
- users are unable to enumerate tables/measures,
- report visuals fail with underlying data permission errors and the datasource behavior differs between the working and failing models (AzureDataLakeStorage vs AnalysisServices / Personal Cloud Connection).
Since the expected permission and configuration checks have already been validated from your end, this may require deeper backend investigation into the semantic model authentication/binding behavior.
At this stage, the best next step would be to open a Create a Fabric and Power BI Support Ticket - Power BI | Microsoft Learn so the product/support engineering team can further analyze the workspace, semantic model bindings, and authentication flow internally.
