Forum Discussion
Impactful Individualcan a task flow be deployed and versioned?
Hi db042190
In Fabric, the CI/CD model is primarily item-based. Supported artifacts such as Data Pipelines, Dataflows Gen2, Notebooks, Lakehouses, Warehouses, etc. can be versioned through Git and/or promoted using Deployment Pipelines, but they remain separate Fabric items rather than one SSIS-style package.
You can still design the solution across Dev → Test → Prod workspaces and promote the individual supported artifacts. However, the relationships/dependencies between those artifacts are not currently packaged into a single deployable ETL unit in the same way an SSIS package does.
Community ChampionHi db042190,
I think you are referring to the workspace Task Flow canvas, especially since you mentioned starting from the medallion template, rather than Power BI Translytical Task Flows/User Data Functions.
For the workspace Task Flow, there is an important distinction today: it is a workspace-level visualization of your solution rather than a normal Fabric item that participates in CI/CD.
The current Fabric Git integration supported-items list and deployment pipeline supported-items list do not currently include Task Flows. So there isn't a native Dev → Test → Prod deployment/versioning experience for the Task Flow canvas itself.
There is, however, a useful workaround. Fabric lets you export a Task Flow as JSON and import it into another workspace. The JSON preserves the task flow name, tasks and connectors, so you could store that exported file in Git and use normal Git history/PRs to version it.
One limitation is that the exported JSON does not include the item associations. After importing the Task Flow into Test or Prod, you would need to associate the corresponding Lakehouses, Warehouses, pipelines, notebooks, etc. again.
For the actual medallion implementation, I would therefore use Git/deployment pipelines for the supported Fabric items themselves, and treat the Task Flow as the architectural representation of each environment.
I haven't found a published Microsoft roadmap date for native Task Flow Git/deployment-pipeline support yet.
AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.
db042190thx shivekmaharaj, i think you are saying that the underlying pieces like gen2 , lakehouse landing for bronze etc be versioned separately, not as a collection of related sources, destinations, transforms? im probabluy missing something.
- ShivekMaharaj
Hi db042190,
Yes, that's basically what I meant, but with one nuance: the underlying Fabric items are versioned individually, but they do not have to be managed as unrelated pieces.
For example, your Dataflow Gen2, Bronze Lakehouse, notebooks/pipelines and downstream Warehouse can all live in the same workspace and Git branch and be promoted together through a deployment pipeline. Fabric's deployment process also handles many item dependencies through autobinding, and you can select related items when promoting a solution.
What Fabric does not currently give you is one SSIS-style package that represents the whole source → transform → destination solution as a single versioned artifact. Git versions the individual Fabric item definitions.
I would therefore think of it as individually versioned items that collectively make up the solution.
The workspace Task Flow is useful as the architectural map over those items, but it is not currently the CI/CD container itself. Microsoft documents that when you export a Task Flow, the JSON preserves the tasks and connectors but not the Fabric item associations.
So for your medallion example, I would keep the related items together in the same solution/workspace/repository, version the supported items through Git, and use the Task Flow to communicate how those pieces fit together.
AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.