Forum Discussion
Fabric question deployment pipelines dependencies
Current setup: 1 main workspace "Production"
New setup: 3 workspace "Dev" + "Test" + "Production"
Right now we want to do an initial deployment from current production to Dev using deployment pipeline within Fabric.
We have created a new warehouse and lakehouse in Dev that are called "Bronze_DEV", "Silver_DEV" and "Gold_DEV"
The content of these is a copy of our lakehouses and warehouse from Production "Bronze", "Silver" and "Gold"
Now when transferring data pipelines having reference to for example "Gold" the deployment fails because of missing dependencies. We dont have this issue with Semantic Model or notebooks. Only pipelines give this error. These data pipelines currently use connections to "Gold".
Is there an easy workaround im missing to transfer these items easily to our DEV workspace?
This is the error when transferring a data pipeline: Missing Dependencies: [ItemType: 'Warehouse', ObjectId: 'xxxx' WorkspaceObjectId: 'xxxx'] Which refers to "Gold" warehouse form production.
These pipelines contain copy data activities.
Hello Perez0s0,
I think the important point here is that your Data Pipeline still has an item dependency on the Production Gold Warehouse.
The error is explicitly showing the Production Warehouse ObjectId as a missing dependency. Fabric deployment pipelines validate item dependencies during deployment, and an item cannot be deployed when its required dependency is not available or correctly paired in the target stage.
Since you are effectively reversing the lifecycle from an existing Production workspace into a new Dev workspace, I would avoid treating this as a normal Prod to Dev deployment.
My suggested approach for the initial migration would be:
- Keep the same logical item names across stages: Bronze, Silver and Gold. The workspace already represents the environment, so Bronze_DEV or Gold_DEV is normally unnecessary.
- Make sure the Warehouse and Lakehouse dependencies are present and paired between the deployment pipeline stages before deploying the Data Pipelines. Fabric tracks source and target stage item pairing, including sourceItemId and targetItemId.
- Deploy the dependent Lakehouse/Warehouse items first, or deploy the pipeline together with its required dependencies. Fabric documents that deployment fails when a required dependent item doesn't exist in the target stage.
- After the initial pairing is established, deploy the Data Pipelines and inspect the Copy activity source and destination connections. I would explicitly verify that they resolve to the Dev Warehouse/Lakehouse and not the original Production connection.
One important distinction: deployment rules aren't a generic solution for rebinding every Data Pipeline Copy activity dependency. The currently documented deployment-rule types are data source rules, parameter rules, and default lakehouse rules for supported item types.
This may also explain why your notebooks behave differently. Notebook deployment supports auto-binding of the default Lakehouse when the dependent items are in the same workspace, so notebooks can be rebound to corresponding target-stage items.
For a clean Dev, Test and Prod design, I would therefore use identical logical Fabric item names in each workspace and let the workspace/stage identify the environment:
Bronze
Silver
Gold
rather than:Bronze_DEV
Silver_DEV
Gold_DEVHowever, I would first establish the item pairing/dependencies and then deploy the pipelines. Simply renaming Gold_DEV to Gold may help Fabric identify the corresponding item during initial stage assignment, but I would not assume the rename alone fixes an already persisted Production ObjectId reference inside a Copy activity. The Copy activity connection should still be validated after deployment.
Microsoft references:Understand the Fabric deployment process
Deploy content using deployment pipelines
Create deployment rules for Fabric ALM
Notebook source control and deployment
Best regards,
Omkar Shinde
Microsoft Fabric Enthusiast | Power BI Consultant
💡 If you found this response helpful, please consider giving it a Kudos.
✅ If this resolves your question, please mark it as the Accepted Solution to help others in the community.
2 Replies
- Shai_Karmani
Super User
In Fabric deployment pipelines, items are paired between stages by name. Because your Dev warehouse and lakehouses are called Bronze_DEV, Silver_DEV and Gold_DEV while Production has Bronze, Silver, Gold, the pipeline cannot auto pair them, and that is what the Missing Dependencies error is telling you.
The cleanest fix is to rename the Dev items to match the Production names exactly (Bronze, Silver, Gold, without any suffix). The deployment pipeline already knows which stage each item belongs to based on the workspace, so you do not need the _DEV suffix in the item name. Once the names match, the pipeline pairs the items and rewrites the data pipeline reference on deployment.
Semantic models and notebooks did not fail because they resolve their references differently, but data pipelines depend on this name based pairing to find their targets.
If it solved your issue, please mark it as the accepted solution and give it a kudos.
Best regards,
Shai Karmani - Omkar_1712
Solution Sage
Hello Perez0s0,
I think the important point here is that your Data Pipeline still has an item dependency on the Production Gold Warehouse.
The error is explicitly showing the Production Warehouse ObjectId as a missing dependency. Fabric deployment pipelines validate item dependencies during deployment, and an item cannot be deployed when its required dependency is not available or correctly paired in the target stage.
Since you are effectively reversing the lifecycle from an existing Production workspace into a new Dev workspace, I would avoid treating this as a normal Prod to Dev deployment.
My suggested approach for the initial migration would be:
- Keep the same logical item names across stages: Bronze, Silver and Gold. The workspace already represents the environment, so Bronze_DEV or Gold_DEV is normally unnecessary.
- Make sure the Warehouse and Lakehouse dependencies are present and paired between the deployment pipeline stages before deploying the Data Pipelines. Fabric tracks source and target stage item pairing, including sourceItemId and targetItemId.
- Deploy the dependent Lakehouse/Warehouse items first, or deploy the pipeline together with its required dependencies. Fabric documents that deployment fails when a required dependent item doesn't exist in the target stage.
- After the initial pairing is established, deploy the Data Pipelines and inspect the Copy activity source and destination connections. I would explicitly verify that they resolve to the Dev Warehouse/Lakehouse and not the original Production connection.
One important distinction: deployment rules aren't a generic solution for rebinding every Data Pipeline Copy activity dependency. The currently documented deployment-rule types are data source rules, parameter rules, and default lakehouse rules for supported item types.
This may also explain why your notebooks behave differently. Notebook deployment supports auto-binding of the default Lakehouse when the dependent items are in the same workspace, so notebooks can be rebound to corresponding target-stage items.
For a clean Dev, Test and Prod design, I would therefore use identical logical Fabric item names in each workspace and let the workspace/stage identify the environment:
Bronze
Silver
Gold
rather than:Bronze_DEV
Silver_DEV
Gold_DEVHowever, I would first establish the item pairing/dependencies and then deploy the pipelines. Simply renaming Gold_DEV to Gold may help Fabric identify the corresponding item during initial stage assignment, but I would not assume the rename alone fixes an already persisted Production ObjectId reference inside a Copy activity. The Copy activity connection should still be validated after deployment.
Microsoft references:Understand the Fabric deployment process
Deploy content using deployment pipelines
Create deployment rules for Fabric ALM
Notebook source control and deployment
Best regards,
Omkar Shinde
Microsoft Fabric Enthusiast | Power BI Consultant
💡 If you found this response helpful, please consider giving it a Kudos.
✅ If this resolves your question, please mark it as the Accepted Solution to help others in the community.
