Data lineage is a map of data movement. In the context of Power BI, lineage documents the full path that data travels from its origin (a database, API, or file system) through each processing step (pipelines, transformations, staging layers) to the final destination (a Power BI dataset and the reports built on it).
Why lineage matters for Power BI
Without lineage, every data incident starts the same way: someone reports wrong numbers, and an engineer starts checking everything — ADF run history in Azure Monitor, Power Query in the dataset, the source database, the dbt job log. The investigation has no structure because there's no map.
With lineage, the same incident starts differently: the monitoring system shows the affected report, traces back to the dataset, identifies the upstream pipeline that feeds it, and shows the specific activity or transformation that failed. Investigation time drops from hours to minutes.
The components of Power BI lineage
A complete lineage map for a Power BI dataset includes:
- Source systems: The databases, APIs, file systems, or SaaS applications that contain the raw data
- Pipeline layer: ADF pipelines, Fabric Data Pipelines, or custom scripts that move and initially transform the data
- Transformation layer: dbt models, Databricks notebooks, or Synapse SQL that build analytical models
- Serving layer: The database tables or Delta tables that Power BI reads from
- Power BI datasets: Semantic models that define metrics, hierarchies, and relationships
- Power BI reports: Visualizations built on top of datasets
Where lineage data comes from
Lineage isn't stored in one place — it's assembled from multiple sources:
- ADF pipeline run metadata (which pipeline wrote to which table)
- dbt manifest files (the model dependency graph)
- Power BI REST API datasource metadata (which server, database, and table each dataset reads)
- Databricks job run metadata (which jobs read from and write to which Delta tables)
Forward and backward traversal
Lineage enables two types of traversal:
- Backward (root cause): Starting from a broken report, trace backward to find where in the pipeline the failure originated
- Forward (impact): Starting from a failed component (a pipeline, a dbt model, a database table), trace forward to identify all reports currently serving stale or incorrect data