Lineage coverage and limitations

What Measure Killer's data lineage traces at each stage, from the data source through dataflows and semantic models to reports and visuals, and what it does not cover.

Last updated · November 5, 2026

This page lists what the data lineage in Measure Killer covers at each stage, from the data source down to the visual, and where it stops. Where something is not covered, the section says what to use instead.

At a glance

Stage	Traced at column level	Not covered
Data sources	SQL Server, Azure SQL Database, PostgreSQL, Snowflake, Databricks, Fabric Lakehouses, Warehouses and SQL Databases, Excel files	Other sources (item level only), Analysis Services as a source, lineage inside the warehouse
Power Query code	Every step and native SQL query, read without running it	Pivoted columns, computed source names, tables picked by position and the other cases listed below
Dataflows	Gen1, Gen2 and Gen2 CI/CD, their Power Query steps and native SQL queries	Dataflows that were not selected and analyzed
Lakehouses, warehouses and notebooks	Their columns, down to every model, report and visual that uses them	Dependencies between them, which are item level only
Semantic models	Power Query, native SQL and every use inside the model, plus models built on other models	SSAS and AAS models in Tenant Analysis
Reports and visuals	Power BI reports down to the single visual, paginated reports, Excel files	Power Query inside paginated reports

Data sources

Column-level lineage works for these sources:

SQL Server and Azure SQL Database
PostgreSQL
Snowflake
Databricks
Fabric Lakehouses, Warehouses and Fabric SQL Databases
Excel files, also on SharePoint

Measure Killer needs no database credentials for any of them. Everything comes from metadata that already exists in your Power BI and Fabric tenant. For Fabric items, it reads the list of tables and columns from the SQL analytics endpoint. Metadata only, never your rows.

Other sources still appear in the item lineage, with every dataflow, model and report that reads from them, just not at column level. Column-level lineage for KQL / Kusto, Google BigQuery, Amazon Redshift, Oracle and SAP HANA is next on the roadmap. Until then, the M Expressions search finds every model and dataflow whose Power Query code names a table or view. The schema change how-to walks through it.

Analysis Services servers (SQL Server Analysis Services and Azure Analysis Services) are not a source in the lineage. For those models, the Analysis Services mode shows which columns, measures and tables downstream reports use.

Inside the warehouse. Measure Killer traces each Power BI field back to the source table, view and column it reads. It does not map lineage inside the warehouse itself, such as loads from one table into another, views built on other views, or stored procedures. That is the job of your data catalog. With MK Automation, the Power BI side of the lineage goes into Databricks Unity Catalog, Snowflake or any tool that reads OpenLineage, so both halves sit in one place.

Power Query tracing

Measure Killer reads the Power Query (M) code of your semantic models and dataflows to find which database tables and columns they use. It only reads the code. It never runs your queries and never loads your data.

Most queries are traced completely. The cases below are where they are not. Your reports are never affected. A limitation only means that the lineage Measure Killer shows may be incomplete:

A column you need may look unused, so check a column before you delete it from the database. The schema change how-to walks through that check.
A column may be linked to a table it does not come from. Nothing is lost then.

Each case says which warning Measure Killer shows. A case with no warning is silent: nothing on the screen tells you that the lineage is incomplete there.

These limitations come from reading the code without running it, so they will stay:

Pivoted columns. Their names come from your data, so they cannot be traced back. Warning: Columns From Data.
Computed names. If a server, database, schema or table name is looked up, built by a function or taken from data, that object is missing or shown under another name. Warning: Unresolved Source Name. For a database, schema or table name you also get Broken Source Detection.
Tables picked by position, like Source{0}[Data]. Everything below that step is missing. Warning: Broken Source Detection.
SQL built with a value known only at refresh, like "... WHERE d >= '" & StartDate & "'". The tables in that SQL are missing. Warning: Unresolved Source Name, on the step that runs the SQL.
Appends. Each column of the result is linked to every appended table. Warning: Ambiguity.
SQL that names a table without its schema. The schema is assumed, or the table is missing. Warning: Empty Hierarchy Name.
Model tables loaded through several partitions. Only the first partition is analyzed. Warning: Multiple Partitions.
Renames with a map that is not in the code, like a mapping file or an Enter Data table. The renamed columns cannot be traced. No warning. A map built with List.Zip shows a Missing Function warning for List.Zip.

Dataflows

Gen1, Gen2 and Gen2 CI/CD dataflows are traced at column level, through their Power Query steps and native SQL queries, including dataflows that read from other dataflows. The patterns that cannot be traced from the code alone are listed under Power Query tracing.

The lineage is only complete when every dataflow in the chain is selected and analyzed. If one is left out, the items connected to it can be missing.

Lakehouses, warehouses and notebooks

The Lakehouse, Warehouse, Fabric SQL Database mode traces each column of these items to the semantic models, dataflows, reports and visuals that use it. Import, DirectQuery, Direct Lake on OneLake and Direct Lake on SQL models are all covered. Models that go through the SQL analytics endpoint appear below it in the lineage.

Dependencies between lakehouses, warehouses and notebooks are shown at the item level only, not at the column level.

Semantic models

Inside a model, Measure Killer follows its own Power Query steps and native SQL at column level, then every place a column or measure can be used in the model. Used and unused explains these categories of usage.

Models built on other models are traced too, whether they connect through DirectQuery, as a composite model, or through the Analysis Services connector.

Measures imported from another semantic model through the Analysis Services connector show up in a generic table, not in the table where they live.
SSAS and AAS models cannot be analyzed in Tenant Analysis. Use the Analysis Services mode instead.

Reports and visuals

Power BI reports are traced down to the individual visual, including its visual-level filters and conditional formatting. Paginated reports and Excel files connected to a model are traced as well.

Power Query inside paginated reports is out of scope.
The few edge cases in reference detection itself are listed on the Compatibility page.

What your access changes

The lineage reaches as far as Measure Killer can see:

Tenant Analysis as a Fabric Administrator covers every workspace in the tenant.
Limited Tenant Analysis and the Developer modes cover only the workspaces you have access to: Contributor where semantic models live, Viewer where only reports live. Anything in a workspace you cannot access does not show up in the lineage.
The free edition traces a single model open in Power BI Desktop from source to visual. Lineage across models, dataflows and the tenant needs MK Enterprise or a free trial.

Found something that should be traced but is not? Use Report an issue on this page.

Something wrong or out of date on this page?