Forum Discussion
New “Invoke Pipeline (Fabric)” activity not executing, while Legacy version works
Hi all,
I’m running into an issue with the new Invoke Pipeline (Fabric) activity.
Context
I have an orchestration pipeline that calls another pipeline (fm_job_control).
The Legacy Invoke Pipeline activity works perfectly.
When I switch to the new Fabric Invoke Pipeline activity, it does not execute as expected.
Configuration Details
Type: Fabric
Connection: FabricDataPipelines (status: Online, verified in Connection Management)
Workspace: FM-Dev-Gold
Pipeline: fm_job_control
Parameter passed:
MainPipeLineName = "<pipeline name>"
Wait on completion: Enabled
Observed Behavior
Legacy activity executes successfully with the same pipeline and parameters.
New Fabric activity:
Does not trigger the downstream pipeline (or fails silently / does not behave as expected).
No obvious connection issues (connection is online and refresh works).
Configuration appears identical from a logical standpoint.
What I’ve Checked
Connection is valid and online.
Workspace and pipeline selection are correct.
Parameters match what works in the legacy version.
No obvious permission issues on workspace or pipeline.
Questions
Are there known limitations or behavioral differences between Legacy Invoke Pipeline and the new Fabric version?
Does the new activity require different parameter typing or schema definition?
Are there additional permission or identity requirements specific to Fabric pipelines?
Is there any known issue where the activity appears configured correctly but does not trigger execution?
Screenshot
Hello Mauro89,
In the legacy setup, invoking the pipeline did not require a connection, which is why it was working there. In the new setup, invoking the pipeline activity requires a connection, and this appears to have been the cause of the issue.
After switching to a Service Principal connection, the new pipeline activity is now working as expected.
Thank you for your time and support—it was very helpful.🙂
8 Replies
Hi aayushiharalal,
I have the new invoke activity in place and its working fine but without parameter.
May I ask you to share the error message of the invoke acitivity which fails?
Beside that, what I came across and might cause issues and what you can check:
- if you have PIM in place and the connection authentication is configured with a PIM identity it might fail depending on the pipeline schedule and PIM activation status
- the identity executing the pipeline has not sufficient rights for the pipeline connection
Hope this helps! Or we can dive deeper into the error message.
Best regards!
PS: If you find this post helpful consider leaving kudos or mark it as solution
Hello Mauro89 ,
I have created two pipelines in Microsoft Fabric:
A main pipeline, which invokes a child pipeline using the InvokeFabricPipeline operation
A child pipeline, which is a simple pipeline with no parameters or activities (for testing purposes)
However, when executing the main pipeline, I consistently receive the following error:
Error message
{"requestId":"3bd6a7a5-3fd3-420c-807a-f25ac091243e","errorCode":"ItemNotFound","message":"Could not found the requested item"}
Input
{
"waitOnCompletion": true,
"operationType": "InvokeFabricPipeline",
"pipelineId": "1b82c51a-66ca-49ce-b249-c8757c986af1",
"workspaceId": "31dae79c-d0be-478d-a752-22849953c41f",
"parameters": {}
}
Output{"requestId": "3bd6a7a5-3fd3-420c-807a-f25ac091243e","errorCode": "ItemNotFound","message": "Could not found the requested item","ADFHttpStatusCodeInResponse": "404","ResponseHeaders": {"Pragma": "no-cache","Transfer-Encoding": "chunked","x-ms-public-api-error-code": "ItemNotFound","Strict-Transport-Security": "max-age=31536000; includeSubDomains","X-Frame-Options": "deny","X-Content-Type-Options": "nosniff","RequestId": "3bd6a7a5-3fd3-420c-807a-f25ac091243e","Access-Control-Expose-Headers": "RequestId","request-redirected": "true","home-cluster-uri": "https://wabi-india-central-a-primary-redirect.analysis.windows.net/","Cache-Control": "no-store, must-revalidate, no-cache","Date": "Fri, 20 Mar 2026 11:11:36 GMT","Content-Type": "application/json; charset=utf-8"},"executionDuration": 6}
response header
{"Pragma":"no-cache","Transfer-Encoding":"chunked","x-ms-public-api-error-code":"ItemNotFound","Strict-Transport-Security":"max-age=31536000; includeSubDomains","X-Frame-Options":"deny","X-Content-Type-Options":"nosniff","RequestId":"3bd6a7a5-3fd3-420c-807a-f25ac091243e","Access-Control-Expose-Headers":"RequestId","request-redirected":"true","home-cluster-uri":"https://wabi-india-central-a-primary-redirect.analysis.windows.net/","Cache-Control":"no-store, must-revalidate, no-cache","Date":"Fri, 20 Mar 2026 11:11:36 GMT","Content-Type":"application/json; charset=utf-8"}
Manage ConnectionsClarifications:
Both pipelines are in the same workspace
I have Admin access to the workspace
The pipelineId and workspaceId were copied directly from the Fabric UI
The child pipeline is saved and visible
A valid connection is configured via Manage Connections (screenshot attached)
Request:
Could you please help clarify:
If there are any additional backend requirements (e.g., publishing state, hidden dependencies, or API limitations) for invoking a Fabric pipeline
Whether InvokeFabricPipeline has any known constraints related to workspace scoping or connection binding
If this error could indicate an issue with ID resolution on the service side, despite the item being present and accessible
Hi aayushiharalal,
the invoke pipeline acitivty is basically very simple. There are not specific limitations like you mentioned.
What else you can try.
- Take you the legacy invoke (not sure if you call in both acitivities the same pipelines to invoke).
- OR create two complete new pipelines and invoke the one from the other just to check if there is any general issue in your environment
Best regards!
Hello,
I wasn’t able to pinpoint the exact root cause, but moving to a Service Principal connection resolved the issue and the setup is now working as expected.For anyone facing a similar problem, this approach might be worth trying.
Thanks to Mauro89 for the support and time.
