Forum Discussion
Dataflow Gen2 CICD are not Linked
- 1 year ago
Hi hansei
Your scenario illustrates the current limitations and inconsistencies in Power BI’s dataflow behavior—especially around Gen1 vs. Gen2, linked tables, and deployment pipelines (CI/CD). Here's what’s happening:
-
Dataflow0 is your source dataflow in the Dev workspace and contains Table0.
-
Dataflow1 (Gen1) references Table0 using the Power Platform Dataflows connector. Because it’s Gen1, the table appears as linked, and Power BI enforces restrictions: you cannot modify the query, and changes won’t be saved (as shown in your warning screenshot).
-
Dataflow2 (Gen2) also references Table0. It does not display the same warning in Power Query, which is expected because Gen2 allows more flexibility and does not treat Power Platform–linked tables as immutable in the same way. However, it still retains the link in the lineage view, indicating dependency on Dataflow0.
-
Dataflow3 (Gen2 with CI/CD) is a copy of Dataflow2 prepared for deployment pipelines. It surprisingly loses the lineage connection to Dataflow0 entirely in the lineage view—this is likely because the CI/CD-compatible export-import process treats the reference as static code and breaks the autobind capability that tracks source lineage.
-
During deployment, only Gen2 dataflows with CI/CD support (like Dataflow3) can be moved to other workspaces (e.g., Test). However, because autobind is lost, Dataflow3 still points back to Table0 in the Dev workspace and cannot automatically rebind to a corresponding Dataflow0 in the Test workspace.
This behavior is by design but creates confusion. Gen1 supports autobind and preserves linkage, but can't be used with deployment pipelines. Gen2 with CI/CD supports deployment, but autobind and lineage tracking are broken or disabled, and the dataflow continues referencing the original source unless manually updated. Microsoft hasn't yet fully aligned these features across Gen2, making cross-workspace deployment of interdependent dataflows (with preserved bindings) a manual and error-prone process. To mitigate this, you may need to parameterize workspace or dataflow references in Gen2 and adjust them post-deployment using the REST API or Fabric UI to avoid hardcoded Dev dependencies.
-
Hi hansei
Your scenario illustrates the current limitations and inconsistencies in Power BI’s dataflow behavior—especially around Gen1 vs. Gen2, linked tables, and deployment pipelines (CI/CD). Here's what’s happening:
-
Dataflow0 is your source dataflow in the Dev workspace and contains Table0.
-
Dataflow1 (Gen1) references Table0 using the Power Platform Dataflows connector. Because it’s Gen1, the table appears as linked, and Power BI enforces restrictions: you cannot modify the query, and changes won’t be saved (as shown in your warning screenshot).
-
Dataflow2 (Gen2) also references Table0. It does not display the same warning in Power Query, which is expected because Gen2 allows more flexibility and does not treat Power Platform–linked tables as immutable in the same way. However, it still retains the link in the lineage view, indicating dependency on Dataflow0.
-
Dataflow3 (Gen2 with CI/CD) is a copy of Dataflow2 prepared for deployment pipelines. It surprisingly loses the lineage connection to Dataflow0 entirely in the lineage view—this is likely because the CI/CD-compatible export-import process treats the reference as static code and breaks the autobind capability that tracks source lineage.
-
During deployment, only Gen2 dataflows with CI/CD support (like Dataflow3) can be moved to other workspaces (e.g., Test). However, because autobind is lost, Dataflow3 still points back to Table0 in the Dev workspace and cannot automatically rebind to a corresponding Dataflow0 in the Test workspace.
This behavior is by design but creates confusion. Gen1 supports autobind and preserves linkage, but can't be used with deployment pipelines. Gen2 with CI/CD supports deployment, but autobind and lineage tracking are broken or disabled, and the dataflow continues referencing the original source unless manually updated. Microsoft hasn't yet fully aligned these features across Gen2, making cross-workspace deployment of interdependent dataflows (with preserved bindings) a manual and error-prone process. To mitigate this, you may need to parameterize workspace or dataflow references in Gen2 and adjust them post-deployment using the REST API or Fabric UI to avoid hardcoded Dev dependencies.
Poojara_D12 wrote:This behavior is by design but creates confusion. Gen1 supports autobind and preserves linkage, but can't be used with deployment pipelines.
That first sentence confirms my suspicion, but is disappointing. Thank you.
However, the 2nd proves to be incorrect. Gen1 ARE supported in deployment pipelines. They simply were not working for me previously.