Forum Discussion
can a task flow be deployed and versioned?
partly assisted by a course and previous post, we are getting our feet wet in this technology. amy and the other contributors at that post have made us feel a lot more comfortable.
we went to set up our first task flow using the medallion template as a starting place. our inclination was to set up 3 workspaces with the intention of the task flow being moved from one ws to the next on each change/qa "iteration".
is there a pipeline experience much like the fabric one we built for dashboards, that can facilitate moving task flows to the next stage (eg dev to test) so we don't have to retype our changes...and versions (maybe in a special file type) the task flow itself in a product like devops?
8 Replies
Hi db042190,
I assume you are talking about translytical task flows (AKA User Defined Functions)?
If so, then you can migrate the UDF object to another workspace with deployment pipelines, however the migration is not exactly smooth yet.
The UDF itself will be migrated, but you still need to manually edit the report to point it to the new UDF, migrating the report will leave it pointed at the old UDF.
thx amy, i'm referring to what ive traditionally called etl. i know its old technology but i could always version an ssis package which is often and end to end source, transform, landing collection of "things".
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.
Hi 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.
thx 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.
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.
