Trace a single column from a source table — through every dataflow, every semantic model, every report — down to the individual visual that renders it. End-to-end. No gaps.
The semantic-model-to-visual half already ships today, at full column-level detail. The upstream piece — dataflows, Power Query and the source column each field comes from — lands September 2026.
Not a diagram — the real thing, from the September build. It works in both directions. The new Column Lineage tab walks a source column downstream to the visuals that render it. And right-clicking any artifact — a semantic model, a column, a measure — offers View end-to-end lineage, which traces it back upstream to the data sources it came from.
Expand a source server in the Column Lineage tab — database, schema, table, column — then keep going: into every semantic model that reads that column, each model column flagged used or unused, and on to the relationships, visuals, visual-level filters and Excel workbooks that consume it.
Right-click any artifact — a semantic model, a column, a measure — and pick View end-to-end lineage. Measure Killer replays its full upstream trail in a tab of its own: every Power Query step it passed through, back to the exact source table and column it originates from, plus every place it is used downstream.
The steps aren't guesswork. Measure Killer parses the M query and groups it step by step — here first_name is selected, merged with last_name, and kept as the model column “Full name”.
Everything above is the upstream half — it ships September 2026. The model-to-visual half is live today: see how lineage works in the current release →
Microsoft Purview maps assets but not visuals. Power BI's own lineage view shows datasets but not the columns inside them. Data-catalog tools own the warehouse but thin out to dataset- and report-level once the trail crosses into Power BI — and none resolve the full dependency surface at the individual visual.
Measure Killer already does the hard half — today. It tracks column-level lineage from the semantic model all the way down to the individual visual: pick any column or measure and see every visual, filter, calculation and downstream report that references it. It also maps end-to-end source-to-report lineage at the table level.
What's coming September 2026 extends that same column-level precision upstream — through your dataflows and Power Query, back to the exact source column each field comes from — so the trail runs unbroken from that source column to the visual that renders it.
The source table and column each Power BI field comes from. The Lineage tab already maps every server and database to the models and reports downstream of it; column-level tracing lands with these sources:
All column changes tracked through Gen1 and Gen2 dataflows — every Power Query M transformation followed end to end. M Expressions search already resolves table and view references across every model and dataflow.
Every place a column or measure can be referenced inside the model:
Every report-level usage point — outside of the individual visuals:
The visual layer itself — fields bound to visuals, filters scoped to a single visual, and inline visual calculations.
Catalogs and lineage tools are strong on the database side — then collapse to dataset- or artifact-level (or nothing at all) the moment the trail enters a dataflow, a semantic model or a report. Measure Killer holds column-level detail the whole way down.
Catalogs are built for the data warehouse — and it shows. Measure Killer deliberately doesn't compete there; it starts where they fade out, the moment data enters Power BI, and holds column-level detail through every dataflow, semantic model and report.
Of the 7 stages from Power Query down to the individual visual, how many each tool resolves to the column.
Measure Killer reaches column level on the Power Query and native-SQL stages in September 2026; the semantic-model, report, paginated-report and Excel stages ship today.
| Pipeline stage | Measure Killer | Microsoft Purview | Power BI Sentinel | Atlan | Collibra | Alation | Dataedo | DataHub | Manta |
|---|---|---|---|---|---|---|---|---|---|
| Inside the data warehouse — the catalogs' turf Measure Killer traces from the source; mapping the warehouse's interior is out of scope by design. | |||||||||
| Inside the data warehouse table-to-table lineage, views & stored procedures upstream of Power BI | out of scope | Column | Table | Column | Column | Column | Column | Column | Column |
| Power Query → semantic model → report → visual — the full stage One unbroken trail, from the moment data enters Power BI to the visual that renders it. This is where every other tool goes dark. | |||||||||
| Power Query (M) transformations Gen1 / Gen2 dataflows and the model's M steps | Column Sep 2026 | Table | Table | Table | Table | Table | Table | Table | Table |
| Native SQL in Power Query raw SQL passed through M (value.NativeQuery) | Column Sep 2026 | – | Table | Table | Table | Table | Column | Column | Table |
| Semantic-model usage where a column / measure is actually used inside the model | Column | Table | Table | Table | Column | Column | Column | Table | Table |
| Downstream / composite models chained via DirectQuery or import from another semantic model | Column | – | – | – | – | – | – | – | – |
| Power BI reports down to the individual visual, filter & conditional formatting | Column | Table | Table | Table | Table | Table | Table | Table | Table |
| Paginated reports RDL reports — fields, parameters & tables | Column | – | – | – | – | Table | Table | Table | – |
| Excel Analyze-in-Excel PivotTables & connected workbooks | Column | – | – | – | – | – | – | – | – |
Every rating is a link (↗) to that vendor's own documentation — click any cell to verify the claim. Competitor depths are our best understanding as of July 2026 and vary by connector, edition and configuration; vendors evolve quickly. Spot something out of date? Tell us at gregor@brunner.bi and we'll correct it.
Some tools resolve columns in narrower cases. Microsoft Purview surfaces column-level lineage from an Azure SQL Database source into a dataset, but not through dataflows, in-model usage or the visual layer. Collibra and Alation parse DAX to link a measure to the columns it references (hence their column rating for semantic-model usage) — but not calculated tables, calculation groups, relationships or row-level security, the fuller in-model usage Measure Killer resolves.
Dataedo parses DAX to link a column to the measure that uses it (hence its column rating for semantic-model usage), and its lineage view carries that measure on to the visualization that displays it. But the chain to a visual runs through a measure: its documentation describes column-level lineage "from datasets to reports", so a column placed directly on a visual — or used only in a report, page or visual filter, conditional formatting, a slicer or a tooltip — resolves no further than the report, which is why the report row is rated table level. Those are the dependencies Measure Killer resolves at the visual. Its upstream source-to-model lineage is column-level only for an enumerated set of sources, requires each source to be separately catalogued in the same Dataedo repository with successful "linked source" matching (Service Principal auth for dataflows), and degrades on dynamic or generated SQL. It creates no lineage for Power BI Report Server (on-prem).
DataHub extracts Power BI lineage by parsing M-Query and the dataset API — mostly at table level, reaching column level only where native SQL is embedded in the M-Query and the advanced-lineage parsing flags are enabled (parameters aren't resolved). It doesn't parse DAX, so it maps no in-model usage of measures; and while a DataHub chart entity can carry field-level inputs, its Power BI connector attributes a tile to its dataset as a whole, not to the specific columns the visual displays.
Measure Killer's semantic-model and report stages are live today at column level. Upstream, the Lineage tab already maps each data source to everything downstream of it and M Expressions search resolves table and view references across every model and dataflow — though not inside raw native SQL, which today resolves only to the item and its database. The column-level upstream trace ships September 2026.
Mapping lineage inside the data warehouse is the catalogs' turf — Microsoft Purview, Collibra, DataHub, Atlan, Alation, Dataedo and Manta all do column-level lineage there. Most fade to dataset or table level the moment the trail crosses into Power BI. Dataedo goes furthest — it parses DAX and carries a column through the measure that uses it to the visualization that displays it — but that is the only route it reaches a visual by: a column placed directly on a chart, or used in a filter, conditional formatting, a slicer or a tooltip, resolves no further than the report, and its upstream column-level lineage is conditional on each source being separately catalogued and matched. Measure Killer is the only tool that resolves the full dependency surface at the visual — every filter, calculation and downstream reference, not just the fields in a chart — and carries column-level detail through downstream and composite models, paginated reports and Excel, tracing straight from the source with no pre-cataloguing step. Live today at column level from the semantic model down, and at table and view level upstream through every dataflow and M query; the column-level upstream trace — back to the source column each field comes from — ships September 2026.
And it's accurate: Measure Killer resolves references with industry-leading 99.99% reference-detection accuracy. See that page for the full scope of the analysis and its known limitations.
Measure Killer traces lineage at the column level through the semantic model and into individual Power BI reports, paginated reports and Excel — down to the specific visual, filter and calculation. Catalog and lineage tools such as Microsoft Purview, Power BI Sentinel, Atlan, Collibra, Alation, Dataedo, DataHub and Manta resolve columns at the source or warehouse; inside Power BI most reach only dataset or report level. A few parse DAX to tie a measure to its columns, and Dataedo carries that measure on to the visualization that displays it — but a column reaches a visual there only by way of a measure; placed directly on a chart it resolves no further than the report. None of them resolve the columns used in report, page and visual filters, conditional formatting, slicers or tooltips, and none reach downstream models, paginated reports or Excel the way Measure Killer does.
The semantic-model-to-visual half is available today at full column-level detail, and upstream of it Measure Killer already traces each data source to the models and reports downstream of it and resolves table- and view-level references across every dataflow and M query. In September 2026 that upstream trail goes column-level — back to the exact source table and column each field originates from — so lineage runs unbroken from that source column to the visual that renders it. Measure Killer connects to the originating source column; mapping lineage inside the data warehouse itself (table-to-table, views, stored procedures) is out of scope.
Power BI's native lineage view maps how artifacts connect — dataflows, datasets, reports — but not the columns inside them. Microsoft Purview goes a step further and can surface column-level lineage from an Azure SQL Database source into a dataset, but neither shows where a column or measure is actually used inside the model — in relationships, calculated columns, calculation groups or other measures — nor which visual consumes it. Measure Killer resolves exactly that: every place a column or measure is used across the model and down to the individual visual, and it can remove the unused ones, not just document them.
DBA wants to rename or drop a source column. Today: pray. With source-to-visual lineage: get a precise list of every visual that will break, who owns each report, and which dataflows or measures need to change first.
An executive asks "why is this number wrong?". Click the visual, walk the lineage backwards through the report, semantic model and dataflow to the exact source column. No more 30-minute spelunking sessions.
Someone asks what actually feeds "Net Revenue" — a warehouse table, a dataflow calculation, or a Power Query step a colleague added two years ago. Pick the column in the model and walk it upstream to the exact source server, database, table and column it originates from, with every dataflow, M step and native SQL query it passed through on the way.
Your data warehouse is paying to compute columns nobody reads. Identify source columns that don't reach any visual — anywhere in the tenant — and decommission them safely.
Measure Killer already removes unused columns and measures from semantic models. With end-to-end lineage we extend that one step further upstream: trim unused columns and entire unreferenced queries out of your Gen1 and Gen2 dataflows — fewer refresh minutes, smaller bills, simpler models.
Strip out unused columns, tables and calculation steps from your semantic models in minutes, with the confidence that nothing downstream will break. Smaller models refresh faster, consume fewer Fabric capacity units (CUs), and present a clean, well-named schema that Copilot for Fabric and other LLMs can actually reason about.
Prove which reports and visuals consume PII columns. Audit-grade answers in seconds instead of weeks.
A lineage graph is only useful where people already look. So we're pushing ours out — writing the Power BI and Fabric lineage Measure Killer resolves into the catalogs your data platform teams live in, refreshed on a schedule by MK Automation. Databricks Unity Catalog is the first.
Unity Catalog tracks your lakehouse right up to the Power BI connector, then goes dark. Measure Killer writes the rest of the graph in as external metadata — dataflows, semantic models, reports, report pages and individual visuals — so a Databricks user can trace a table all the way to the visual that renders it without leaving Databricks.
Note that Unity Catalog currently renders column-level flow one hop at a time — the full multi-hop column chain is written into the catalog, but following it end to end in a single view is something you still do in Measure Killer.
Column-level relationships
Not just object-to-object edges — the individual column mappings behind them, including the aggregations defined in DAX and Power Query that API-based connectors can't see.
Tagged and reversible
Every object carries generated_by: "Measure Killer" and its workspace ID, so its contribution stays auditable and separable from Databricks' own lineage.
Refreshed on schedule
Runs from MK Automation on the same cadence as your tenant scan, reconciling renames and deletions instead of leaving orphans.
More catalogs will follow. If your team standardizes on a different one — tell us which and we'll weigh it for the next integration.
The first wave will cover SQL Server, Azure SQL Database, PostgreSQL, Snowflake, Fabric Warehouse, Fabric SQL, Fabric Lakehouse and Databricks as sources. KQL / Kusto, Google BigQuery, Amazon Redshift, Oracle and SAP HANA are on the roadmap for subsequent releases.
If you want a preview build, hands-on guidance, or to put your specific source on the priority list — reach out and we'll get you into the early-access cohort.
Measure Killer