Forum Discussion
Bug: Pipeline Copy activity for parametrized warehouse destination asks for connection string
Hello,
I've noticed while developing another pipeline what if you parametrize connection ID (e.g. via variable library) for warehouse destination (as well as providing workspace_id and warehouse_id parameters) - for some reason pipeline asks connection string as mandatory parameter (despite already having all required information, generic fabric connection_id, workspace_id and warehouse_id, these 3 should be sufficient enough)
I can understand scenarios for private workspaces (inbound/outbound traffic is controlled via slightly different endpoint) but this connection thing should be optional, not mandatory (which causes unnecessary overhead of storing and populating extra row in variable library).
Is there a plan to fix it or this problem already has some sort of workaround anyone can share?
Thank you.
What's actually happening
When you parametrize a Warehouse connection via dynamic content, the UI/schema for that connection type expects four things: Connection GUID, Workspace ID, Warehouse ID, and SQL connection string — even though the Connection GUID plus Workspace ID plus Warehouse ID should, in theory, be enough for Fabric to resolve the target. Several community threads on the Fabric forum confirm the same set of fields is required, and one person specifically flagged that the workspace-identity path (which would let you skip the connection string entirely) doesn't currently work either, only getting past it after correctly wiring up workspace identity and warehouse ID. So the pain point you're describing is a known limitation, not something you're missing.
Workaround that people are actually using
For Lakehouse destinations, there's a documented trick: if you open the pipeline in the JSON editor, the connection definition contains an
externalReferences block that duplicates the Lakehouse/Workspace GUIDs. Deleting that block (and its leading comma) collapses the UI down to just Connection + Workspace ID, dropping the redundant fields. It's plausible the same JSON-editing approach can trim the Warehouse connection string requirement too, since the underlying pipeline definition is just JSON — worth testing by exporting the pipeline JSON, editing the Warehouse activity's connection object by hand, and reimporting, rather than fighting the UI dropdowns.If that doesn't fully eliminate it for Warehouse, the more common workaround people report is just accepting the "extra row" in the Variable Library rather than fighting the requirement — i.e., you populate the connection string variable but reuse the same variable across every activity that hits that warehouse, so it's one extra row per environment, not one per activity. Not elegant, but it avoids the overhead compounding.
On a fix
I didn't find anything from Microsoft (docs, roadmap, or product team comments) indicating this specific mandatory-field behavior is being changed. Variable Library and the parametrized-connections feature are still in preview, so it's the kind of rough edge that could get smoothed out, but there's no confirmed timeline. If it's blocking you, filing feedback via the Fabric ideas portal or flagging it on the Fabric Community forum thread you're probably already reading is the most direct way to get visibility on it — Microsoft does act on those for preview features.
2 Replies
What's actually happening
When you parametrize a Warehouse connection via dynamic content, the UI/schema for that connection type expects four things: Connection GUID, Workspace ID, Warehouse ID, and SQL connection string — even though the Connection GUID plus Workspace ID plus Warehouse ID should, in theory, be enough for Fabric to resolve the target. Several community threads on the Fabric forum confirm the same set of fields is required, and one person specifically flagged that the workspace-identity path (which would let you skip the connection string entirely) doesn't currently work either, only getting past it after correctly wiring up workspace identity and warehouse ID. So the pain point you're describing is a known limitation, not something you're missing.
Workaround that people are actually using
For Lakehouse destinations, there's a documented trick: if you open the pipeline in the JSON editor, the connection definition contains an
externalReferences block that duplicates the Lakehouse/Workspace GUIDs. Deleting that block (and its leading comma) collapses the UI down to just Connection + Workspace ID, dropping the redundant fields. It's plausible the same JSON-editing approach can trim the Warehouse connection string requirement too, since the underlying pipeline definition is just JSON — worth testing by exporting the pipeline JSON, editing the Warehouse activity's connection object by hand, and reimporting, rather than fighting the UI dropdowns.If that doesn't fully eliminate it for Warehouse, the more common workaround people report is just accepting the "extra row" in the Variable Library rather than fighting the requirement — i.e., you populate the connection string variable but reuse the same variable across every activity that hits that warehouse, so it's one extra row per environment, not one per activity. Not elegant, but it avoids the overhead compounding.
On a fix
I didn't find anything from Microsoft (docs, roadmap, or product team comments) indicating this specific mandatory-field behavior is being changed. Variable Library and the parametrized-connections feature are still in preview, so it's the kind of rough edge that could get smoothed out, but there's no confirmed timeline. If it's blocking you, filing feedback via the Fabric ideas portal or flagging it on the Fabric Community forum thread you're probably already reading is the most direct way to get visibility on it — Microsoft does act on those for preview features.
Hi J_Fad ,
Hey, this is current expected behavior in Fabric pipelines, not really a bug. When you switch a Warehouse connection to dynamic content (variable library / parameters), the UI expects all four values, not just the connection GUID:
- Connection = Warehouse connection GUID
- Workspace ID = target workspace GUID
- Warehouse ID = Warehouse GUID (goes in the "database" slot)
- SQL Connection String = the Warehouse's SQL analytics endpoint (server FQDN)
Even though it feels redundant, the runtime uses the connection string to actually resolve the SQL endpoint — the GUIDs alone aren't enough today. Same behavior applies to Lookup / Script / Stored Procedure activities.
Workaround: Add a 4th variable in your Variable Library (e.g. wh_sql_endpoint) holding the SQL endpoint per environment, and bind it to the Connection String field. Then Dev/Test/Prod swap works cleanly.
If you'd like the connection string derived automatically from connectionId + warehouseId, please upvote / raise it on fabric Ideas.
References:
