Dataflow lineage not correct when using referenced Power Queries

[arjobsen]

I'm experiencing a problem with the lineage view in Power BI Service. By means of sample I've created 2 simple dataflows (with just a `#table(...)` inside) and 1 report which takes those 2 dataflows as a data source. Our real workspace is more complex though.

In the report these are the Power Queries:

let
    Source = PowerPlatform.Dataflows(null),
    workspaces = Source{[Id="Workspaces"]}[Data],
    dataflows = workspaces{[workspaceId="1803f02e..."]}[Data],
    dataflow = dataflows{[dataflowId="4902516d..."]}[Data],
    _Query1 = dataflow{[entity="Query1", version=""]}[Data]
in
    _Query1

And the same query but for Query2. In Power BI Service now the lineage shows correct: 

But if I refactor out the steps which navigate to the dataflows into a separate query like this:

// Query: dataflows
let
    Source = PowerPlatform.Dataflows(null),
    workspaces = Source{[Id="Workspaces"]}[Data],
    _dataflows = workspaces{[workspaceId="1803f02e-fdb7-459c-9bf4-60766c70c183"]}[Data]
in
    _dataflows


// Query: Query1 now references the dataflows query
let
    dataflow = dataflows{[dataflowId="4902516d-c793-4d7d-a4a2-a4256a7963cf"]}[Data],
    _Query1 = dataflow{[entity="Query1", version=""]}[Data]
in
    _Query1

Now the lineage shows as if there is no dependency:

I read from the docs that "Correct display of semantic model<->dataflow lineage is guaranteed only if the Get Data UI is used". Are there any known workarounds for this?

I'm trying to accomplish having 1 query which connects to the dataflows and all other queries references that main one. This makes it easy to switch between production (dataflows) and development (connection to the DWH).

[Anonymous]

Hi @arjobsen,

Thank you for reaching out to the Microsoft Fabric Forum Community, and special thanks to @johnbasha33  for prompt and helpful responses.

Just following up to see if the Response provided by community members were helpful in addressing the issue. if the issue still persists Feel free to reach out if you need any further clarification or assistance.

Best regards,
Prasanna Kumar

[arjobsen]

wow this is a useless waste of AI

[johnbasha33 · Accepted solution]

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 !!

[arjobsen]

Thanks for that clear information. Too bad that such a powerful product as the Power BI suite doesn't do a simple task as evualate referenced queries.

Option 1 and 3 are unfortunately not working for us since our development source is directly reading from a Redshift datawarehouse. So option 2 it is