Forum Discussion
Notebook using Workspace Identity FabricAdomdException: The connection is not open
I have a notebook in a pipeline, the notebook is set to use a connection that uses the current Workspace Identity. The notebook trys to query a semantic model in another workspace using fabric.evaluate_dax(...). It works if I run the notebook manually under my own identity but when I run the notebook through the pipeline so it will run as the current workspace identity I get the following error:
Caused by InvalidOperationException:
The connection is not open.
at Microsoft.AnalysisServices.AdomdClient.AdomdUtils.CheckConnectionOpened(AdomdConnection connection)
at Microsoft.AnalysisServices.AdomdClient.AdomdCommand.CheckCanExecute()
at Microsoft.AnalysisServices.AdomdClient.AdomdCommand.ExecuteReader(CommandBehavior behavior)
at Microsoft.AnalysisServices.AdomdClient.AdomdCommand.ExecuteReader()
at Microsoft.Fabric.SemanticLink.DAXToParquetWriter.Write(String dax, String fileName, Int32 batchSize, AdomdConnection adomdConnection, Int32 verbose, Nullable`1 maxNumRows, Nullable`1 activityId)
- Both myself and the workspace identity have contrabutor access to both workspaces.
- Neither of us have any direct item level permissions to the semantic model.
- I have tried the the default semantic-link v0.11.0 that comes with the default enviroment and also v0.14.0
- Service principals can call Fabric public APIs, is enabled
Any help would be much appreciated.
This is almost always a permissions + identity context issue, not a semantic-link bug. When you run manually, it works because your user identity has implicit access to the semantic model via workspace role inheritance, but when the pipeline runs, the workspace identity (spn) is used, and that identity does not get implicit dataset access unless explicitly granted. In Fabric, Contributor on workspace is not enough for semantic model query via XMLA/ADOMD, you must explicitly grant the workspace identity Build (or Read + Build) permission on the semantic model (or add it via dataset permissions, not just workspace role). Because of this, the connection silently fails to open & surfaces as
AdomdException: The connection is not open. Fix: go to the semantic model --> Manage permissions -> explicitly add the workspace identity (service principal) with Build access; alternatively test by granting Admin temporarily to confirm. Also ensure XMLA endpoint is enabled (Read/Write) and cross-workspace access is allowed. I believe this should resolve it immediately.
5 Replies
This is almost always a permissions + identity context issue, not a semantic-link bug. When you run manually, it works because your user identity has implicit access to the semantic model via workspace role inheritance, but when the pipeline runs, the workspace identity (spn) is used, and that identity does not get implicit dataset access unless explicitly granted. In Fabric, Contributor on workspace is not enough for semantic model query via XMLA/ADOMD, you must explicitly grant the workspace identity Build (or Read + Build) permission on the semantic model (or add it via dataset permissions, not just workspace role). Because of this, the connection silently fails to open & surfaces as
AdomdException: The connection is not open. Fix: go to the semantic model --> Manage permissions -> explicitly add the workspace identity (service principal) with Build access; alternatively test by granting Admin temporarily to confirm. Also ensure XMLA endpoint is enabled (Read/Write) and cross-workspace access is allowed. I believe this should resolve it immediately.This looks more like a permission or authentication context issue with the Workspace Identity than a semantic-link version problem. Even with Contributor access, the pipeline execution context can behave differently from manual runs, especially when accessing semantic models across workspaces.
Hi MO-HS,
Thank you for reaching out to Microsoft Fabric Community.
Thank you Vinodh247 and Jesse_ethon for the prompt response.
As we haven’t heard back from you, we wanted to kindly follow up to check if the solution provided by the user's for the issue worked? or let us know if you need any further assistance.
Thanks and regards,
Anjan Kumar Chippa
Hello Vinodh,
Thank you for the advice. After explicitly granting permissions it worked.
