Azure Data Lineage That Doesn’t Stop at the Azure Boundary
Quick definition: Azure data lineage
Azure data lineage is the record of how data moves and transforms across Azure services such as Azure Data Factory, ADLS Gen 2, Synapse, Microsoft Fabric, and Power BI. Microsoft Purview and Fabric capture this lineage inside the Microsoft ecosystem.
Many teams running Azure already use Microsoft Purview as a data catalog. Fabric gives you a real foundation for data lineage inside the Microsoft ecosystem, and for assets that live entirely within Azure, that foundation often covers what you need.
The question is what happens when you need lineage from outside the boundaries of your Azure estate. Impact analysis and incident triage rarely respect a single platform’s edge. Purview can reach past Azure. You can register and scan a source like Snowflake, but you configure and maintain each connection yourself, and column-level lineage stays inconsistent across those sources. That unevenness is exactly what impact analysis depends on. This is where a cross-platform layer like DataHub earns its place as the connective tissue that puts your Azure investment in context with the rest of your data supply chain.
What does Azure-native lineage actually cover?
Microsoft Purview captures lineage as data moves through Azure systems, stitching metadata from data processing, storage, and reporting tools into a single graph in the Microsoft Purview Data Map. Azure Data Factory pushes lineage at execution time, Power BI reports their dependencies, and storage and analytics systems report what they transform.
For a stack that lives entirely inside the Microsoft boundary, that coverage is pretty useful for troubleshooting, root-cause analysis, and impact assessment.
The coverage has a couple of limits, though:
- Lineage granularity varies by system. Per Microsoft’s Purview lineage documentation, column-level lineage is captured for specific scenarios, such as a one-to-one column copy in Azure Data Factory, rather than uniformly across every connected source.
- The surface itself is in motion. Microsoft is consolidating its governance tools into the new Microsoft Purview portal, moving the classic Data Catalog’s capabilities into the Unified Catalog or retiring them. What “Purview lineage” refers to keeps shifting as that consolidation plays out.
Two gaps in Azure-native lineage that show up in production
Native Azure lineage holds up well until it meets the conditions that define most production incidents: you need to know exactly which column breaks, and the trail crosses a platform boundary.
1. Column-level depth is inconsistent
Table-level lineage tells you that a downstream report consumes a table. It does not tell you that the report’s revenue figure depends on a single column you are about to rename.
Purview does not provide complete column-level lineage from all sources. For example, Purview doesn’t automatically capture lineage for Fabric assets. Without consistent column-level lineage, impact analysis answers the wrong granularity of question, and engineers fall back to reading queries by hand to find out what actually breaks.
2. Lineage stops at the platform boundary
Azure-heavy stacks are rarely Azure-only. Most enterprise data environments run Databricks, Snowflake, dbt, Airflow, and non-Microsoft BI tools alongside the Azure-native services, and data flows freely between them.
When lineage stops at the platform edge, a single logical pipeline fractures into separate graphs that nobody can read together. Debugging an incident then means manually tracing the same dataset across three or four tools, and the lineage graph cannot answer the cross-system questions that matter most when something is on fire.
How DataHub extends Azure lineage
With native connectors for OneLake, Data Factory pipelines, and Power BI and Fabric reporting artifacts, DataHub can discover and trace lineage across most core Fabric services. DataHub picks up where Azure-native lineage leaves off. It connects Azure SQL, ADLS Gen 2, Azure Data Factory, Power BI, and Fabric into the same lineage graph as every other platform in your stack, and adds the column-level depth Purview doesn’t provide consistently.
Column-level lineage across Azure systems
Column-level lineage is the primary extension DataHub provides over Azure-native tooling. Where Purview’s column coverage is patchy and Fabric lacks reliable native column lineage, DataHub produces column-level lineage across Azure systems, so impact analysis can resolve to the specific field a change will affect. If your team already relies on Purview for governance and cataloging inside Azure, that depth is complementary rather than competing.
One lineage graph across every platform
Cross-platform lineage is the capability that makes Azure lineage extensible rather than siloed. DataHub stitches Azure-native services and the surrounding Databricks, Snowflake, dbt, Airflow, and non-Microsoft BI tools into one graph. A trace that begins in ADLS and ends in a Power BI dashboard stays intact even when it passes through a Databricks notebook and a Snowflake table on the way.
Propagate governance once, across every platform
Because DataHub sits across catalogs rather than inside one, it can act as the source of truth for metadata and use your lineage graph as the distribution mechanism. When someone tags a column or applies a glossary term, that decision propagates automatically to every downstream asset derived from it, across whatever platforms those assets live on.
A glossary term applied to address_line2 in an Azure SQL source table shows up on billing_address_line2 and shipping_address_line2 in the Fabric warehouse, the Snowflake mart, and the Power BI report downstream, without anyone reapplying it at each step. This is what column-level lineage makes possible that table-level lineage cannot: a single human judgment becomes durable across your data supply chain.
Which Microsoft systems does DataHub connect to?
DataHub ingests lineage and metadata from the Microsoft services most Azure stacks rely on, then connects them to the rest of your data systems. For Azure Data Factory, lineage is generated from Copy and Data Flow activities, the same signals Purview reads.
| Microsoft service | Lineage scope in DataHub |
| Azure Data Factory (classic) | Table-level and column-level lineage |
| Microsoft Fabric OneLake (OneLake and Data Warehouse) | Table-level and column-level lineage via view SQL parsing |
| Microsoft Fabric Data Factory | Table-level lineage |
| Power BI | Table-level and column-level lineage |
| Microsoft SQL Server | Table-level and column-level lineage |
We added native Microsoft Fabric connectors in DataHub Cloud v0.3.17, so DataHub now reads lineage across Fabric OneLake, the Fabric Data Warehouse, and Fabric Data Factory alongside Power BI. Since Purview doesn’t automatically capture lineage for Fabric assets, that native coverage is where DataHub fills a gap rather than duplicating what Azure already does. Teams running Fabric next to Snowflake, Databricks, or dbt no longer have to stitch that boundary together by hand.
DataHub propagates metadata along that same lineage. Set a tag, glossary term, or description on an Azure SQL or ADLS source table once, and DataHub carries it downstream to the derived datasets and the Power BI reports built on them, so nobody has to reapply the classification at every step.
Lineage is what analytics agents reason from
Analytics agents like Snowflake Cortex Analyst and Databricks Genie One answer questions by querying your data, and a result is only as trustworthy as the agent’s grasp of what the data means and where it came from. In DataHub’s 2026 State of Context Management Report, a survey of 250 IT and data leaders, 83% said agentic AI cannot reach production value without a dedicated context platform.
When an agent reads a derived table, cross-platform column-level lineage lets it inherit the descriptions, glossary terms, and source context that traveled with the data, not just the raw schema. Industry benchmarks like BIRD find that adding this kind of semantic context improves text-to-SQL accuracy by up to 20 percentage points over raw schema alone. Pinterest built its most-used internal analytics agent on exactly this foundation, with DataHub as the store for governance, ownership, and column-level semantics. That agent now runs at 10x the usage of any other internal tool at the company.
This is a different job from access control. Deciding what an agent is allowed to open is necessary, but it does not tell the agent what a column means or which upstream source produced it. Lineage supplies the context agents reason from, and DataHub is the context platform that supplies it.
The upside: impact analysis and incident triage across platforms
Column-level lineage that crosses platforms shows you what a change will break before you make it. Rename a column in a Fabric warehouse or restructure an Azure Data Factory pipeline, and impact analysis surfaces the downstream Power BI reports, dbt models, and Databricks tables that depend on it, including the ones on other platforms. You stop shipping changes that quietly break a report two platforms away.
When something does break, the same graph runs in reverse. Instead of opening four tools to trace a bad value back to its source, you follow one lineage path from the broken report upstream to where the problem started, even when it passes through Snowflake or Databricks. The trace is one connected graph, not four you have to reconcile by hand.
Put your Azure lineage in context with the rest of your stack. See how DataHub builds cross-platform lineage.
