Dataflow Gen2 CICD are not Linked

[hansei]

I have a dataflow Dataflow0 with table Table0 in workspace Dev.
In the same workspace I create dataflow Dataflow1 and Dataflow2 and Dataflow3 that all reference Table0 using the connector Dataflows (Power Platform)

• Dataflow1 is a Gen1 dataflow, then the table is linked

• Dataflow2 is a Gen2 dataflow, and the queries do not show the above warning, but the link shows up in workspace lineage. 
• Dataflow3 is a copy of Dataflow2 with CI/CD support. It does not display the link to Dataflow0 in lineage view at all.

When deploying from this workspace to another workspace (Test), the only items that can deploy are Gen2 with CI/CD (Dataflow3). However, it still points to the Dev workspace for it's content. I am a bit baffled here, as the only dataflows that retain the link (autobind) are the ones that cannot be used in deployment pipelines.

[Poojara_D12 · Accepted solution]

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.

[hansei]

---

@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.

[GilbertQ]

Hi @hansei 

As far as I'm aware, the reason that this is working the way as you expanded it because it data flow gen2 are the only one that you can use CI/CDwith. So this is why they're still pointing to the Dev workspace for the data flow gen 1. You will need to change the data flow Gen 1 to a data flow gen 2 in order for this to move through the different workspaces using deployment pipelines.

[hansei]

Creating Dataflow0 as Gen2 (CI/CD) is the same behavior. The entities do not show as linked in lineage view and deploying to another workspace will have the referencing dataflow still pointing to the original workspace.