How Microsoft Purview Data Lineage Works in Microsoft Fabric

A report owner preparing to change a key metric needs to understand where its data comes from and which assets depend on it. Microsoft Purview Data Lineage in Microsoft Fabric helps organizations understand relationships between supported Fabric assets, trace dependencies, and assess potential downstream impacts.

The practical process involves registering the Fabric tenant with Microsoft Purview, configuring the required access, scanning supported Fabric metadata, and reviewing the lineage relationships that are captured.

However, lineage coverage has important limitations. The level of detail available depends on the Fabric item, supported lineage capabilities, configuration, and service boundaries. In particular, organizations should distinguish between catalog and metadata discovery and actual connected lineage relationships.

This guide explains how Microsoft Purview and Microsoft Fabric work together, the prerequisites and permissions involved, how lineage is captured and interpreted, and the limitations organizations should understand before relying on lineage for impact analysis.

Data lineage represents the recorded relationships and movement of data between sources, Fabric items, transformations, and downstream consumption points where those relationships are supported.

For data teams, lineage can help answer questions such as:

Fabric provides native capabilities for discovering and understanding relationships between Fabric items. Microsoft Purview adds cataloging, metadata management, classification, governance, and lineage capabilities for supported assets across the broader data estate.

The two platforms can therefore complement one another, but they should not be treated as interchangeable or as providing identical lineage coverage.

When the relevant relationships have been captured, lineage can support:

For example, a change to a supported source or Fabric item could affect a pipeline, Lakehouse or warehouse asset, semantic model, or Power BI report. Reviewing available downstream relationships can help teams identify assets that may require testing before the change is deployed.

After the Fabric tenant is registered and the required configuration is completed, scanning can bring supported Fabric metadata and lineage information into Microsoft Purview.

Metadata describes an asset, while lineage represents captured relationships between assets.

Microsoft Purview can also provide governance capabilities such as catalog discovery, classifications, ownership information, and sensitive information context for supported assets.

Upstream lineage can help users understand which captured assets provide inputs to a selected asset, while downstream lineage can show supported assets that depend on it.

Automated metadata capture reduces the need for completely manual documentation, but it does not automatically map every source, transformation, or dependency. Coverage depends on supported item types, configurations, and the lineage relationships that the platform can discover.

Fabric Lineage View Versus Purview Lineage

Fabric and Microsoft Purview provide complementary capabilities, but the distinction should not be reduced to “Fabric for local dependencies” and “Purview for everything broader.”

Microsoft Fabric has its own native governance, discovery, and data-management capabilities. Fabric lineage views can help users understand relationships between Fabric items within the applicable Fabric environment.

Microsoft Purview provides additional cataloging and governance capabilities and can provide lineage for supported assets and relationships that have been discovered through its scanning and metadata capabilities.

For non-Power BI Fabric items, organizations should be particularly careful about assuming that Purview can automatically connect assets across workspaces or trace them back to external upstream sources.

A practical setup sequence is:

Permissions must cover the relevant Fabric and Purview operations while following least-privilege principles.

A scan discovers permitted metadata across supported boundaries. It does not automatically grant catalog users access to the underlying data.

Permissions and Ownership to Confirm

Different activities can require different permissions. These can include tenant registration, scan configuration, catalog management, and lineage viewing.

For Fabric Lakehouse sub-artifact scans, the applicable permissions and preview status should be confirmed against current Microsoft documentation. Metadata scanning should not be confused with sub-item lineage support.

Clear ownership is also important. Organizations should assign responsibility for:

Clear accountability helps prevent scan failures, incomplete metadata, and unresolved ownership issues from becoming operational problems.

Purview scans supported Fabric metadata, identifies supported assets and relationships, and makes the resulting information available through applicable catalog and lineage experiences.

Supported Fabric items can include data pipelines, notebooks, Lakehouses, warehouses, semantic models, and reports, subject to the current support matrix and configuration.

Lakehouse sub-item metadata scanning may provide additional metadata visibility, but this should not be interpreted as support for sub-item lineage.

Another important limitation is that, for non-Power BI Fabric items, cross-workspace lineage is not supported. Similarly, external data sources cannot be assumed to appear as upstream lineage sources for these items.

Open an asset in Purview and inspect the available lineage graph to investigate captured relationships. When the question concerns relationships between Fabric items, the native Fabric lineage experience may also provide useful context.

Dynamic data sources can be difficult to resolve because locations or connection details may be determined at runtime. Custom logic and other unsupported relationships can also result in incomplete lineage.

Reading an Upstream and Downstream Lineage Graph

Upstream assets provide inputs to the selected asset, while downstream assets depend on its output.

For a proposed change, review both directions where supported:

Do not assume that the upstream graph will always reach the original external source. For non-Power BI Fabric items, external upstream lineage sources are not supported.

Similarly, do not treat a large lineage graph as a complete operational diagram. Focus on the relevant path and validate important dependencies independently.

What the Graph Does Not Prove

A visible lineage relationship does not prove:

The graph represents captured relationships. It does not replace engineering documentation, monitoring, testing, ownership records, security controls, or data-quality processes.

Organizations should therefore use lineage together with:

These controls provide operational and governance evidence that lineage alone cannot supply.

On a phone, scroll the table sideways to see every column.

The key point is that Microsoft Purview’s broader catalog and governance capabilities should not be interpreted as unrestricted cross-workspace or cross-estate lineage.

Example: Tracing a Report Through Supported Relationships

Consider operational data that enters Fabric through a supported pipeline, is stored in a Lakehouse or warehouse, and ultimately feeds a semantic model used by a Power BI report.

When a key performance indicator changes unexpectedly, a team can begin with the report and identify its semantic model. From there, the team can review available upstream relationships through the supported Fabric and Power BI lineage paths.

The team can then investigate relevant tables, transformations, pipelines, and other captured dependencies and review downstream relationships to identify potentially affected reports.

However, the example should not imply that every scenario can be traced all the way back to an external original source. For non-Power BI Fabric items, external upstream lineage is not supported.

This distinction is important when using lineage for change-impact analysis.

A practical change-impact process should include:

Windows Management Experts, Inc. applies this type of methodical planning to complex Microsoft environments where downtime, data loss, and compliance gaps must be prevented. The essential principle is to understand dependencies before altering them.

Microsoft Purview lineage for Fabric should not be treated as a complete map of every data relationship.

A successful scan does not mean governance is finished. Organizations should rescan and review relevant metadata after material changes to workspaces, pipelines, models, source systems, or architecture.

Another common mistake is treating the lineage graph as a replacement for engineering documentation. Lineage shows captured relationships, but teams still need transformation definitions, operational procedures, ownership records, security controls, and recovery plans.

Practices That Improve Lineage Quality

Organizations can improve the usefulness of lineage by:

A medallion architecture can also clarify progression through raw, validated, and curated data layers where that pattern fits the workload.

Avoid overly dynamic pipeline sources when traceability is a requirement. Document exceptions and dependencies that automated discovery cannot represent.

Most importantly, treat lineage as one component of a broader governance and change-management process rather than as a complete dependency map.

A practical lineage operating model should combine automated scanning with human review.

A recurring process can include:

Prioritize sensitive, regulated, executive-reporting, and operationally critical data products rather than trying to perfect every asset simultaneously.

Suggested Review Cadence

Review lineage and related metadata after:

Assign responsibility for correcting missing metadata, addressing scan failures, documenting unsupported dependencies, and resolving unclear ownership.

Microsoft Purview can make supported Fabric relationships more visible and provide valuable catalog and governance context. However, lineage visibility should not be confused with complete dependency discovery.

For non-Power BI Fabric items, organizations need to account for important limitations, including item-level lineage, the lack of supported cross-workspace lineage, the lack of external upstream lineage, and limitations involving specific relationships such as Notebook-to-Pipeline lineage.

Reliable lineage therefore requires more than a successful scan. Organizations should combine Microsoft Fabric and Microsoft Purview capabilities with appropriate permissions, clear ownership, engineering documentation, testing, stable architecture, monitoring, and regular review.

The goal is not simply to create a lineage graph. The goal is to use the supported lineage information responsibly as part of a broader process for understanding dependencies, managing change, and maintaining trustworthy data operations.

Microsoft Documentation Sources

These Microsoft Learn sources support the technical statements and configuration guidance discussed in this article. Microsoft documentation should be checked for the latest supported features, permissions, regional availability, and configuration requirements before implementation.