Forum Discussion
Advocate IConnecting to a semantic Model issue
Hello,
We created a Snowflake mirrored database in Microsoft Fabric. User A then created a semantic model connected to this mirrored database (OneLake).
We have an older semantic model, and I migrated all the measures from it to the new semantic model using TMDL Apply.
However, when I tried to connect to User A's semantic model from Power BI Desktop to create reports and visuals, I received the following error:
Both User A and I are Workspace Administrators.
To troubleshoot, I created my own semantic model on the same mirrored database, migrated the same measures using TMDL Apply, and then connected to it from Power BI Desktop. In this case, the connection worked successfully without any issues.
My question is:
- Why am I unable to connect to the semantic model created by User A, even though we have the same workspace permissions?
- What could explain the difference in behavior between User A's semantic model and the one I created, given that both are in the same workspace, use the same mirrored database, and have the same measures migrated via TMDL?
Any insights or recommendations would be greatly appreciated.
Hi PBI_2K26,
The most useful thing in your post is the test you already ran, and I think it's getting skipped over. You built your own semantic model on the same mirrored database, in the same workspace, with the same measures moved across the same way, and it connected fine.
That rules out most of what's been suggested. A tenant setting, your workspace role, your access to OneLake, those are all properties of you, and they were identical in both attempts. Whatever this is, it's a property of User A's model rather than of your permissions.
Two things can differ between two Direct Lake models over the same source and give one person a permission error and not another.
First, the connection. By default a Direct Lake model uses Entra SSO and checks the identity of whoever is querying it. But a model can instead be bound to a cloud connection with a fixed identity, and that changes who the source thinks is asking. Open User A's model settings and compare the gateway and cloud connections section against yours.
Second, and this is the one people don't expect: the owner's access gets checked too, not just yours. The docs are explicit that "No matter who refreshes a Direct Lake model, Direct Lake checks the owner's permission to ensure the model is allowed to access the data." So if User A has lost SELECT on the mirrored database since they built it, their model breaks for everyone while yours carries on working fine.
Can User A still open their own model and see data in it? If they can and you can't, it's the connection. If they can't either, it's their access to the source, and that also tells you it was never about you.
5 Replies
v-aatheequeCommunity Support
Hi PBI_2K26
A few things would be worth checking to understand why User A’s semantic model behaves differently even though you both have the same workspace permissions:
- Check whether the OneLake external access tenant setting is enabled in Fabric Admin Portal → Tenant settings → “Users can access data stored in OneLake with apps external to Fabric.” If this was disabled when User A created the semantic model, it may be worth recreating the model after confirming the setting is enabled.
- Verify the semantic model ownership and compare it with the working model you created. Although you are both Workspace Admins, the two models may have different underlying connection or ownership metadata.
Confirm that the workspace is assigned to an active Fabric capacity and that there are no capacity-related issues such as throttling or suspension. - Compare the data source/connection settings of both semantic models, especially the OneLake and mirrored database references. Since both models use the same Snowflake mirrored database, any difference in how the models reference or bind to it could explain the different behavior.
- If everything looks the same, try recreating User A’s semantic model from the same mirrored database after confirming the tenant and capacity settings. Then apply the same TMDL measures and test the Power BI Desktop connection again.
- If the newly recreated model works, that would strongly suggest that something specific to the original semantic model's metadata or connection configuration was causing the issue.
Useful Links : https://learn.microsoft.com/en-in/power-bi/connect-data/service-datasets-build-permissions
Hope this helps !!
Thank You.
- v-aatheeque
Hi PBI_2K26
Have you had a chance to look through the responses shared earlier? If anything is still unclear, we’ll be happy to provide additional support. - v-aatheeque
Hi PBI_2K26
Following up to confirm if the earlier responses addressed your query. If not, please share your questions and we’ll assist further.
- ShivekMaharaj
Community Champion
Hi PBI_2K26,
Since both of you are Workspace Admins, I would not start with Build permission. Microsoft documents that Contributor, Member and Admin workspace roles already provide Build permission on semantic models in that workspace.
What I would compare is the source binding and permissions of the two semantic models, because migrating the measures through TMDL only reproduces the model metadata you moved. It does not necessarily mean both semantic models have the same underlying Direct Lake configuration.
A few things I would check on User A’s model:
- Open the semantic model settings and confirm which mirrored database / SQL analytics endpoint it is actually bound to.
- Compare that binding with the model you created.
- Check whether User A’s model is using a different Direct Lake security mode or fixed identity.
- Confirm you have the required access to the underlying Snowflake mirrored database, not only Admin access to the workspace.
Microsoft documents that Direct Lake access involves both the semantic model permissions and the permissions to the underlying Fabric data source. The mirrored database itself also has separate permissions such as Read all OneLake data and Read all SQL analytics endpoint data.
I would also test something simple in the Service: open User A’s semantic model and use Explore this data or another model-level query path. If that model itself cannot be queried by you, while your recreated model can, then the issue is below Power BI Desktop and is almost certainly specific to User A’s semantic model configuration.
The fact that your recreated model works against the same mirrored database is actually useful evidence. It makes the shared workspace, capacity and mirrored database less likely to be the general problem.
If the source bindings and permissions look identical, then I would compare the semantic model definitions beyond the measures, especially the model-level connection/source properties, rather than recreating the measures again.
AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.
PauReisResolver III
Hi PBI_2K26,
The most useful thing in your post is the test you already ran, and I think it's getting skipped over. You built your own semantic model on the same mirrored database, in the same workspace, with the same measures moved across the same way, and it connected fine.
That rules out most of what's been suggested. A tenant setting, your workspace role, your access to OneLake, those are all properties of you, and they were identical in both attempts. Whatever this is, it's a property of User A's model rather than of your permissions.
Two things can differ between two Direct Lake models over the same source and give one person a permission error and not another.
First, the connection. By default a Direct Lake model uses Entra SSO and checks the identity of whoever is querying it. But a model can instead be bound to a cloud connection with a fixed identity, and that changes who the source thinks is asking. Open User A's model settings and compare the gateway and cloud connections section against yours.
Second, and this is the one people don't expect: the owner's access gets checked too, not just yours. The docs are explicit that "No matter who refreshes a Direct Lake model, Direct Lake checks the owner's permission to ensure the model is allowed to access the data." So if User A has lost SELECT on the mirrored database since they built it, their model breaks for everyone while yours carries on working fine.
Can User A still open their own model and see data in it? If they can and you can't, it's the connection. If they can't either, it's their access to the source, and that also tells you it was never about you.
