Variable Types Missing After Deployment to Another Workspace (Fabric Pipeline → ADF Pipeline + Varia

[mvdhoorn]

Hi everyone,

I'm running into an issue with Microsoft Fabric deployment pipelines and I'm hoping someone can confirm whether this is a known limitation or a bug.

🔧 Scenario

• I have a Microsoft Fabric Data Pipeline.
• The pipeline invokes an Azure Data Factory (ADF) pipeline using the Invoke Pipeline activity.
• The ADF pipeline expects several parameters (Strings) which I populate from a Fabric Variable Library.
• Everything works perfectly in the Development workspace.

🚨 Problem

After deploying the solution to another workspace (e.g., Test or Production), all the parameter names still appear in the pipeline, but the parameter types are empty.

Essentially, the target workspace shows:

• Parameter names ✔️
• Parameter values ✔️
• Parameter types ❌ (missing / blank)

This causes the invocation to fail because the Fabric pipeline can no longer determine the expected parameter type.

(See attached image — left side Dev, right side Test: all parameter types missing.)

🔍 What I already checked

• Variables and value sets are properly defined in the Variable Library.
• Variable libraries are known to require correct variable types, and type mismatches normally surface during validation. (Microsoft Learn confirms type‑related issues can block saving or referencing variables.) [learn.microsoft.com]
• I also reviewed Invoke Pipeline behavior: Fabric currently has known limitations with dynamic pipeline references and cross‑workspace design‑time metadata. (Confirmed by Fabric Community responses on Invoke Pipeline limitations.) [community....rosoft.com]

However, I haven’t found any community topic describing variable types disappearing specifically after deployment, and none of the deployment pipeline docs mention this scenario.

🧪 Additional Notes

• The problem only appears after deployment to another workspace.
• The variable names and values survive correctly — only the type metadata is lost.
• Re‑adding the parameters manually fixes the issue, but this defeats CI/CD automation.

❓ Questions for the Community

1. Is this a known issue or limitation in Fabric deployment pipelines?
2. Should Variable Library–based parameter types be preserved across workspace deployments?
3. Has anyone else experienced parameter-type loss after promoting Fabric pipelines?
4. Is there a recommended workaround besides re‑entering types manually?

Thanks in advance for any help—happy to share more details or export metadata if useful!

[mvdhoorn]

Hi @v-veshwara-msft , 

Thank you for the quick reply.

I can confirm that the Variable Library exists in the target workspace and that the variables and their types match the source before deploying the pipeline (see attached image). 

The issue continues, so I will raise a support ticket.

Thanks!

[v-veshwara-msft]

Thank you for confirming and for sharing the screenshot.

Since the Variable Library and variable types are aligned in the target workspace and the issue still persists, raising a support ticket is the right next step. This will allow the product team to review the deployment behavior in detail.

Once you have the ticket created, please feel free to share any updates here which would be helpful for others facing a similar issue.

[v-veshwara-msft]

Hi @mvdhoorn ,

Just wanted to check if you have any update from the support ticket regarding this issue. If there are any findings or recommendations shared, please feel free to update the thread.

Thank you.

[mvdhoorn]

Hi @v-veshwara-msft,

Was a few days of, and not able yet to raise a support ticket. If there are any findings or recommendations, I will update the thread.

[v-veshwara-msft]

Hi @mvdhoorn ,

Thank you for the update.

No worries. Please share any findings once you’re able to raise the support ticket.

[v-veshwara-msft]

Hi @mvdhoorn ,

Just checking in to see if there are any updates from the Microsoft support ticket.

If the issue has been resolved, it would be helpful if you could share the outcome or any key findings here, as it may benefit others in the community facing a similar scenario.

Thank you.

[mvdhoorn]

Hi @v-veshwara-msft ,

After consulting with me, Microsoft support was unable to reproduce the problem even though they put a lot of effort into it. I now am also unable to reproduce it myself.

We now assume (and hope) it was a one-time issue. Should it occur again, they will investigate the cause again.

For now, this issue is closed.

Thank you for your time!

[v-veshwara-msft]

Hi @mvdhoorn ,

Thank you for the update and for sharing the outcome.

Good to hear that the issue is no longer reproducible. Hopefully it was a one time occurrence.

Please feel free to reach out for further assistance.
Thank you.

[v-veshwara-msft]

Hi @mvdhoorn ,

Thank you for raising these questions in Microsoft Fabric Community.

Based on the current documentation and expected behavior of Fabric deployment pipelines, this is not described as a known limitation.

Parameter types are part of the pipeline definition and should be preserved when promoting pipelines across workspaces.

Variable Library based parameter types are also expected to remain intact after deployment. The promotion process should not remove or reset the type metadata of parameters used in an Invoke Pipeline activity.

There is no documented behavior indicating that parameter types are expected to be lost during promotion, and this is not a standard or intended outcome.

As a precaution, please ensure that the Variable Library exists in the target workspace and that the variables and their types match the source before deploying the pipeline.

If the issue continues after confirming this, please raise a Microsoft Support ticket for further investigation.

Please reach out for further assistance.
Thank you.