Forum Discussion
Enabling Org App Access - with data residing in seperate workspace/semantic model
Probably something many have run into before.
Data is stored in Semantic Model A, in Workspace A. This is used as the central location.
I want to provide app access to Team B - they have their own Workspace Containing the App.
Now: this works when I (admin) look at it. But what I'm not clear on how to do is how to enable access to Team B via a Security Group. What's the correct method in this instance.
I've tried:
- Service principles - runs into defaulting to the standard SSO permissions as users can't inherit them.
- Security Groups - when applied to the Semantic model, seems to break admin access/
So what's the "right" approach. The Data and Semantic Model in one workspace, Dashboard and App in another. Everything Works, but the Permissions prevent the users in the app workspace from viewing the data as it currently stands
4 Replies
- AvdBerg
Resolver I
Hi jackbettles
App permissions and semantic model permissions are two separate grants, and the app one cannot reach across workspaces. You need the same security group in two places
1, Workspace A, item level (not workspace level)
Semantic Model A → Manage permissions → Direct access → Add user → add the SG → tick Read.Read alone is enough, add build only if they need Analyze in Excel, XMLA etc. You dont need to give the viewer role to the workspace, it works but all items in the workspace are exposed that way.
2, Workspace B, Org app
App → Audience → Manage audience access → add the same SG.3. If RLS exists, add the SG to the RLS role (Semantic model -> Security)
Hopefully this helps you.
Did I answer your question, please mark the post as a solution or consider a like.
xactly what I have in place - Read access is enabled, but they still get the standard no permission warning when the data actually attempts to render.
No RLS, So don't need to worry about this fortunatly- AvdBerg
What is the storage mode of the semantic model?
I have used Direct lake in the past, there we needed to bind the model to a cloud connection with a fixed identity (Service principal), That SP has read permissions on the source.
jubinsoniSkilled Sharer
Hi jackbettles,
Building on the storage mode question above: since Read on the model is already in place, the "no permission" at render time almost always means the users are being checked against the source behind the model, not the model itself. Which permission they need depends on how the model reaches its data:
Model storage mode What Team B also needs ------------------------------------- ------------------------------------------- Import nothing more (Read on the model is enough) DirectQuery with SSO (per-user) access to the source itself (SQL / lakehouse) Direct Lake, default (user identity) Read + ReadData on the lakehouse / SQL endpoint in Workspace A (or OneLake security roles) Direct Lake / DQ with fixed identity nothing more: the connection identity readsSo for Direct Lake you have two clean options: grant the security group ReadData on the lakehouse (Lakehouse > Manage permissions > the SG > "Read all data using SQL endpoint" / OneLake data access role), or switch the model's connection to a fixed identity as mentioned above, so users only ever need Read on the model and the app.
To confirm quickly which layer is failing, sign in as a Team B test user, open the visual error and click See details: an error mentioning the lakehouse/SQL endpoint or "user does not have permission to access data source" points to the source layer, while a model-level error points to model permissions.
So my overall approach would be:
Check model storage mode (Import / DQ / Direct Lake) -> Import: Read on model + app audience is enough -> Direct Lake/DQ with SSO: grant SG ReadData on the source in Workspace A or switch to fixed identity connection -> Verify with a Team B test user via the error detailsAI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.
