Approach for automating Dataflow Gen2 connection binding across Dev/Prod?

Hi lavginqo2​,

I think there is one newer API capability worth adding here, because the current situation is slightly more nuanced than "there is no REST way to rebind it."

You are correct that Dataflow Gen2 still does not have a native Dev → Prod connection deployment rule. Microsoft's current Dataflow Gen2 CI/CD architecture guidance explicitly says that data-source connections are statically bound and cannot be switched using workspace variables or Dataflow parameters. Deployment rules don't currently alter Dataflow connections either.

However, Microsoft now exposes the Dataflow's public definition through the Fabric REST API.

The documented Dataflow definition format includes a connections collection inside queryMetadata.json, and each entry contains the connection path, kind, and connectionId.

That opens up a post-deployment automation pattern:

Deploy Dev → Prod → get the Prod Dataflow definition → replace the Dev connection ID with the corresponding Prod connection ID → update the definition → publish the Dataflow

Microsoft provides both Get Dataflow Definition and Update Dataflow Definition endpoints for this.

I would therefore separate environment configuration from the Dataflow deployment itself.

For example:

1. Create the required shareable connections in Prod once, ideally with stable naming.
2. Maintain a small environment mapping such as DevConnectionId → ProdConnectionId.
3. Deploy the Dataflow through your normal Fabric CI/CD process.
4. Call getDefinition on the deployed Dataflow.
5. Decode queryMetadata.json and replace the relevant connections[].connectionId values.
6. Send the modified definition through updateDefinition.
7. Publish the Dataflow and run a validation refresh.

Fabric also has public connection APIs for creating, listing, testing and managing the actual connection objects, so provisioning the Prod connections can be automated separately.

One important distinction is that the Update Connection API isn't itself a Dataflow-rebinding operation. It updates an existing connection object. The Dataflow-to-connection reference is represented in the Dataflow definition, which is why I would change the connectionId there instead.

For ~47 tables, this is the route I would prototype before manually reconnecting every query or splitting the Dataflow purely to make the manual work manageable. If those queries share a small number of underlying source connections, you are effectively translating a small connection map rather than maintaining 47 independent bindings by hand.

One caveat: Microsoft's API documentation is currently a little inconsistent around unattended identities. The specific Update Dataflow Definition API lists service principals and managed identities as supported, while the broader Dataflow Gen2 public-API documentation still lists service-principal authentication as a limitation. I would therefore validate the full getDefinition → updateDefinition → publish sequence with your intended CI/CD identity before making it the production deployment path.

So I agree that the lack of a first-class connection deployment rule is still a gap, but with the newer public Dataflow definition APIs I don't think manual per-query rebinding necessarily has to be the end state anymore.

AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.