Dataflow lineage not correct when using referenced Power Queries

Hi arjobsen 

Why this happens

Power BI Service's lineage detection works by statically scanning the M code in your queries for specific patterns that match what the Get Data UI generates. When the full navigation chain (PowerPlatform.Dataflows → workspace → dataflow → entity) exists in a single query, the service recognises it and draws the lineage correctly.

The moment you split that navigation across multiple queries, the static parser loses the trail. It can't follow references across queries to piece together the full dependency chain — so it just gives up and shows no connection.

This is a parser limitation, not a bug they're likely to fix quickly, which is why it ended up in the docs as a caveat.

The honest answer on workarounds

There's no clean fix that gives you both correct lineage and the refactored shared-connection pattern. But here are your realistic options:

Option 1 — Live with duplicated connection steps (keep lineage correct)

Keep the full navigation chain in each query as the docs expect. To make environment switching easier, use a parameter for the workspace ID and dataflow ID so you only change values in one place rather than rewriting queries.

// Parameter: WorkspaceId = "1803f02e-..."

// Parameter: DataflowId  = "4902516d-..."

let

    Source = PowerPlatform.Dataflows(null),

    workspaces = Source{[Id="Workspaces"]}[Data],

    dataflows = workspaces{[workspaceId=WorkspaceId]}[Data],

    dataflow = dataflows{[dataflowId=DataflowId]}[Data],

    _Query1 = dataflow{[entity="Query1", version=""]}[Data]

in

    _Query1

Switching environments = just updating the parameter values. Lineage stays intact.

Option 2 — Keep your refactored pattern, accept broken lineage

If the shared-connection approach is genuinely important for your dev/prod switching workflow, you can keep it and just accept that lineage won't display correctly in the Service. This is a cosmetic/governance loss, not a functional one — the data still flows correctly.

To compensate, you could document the lineage manually using the Purview integration or just a simple diagram shared with your team.

Option 3 — Move environment switching to deployment pipelines

Rather than handling dev/prod switching inside the M code, use Power BI Deployment Pipelines with parameter rules. You define one set of queries (with full navigation chains, so lineage works), and the pipeline swaps out the workspace/dataflow IDs automatically when promoting between dev and prod stages.

This is probably the most scalable approach if your workspace is already complex.

Did I answer your question? Mark my post as a solution! Appreciate your Kudos !!