--- title: "Which Tools Support End-to-End Power BI Column-Level Lineage?" url: "https://atlan.com/know/data-catalog/microsoft/power-bi-column-level-lineage/" description: "See the five-hop chain from a Fabric source table to a Power BI visual, the four settings for page-level lineage, and why it stops before Snowflake or Synapse." author: "Emily Winks" author_role: "Data Governance Expert" published: "2026-09-29" updated: "2026-09-29T00:00:00.000Z" --- > Atlan is hosting Context Conference, bringing together the leaders and builders at the frontier of giving AI the context it needs to understand their business. It runs online on October 28, 2026, from 11:00 AM to 2:00 PM ET. Atlan co-founder Prukalpa Sankar opens and closes the day. Leaders from AstraZeneca, BNY and Verizon share why they invest in context and what they get from it. Registrants get early access to The AI Context Gap, a new study from MIT Technology Review Insights. Register: https://atlan.com/context-conference/ --- Column-level lineage for Power BI is the ability to trace a single column or measure from its source table, through Microsoft Fabric's lakehouse or warehouse layer and a semantic model, to the exact report page and visual that display it. Atlan, alongside Microsoft Fabric, Microsoft Purview, Snowflake, and Azure Synapse, is one of the few platforms that documents the complete source-to-visual chain, including the four specific prerequisites required to get lineage past the semantic model and down to the visual. Mapping that chain surfaces two seams where Microsoft's own documentation says it typically stops, and the checklist below is what closes the gap. ### Build Your Lineage Coverage Shortlist Give it the lineage tools you're considering and your actual BI/warehouse stack. It returns an evaluation matrix scored on connector coverage, where lineage stops, and who maintains the metadata. [Read the skill](/skills/catalog-tool-shortlist.md). *Paste into a new chat* ``` Use the skill at https://atlan.com/skills/catalog-tool-shortlist.md to build an evaluation matrix for the Power BI lineage coverage we're comparing. Ask me for whatever it needs. ``` *Run once in a terminal* ``` curl -fsSL --create-dirs \ -o ~/.agents/skills/catalog-tool-shortlist/SKILL.md \ https://atlan.com/skills/catalog-tool-shortlist.md ``` *For an agent* ``` curl -fsSL https://atlan.com/skills/catalog-tool-shortlist.md ``` Human Agent ClaudeChatGPTGeminiCursorOther Copy .skp{margin:1.75rem 0;padding:1rem 1.125rem 1.125rem} .skp h3{margin:0 0 .375rem!important;font-size:20px!important;line-height:24px!important; font-family:var(--font-funnel-display)!important;font-weight:600!important;color:#2B2B39!important} .skp > p{margin:0 0 .875rem!important;font-size:14px!important;line-height:22px!important;color:#555572!important} .skp > p a{color:#2026D2;text-decoration:underline} .skp-box{margin-bottom:.75rem} .skp-p em{display:block;font-size:10px;font-weight:700;letter-spacing:.06em;text-transform:uppercase; color:#F34D77;font-style:normal;margin-bottom:.25rem} .skp-p > p{margin:0!important} #seo-layout article .skp .skp-p pre{margin:0!important;overflow-x:auto} #seo-layout article .skp .skp-p pre code{color:#2B2B39!important;font-size:12px!important;line-height:19px; white-space:pre-wrap;overflow-wrap:anywhere;background:none;padding:0; font-family:ui-monospace,SFMono-Regular,Menlo,monospace} .skp-p + .skp-p{margin-top:.625rem} .skp-cs{display:flex;flex-wrap:wrap;align-items:center;gap:.375rem} .skp-seg{display:inline-flex;flex:0 0 auto;border:1px solid #DDDDE3;border-radius:999px;overflow:hidden;background:#fff} .skp-m{min-height:32px;padding:.25rem .75rem;border:0;background:transparent;font-family:inherit;color:#77778E;cursor:pointer} .skp-m:hover{color:#2026D2} .skp-m.on{background:#2026D2;color:#fff} .skp-sep{flex:0 0 auto;width:1px;height:20px;background:#DDDDE3;margin:0 .25rem} .skp-tools{display:inline-flex;flex-wrap:wrap;gap:.375rem;min-width:0} .skp-cp{margin-left:auto;min-height:32px;padding:.25rem .75rem;border-radius:999px;background:#fff; font-family:inherit;color:#555572;cursor:pointer} .skp-cp:hover{border-color:#2026D2!important;color:#2026D2} .skp-cs .skp-c{display:inline-flex!important;width:auto;flex:0 0 auto;align-items:center;gap:.375rem; min-height:32px;padding:.25rem .625rem;border-radius:999px;background:#fff;font-family:inherit; color:#555572;cursor:pointer} .skp-cs .skp-c img{display:block!important;width:14px!important;height:14px!important; max-width:14px!important;flex:0 0 auto;opacity:.55;margin:0} .skp-c:hover img,.skp-c.on img{opacity:1} .skp-cs .skp-c:hover{border-color:#797DE4!important;color:#2026D2} .skp-cs .skp-c.on{border-color:#2026D2!important;background:#F4F4FD;color:#2026D2} .skp-agent .skp-tools,.skp-agent .skp-sep{display:none} (function(){ var p=document.querySelector('.skp[data-skill="catalog-tool-shortlist"]');if(!p)return; var panes=p.querySelectorAll('.skp-p'); function show(id){panes.forEach(function(x){x.hidden=x.dataset.skp!==id;});} function cur(){var a=p.querySelector('.skp-p:not([hidden]) pre code');return a?a.textContent:'';} show('prompt'); p.querySelectorAll('.skp-p em').forEach(function(e){ var par=e.parentElement; ((par.tagName==='P'&&par.textContent.trim()===e.textContent.trim())?par:e).hidden=true; }); p.querySelectorAll('.skp-c').forEach(function(b){ b.addEventListener('click',function(){ p.querySelectorAll('.skp-c').forEach(function(x){var on=x===b;x.classList.toggle('on',on);x.setAttribute('aria-pressed',on);}); show(b.dataset.skp); }); }); p.querySelectorAll('.skp-m').forEach(function(m){ m.addEventListener('click',function(){ var agent=m.dataset.skpMode==='agent'; p.classList.toggle('skp-agent',agent); p.querySelectorAll('.skp-m').forEach(function(x){var on=x===m;x.classList.toggle('on',on);x.setAttribute('aria-pressed',on);}); if(agent){show('agent');}else{var s=p.querySelector('.skp-c.on');show(s?s.dataset.skp:'prompt');} }); }); var c=p.querySelector('[data-skp-copy]'); c.addEventListener('click',function(){ navigator.clipboard.writeText(cur()).then(function(){ c.textContent='Copied';setTimeout(function(){c.textContent='Copy';},1600); }); }); })(); The chain has five hops, and Microsoft's own documentation names a hard boundary at two of them. Fabric's lineage view shows external sources one step upstream and stops there. Purview's column-level lineage for Power BI works only when the upstream source is Azure SQL Database. Getting lineage all the way to the report page and visual is a configuration choice, not a default: the connection's Scanner API access has to be switched off, not on, alongside three other settings covered below. Fabric and Purview are doing exactly what they are built and documented to do inside the Microsoft estate. The gap shows up specifically where an estate spans Microsoft and non-Microsoft platforms, which describes most real deployments. - The five hops: source table, Fabric lakehouse or warehouse, semantic model, report, and visual - The two Microsoft-documented stopping points: Fabric's one-hop native view and Purview's Azure SQL Database restriction - The four settings that decide whether lineage reaches the page and visual, not just the semantic model - Why a cross-platform graph, not a bigger native view, is what closes the remaining gap | Fact | Detail | |---|---| | What it is | Tracing a specific column or measure from its source table through Fabric and a semantic model to the exact report page and visual using it | | Key mechanism | Parsing Power Query (M) expressions and DAX measures to recover column-to-column mappings the native object graph doesn't show | | Where it breaks | Fabric's native lineage view stops one hop upstream; Purview's Power BI column lineage works only for Azure SQL Database sources | | Prerequisites for page/visual lineage | Fabric public API tenant setting, Contributor+ workspace role, Scanner API access off, Fetch Report Definition Extracts on | | Best for | Migration validation, pre-change impact analysis, and tracing a KPI back to its source column when a number looks wrong | | Core components | Semantic model, Power Query (M), DAX measures, Direct Lake, Entra ID service principals | --- ## What is column-level lineage for Power BI, and why does it matter beyond the report level? Column-level lineage for Power BI means tracing a specific field or measure, not just a report or dataset, back to the exact upstream table and column it came from. Report-level lineage, which [Microsoft's native lineage view already provides](https://learn.microsoft.com/en-us/fabric/governance/lineage), tells you a report connects to a given semantic model and data source. Column-level lineage goes one layer deeper: it tells you which specific column feeds which specific measure or field, across the five hops between the two. That granularity matters for three practical reasons. Migration validation confirms that the exact fields a report depends on survived a move into Fabric, not just that the connection string still resolves. Impact analysis shows which visuals reference a column before a schema change ships, catching breakage before it reaches a dashboard. Root-cause investigation is the third: when a KPI looks wrong, column-level lineage traces the display value through the semantic model's Power Query (M) transformations and DAX measures back to the specific warehouse or lakehouse column behind it, rather than leaving an analyst to guess. Teams building [data lineage for AI](https://atlan.com/know/ai-agent/data-for-ai/data-lineage-for-ai/) use cases run into the same dependency problem an analyst does, just with an agent doing the reasoning instead of a person. For readers arriving from a more general starting point, [what a data catalog is](https://atlan.com/what-is-a-data-catalog/) and how it differs from a [context layer](https://atlan.com/know/data-catalog-vs-context-layer/) are useful grounding before the Power BI-specific mechanics below. Atlan documents the full source-to-visual chain end to end, including the exact conditions under which each hop succeeds or silently produces nothing, a level of detail no single native tool currently publishes in one place. --- ## How does lineage flow from a Fabric source table to a Power BI visual? Lineage moves through five distinct layers between a source table and a Power BI visual, and each layer uses a different mechanism to pass the connection forward: an external SQL source, a Fabric lakehouse or warehouse, a semantic model built from Power Query (M) and DAX, a report, and the specific page and visual a reader sees. A crawler that only reads object-level relationships can see that the layers connect; reconstructing which column feeds which takes a dedicated parser. The five-hop lineage chain Source table SQL Server, Snowflake, etc. Fabric lakehouse or warehouse Semantic model Power Query (M), DAX measures Report Power BI Page / visual Needs 4 settings Reaching the last hop depends on four specific settings; see the checklist below. The five hops between a source table and the Power BI visual that displays it. Each hop uses a different mechanism to carry lineage forward. ### Source table to Fabric lakehouse/warehouse An external SQL source, whether an on-premises SQL Server instance or a cloud warehouse, lands in Fabric as a table inside a lakehouse or warehouse. [Atlan's Microsoft Fabric connector](https://docs.atlan.com/apps/connectors/business-intelligence/microsoft-fabric) catalogs these lakehouse and warehouse schemas, tables, views, and columns as the first hop. This is also the layer where a [context layer for Snowflake](https://atlan.com/know/context-layer-for-snowflake/) or a [context layer for Databricks](https://atlan.com/know/context-layer-for-databricks/) has to pick the thread back up once it crosses into non-Microsoft territory. ### Semantic model, Power Query (M), and DAX measures A [Power BI semantic model](https://atlan.com/know/ai-agent/semantic-layer/power-bi-semantic-model/) sits between the Fabric data layer and the report, and it carries most of the real transformation logic. Power Query (M) expressions reshape and rename columns before they become fields, and DAX measures calculate the values a report actually displays. Atlan's parser resolves named M expressions and specific functions, including `Table.RenameColumns`, `Table.TransformColumnNames`, and `Table.TransformColumns`, to derive the upstream table and column a field or measure depends on. Non-standard or heavily customized M expressions are a documented parsing limit here and across the industry, not a gap unique to one tool. The same question of how far a semantic layer can carry structure shows up in [Power BI semantic model vs. a dedicated semantic layer](https://atlan.com/know/ai-agent/semantic-layer/power-bi-semantic-model-vs-dedicated-semantic-layer/) and in [semantic layer vs. data catalog](https://atlan.com/know/ai-agent/semantic-layer/semantic-layer-vs-data-catalog/). [Direct Lake overview](https://learn.microsoft.com/en-us/fabric/fundamentals/direct-lake-overview) explains why connector choice at this layer matters. Direct Lake lets Power BI query a Fabric lakehouse table's Delta tables directly, without an extra connector hop, which keeps the chain intact; Microsoft's own documentation notes that routing a Direct Lake refresh through a gateway is not supported, which is the same seam that produces an opaque hop for lineage. Routing the same data through a generic database connector or gateway instead can introduce an opaque hop a lineage crawler cannot see through, a distinction also covered from the analyst side in [Microsoft Fabric vs. Power BI](https://atlan.com/microsoft-fabric-vs-power-bi/). ### Report, page, and visual: the last and hardest hop This is where item-level relationships, what Fabric's own graph shows by default, and subartifact metadata, what the Scanner API can additionally surface, diverge. According to [Microsoft Learn's Fabric metadata scanning documentation](https://learn.microsoft.com/en-us/fabric/governance/metadata-scanning-overview), subartifact metadata includes table and column names, measures, DAX expressions, and M queries, information the item-level graph alone does not carry. A catalog that reads this subartifact layer, or parses the M and DAX expressions directly, can reconstruct which page and visual a column ultimately feeds. Reaching that depth also depends on four specific settings, covered next, and missing any of them is the single most common reason a Fabric or Power BI connection produces reports but no real lineage. Every one of these hops does exactly what Microsoft built it to do; the four settings below are what turn a connected estate into one with lineage all the way to the visual. --- ## Which prerequisites are required to get lineage down to the Power BI page and visual? Reaching page- and visual-level lineage in Power BI depends on four specific settings, and missing any one of them fails silently rather than producing an error. According to [Atlan's documentation on Microsoft Power BI lineage](https://docs.atlan.com/apps/connectors/business-intelligence/microsoft-power-bi/references/what-lineage-does-atlan-extract-from-microsoft-power-bi), column- and measure-to-page lineage needs a Fabric tenant setting that lets service principals call Fabric's public APIs, a workspace role of Contributor or higher for the scanning identity, the connection's Scanner API access switched off, and its Fetch Report Definition Extracts option switched on. All four have to be true at once, a setup covered step by step in [Atlan's guide to configuring Power BI tenant settings](https://docs.atlan.com/apps/connectors/business-intelligence/microsoft-power-bi/how-tos/configure-power-bi-tenant-settings). The common mistake is picking the setup that looks simpler. Teams often enable Scanner-API-only mode because it is tenant-wide and does not require granting workspace-by-workspace permissions, the low-friction path. That configuration produces a complete asset inventory of workspaces, reports, and datasets; it does not produce page- or visual-level lineage, and it throws no error saying so. According to the permissions section of [Microsoft Learn's Fabric governance and lineage documentation](https://learn.microsoft.com/en-us/fabric/governance/lineage), a Viewer role can open the lineage view but cannot see the underlying data sources, the same asymmetry playing out one layer up: the setup that is easiest to grant is also the one that sees the least. Practitioners on [Reddit's r/MicrosoftFabric community](https://www.reddit.com/r/MicrosoftFabric/comments/1m99b6v/what_is_everyone_using_for_data_lineage/) independently describe resorting to manually parsing Scanner API output to reconstruct column-level dataset metadata themselves, and a [second r/MicrosoftFabric thread](https://www.reddit.com/r/MicrosoftFabric/comments/1n9ub15/import_mode_in_fabric_how_do_you_track_lineage/) confirms that correlating a semantic model to its underlying warehouse tables often means reading M expressions by hand. That manual work is exactly what a purpose-built parser automates, and it is the foundation any [AI-ready data lineage](https://atlan.com/know/ai-readiness/ai-ready-data-lineage/) program eventually needs. A team evaluating this checklist against its own environment is doing the same exercise the [Fabric governance evaluation checklist](https://atlan.com/know/ai-agent/microsoft/fabric-governance-evaluation-questions/) walks through in more depth, and the [Power BI data catalog setup guide](https://atlan.com/how-to/microsoft-power-bi-data-catalog-setup-guide/) covers the connector setup steps around it. | Requirement | Why it's needed | What happens if missing | |---|---|---| | Fabric tenant setting: service principals can call Fabric public APIs | Lets the scanning service principal read report definitions | Report and page metadata isn't reachable at all | | Workspace role: Contributor or higher | Viewer sees the lineage view but not the underlying data sources | Lineage extraction returns nothing for that workspace | | Scanner API access: switched off on the connection | Report pages, visuals, and pipeline copy activities are only cataloged when this is off | The asset inventory completes normally; page and visual lineage is silently absent | | Fetch Report Definition Extracts: switched on | Required to parse the report definition for page- and visual-level mapping | Lineage stops at the semantic model | Each of these four settings is ordinary on its own; a tenant setting, a workspace role, a toggle, an extraction option. What makes lineage fail is that a cross-platform estate has to get all four right at the same time, on every connection, which is a governance discipline problem as much as a technical one. --- ## What's the difference between Power BI's native lineage view and a cross-platform lineage graph? Power BI's and Fabric's own lineage views are real and useful, but both are scoped to what happens inside the Microsoft estate, and a cross-platform graph has to pick up where they stop. According to [Microsoft Learn's Fabric governance documentation](https://learn.microsoft.com/en-us/fabric/governance/lineage), the native lineage view shows relationships between items inside one workspace, plus external sources one step upstream; it does not show downstream items sitting in other workspaces. Purview extends this picture but with its own documented boundary. [Purview's Unified Catalog](https://atlan.com/know/ai-agent/microsoft/purview-unified-catalog/) is the native starting point for that picture, and [Microsoft's Purview-Power BI lineage documentation](https://learn.microsoft.com/en-us/purview/data-map-lineage-power-bi) states that column-level lineage and transformation capture, except for Dataflows, is supported "when using Azure SQL Database as source," and that "other sources are currently not supported." [Purview's broader lineage model](https://learn.microsoft.com/en-us/purview/data-gov-classic-lineage) confirms the same source-type scoping applies generally, not just for Power BI. A cross-platform lineage graph extends the identical chain into Snowflake, Databricks, Google BigQuery, and Amazon Redshift, systems Purview's Power BI column lineage does not reach today. This is the coexistence idea at the center of the [semantic layer](https://atlan.com/know/semantic-layer/) conversation more broadly, and a close cousin of the question [Purview vs. Databricks Unity Catalog](https://atlan.com/know/purview-vs-databricks-unity-catalog/) asks from the other direction: Fabric and Purview cover the Microsoft-native leg of the estate thoroughly, and a cross-platform graph makes the same lineage survive the handoff to everything else, rather than replacing what Fabric and Purview already do well. Atlan's access to this graph is metadata-only, authenticated through Entra ID service principals or APIM managed identities, with a self-deployed runtime option that keeps credentials inside the customer's own environment, the same underlying principle behind [how to implement an enterprise context layer for AI](https://atlan.com/know/how-to-implement-enterprise-context-layer-for-ai/). For a partner-relationship view of how Purview and a cross-platform layer fit together, see [Microsoft Purview and Atlan](https://atlan.com/know/data-catalog/microsoft-purview-and-atlan/) and [Microsoft data governance tools](https://atlan.com/know/data-governance/microsoft-data-governance-tools/). | Aspect | Fabric/Power BI native lineage view | Cross-platform lineage graph | |---|---|---| | Upstream visibility | One step upstream from the workspace | Full chain back to the original source system | | Cross-workspace visibility | Not shown in the native lineage view | Shown across workspaces and platforms | | Column-level granularity | Native view is item-level, not column-level | Column- and measure-level via M and DAX parsing | | Non-Microsoft sources | Purview's column lineage: Azure SQL Database only | Extends to Snowflake, Databricks, BigQuery, and Redshift | | Permission model | Workspace roles: Viewer, Contributor, Admin | Entra ID service principals or APIM managed identities, metadata-only | Neither view is wrong. Each is scoped exactly to what it was built to govern, and the estate only gets full coverage when both layers run together. --- ## When do you need column-level lineage instead of report-level lineage? Report-level lineage tells you a dashboard exists and where it lives; column-level lineage tells you whether changing one upstream field will break it. Three situations make the difference concrete. Migration validation comes up whenever a source table moves, whether that is an on-premises database consolidating into a Fabric lakehouse or a warehouse migrating between clouds. Column-level lineage confirms the specific fields a report depends on resolved correctly after the move, not just that the connection string still works, a check worth running against Microsoft's own [Fabric use cases](https://atlan.com/microsoft-fabric-use-cases/) whenever a migration is in scope. Impact analysis matters before a schema change ships. Knowing which visuals reference a column that is about to be renamed, retyped, or dropped turns a predictable break into a planned one, the same discipline behind [automated SQL lineage vs. manual lineage mapping](https://atlan.com/know/ai-agent/data-for-ai/automated-sql-lineage-vs-manual-lineage-mapping/): tracing dependencies automatically catches what a manual review of report titles never will. Root-cause investigation is the case teams feel most directly, and it is the same workflow behind [data lineage root-cause analysis with MCP](https://atlan.com/know/mcp/data-lineage-rca-with-mcp/): when a KPI on a dashboard looks wrong, column-level lineage traces the display value through the semantic model's DAX measure and Power Query transformations back to the specific warehouse or lakehouse column behind it. One honest limit is worth stating here: mapping a visual's display label back to the exact underlying measure name is a separate, documented step that does not always resolve cleanly, so treat this as narrowing the search dramatically rather than guaranteeing a one-click answer. Across all three cases, the underlying demand is governed, cross-platform KPI traceability, not cataloging Fabric as an end in itself. Column-level lineage is also table stakes at the analyst level: [Gartner's Data Lineage research](https://atlan.com/gartner-data-lineage/) positions automated, column-level lineage capture as a baseline expectation for modern data platforms, and the [Forrester Wave for Enterprise Data Catalogs](https://atlan.com/forrester-enterprise-data-catalog-2024/) weights cross-platform lineage explicitly across the vendors it evaluates. As AI agents start reasoning over Power BI metrics directly, rather than a person reading a dashboard, the same lineage accuracy that resolves a broken number today is what will let an agent trust that number tomorrow. Before signing off on any lineage claim this specific, it is worth [proving it in a proof of value](https://atlan.com/know/data-catalog/microsoft/fabric-lineage-proof-of-value/) against your own Fabric estate rather than taking a vendor's word for it. --- ## How Atlan approaches column-level lineage for Power BI and Fabric Teams evaluating a Fabric or Power BI connection often default to the setup that requires the least coordination: enabling Scanner API access tenant-wide and skipping workspace-level permission requests. That path produces a complete inventory of workspaces, semantic models, and reports. It does not produce page- or visual-level lineage, and because the crawl still completes successfully, the gap is invisible until someone goes looking for a specific column and cannot find it. Atlan's Microsoft Fabric and Power BI connectors extract lineage across the full chain: from an external SQL source into a Fabric lakehouse or warehouse, through a semantic model parsed with a custom Power Query (M) and DAX reader, into a report, and, when the four prerequisites above are met, down to the page and visual. The same lineage graph extends to Snowflake, Databricks, Google BigQuery, and Amazon Redshift, so the chain does not stop at the Fabric boundary the way a Microsoft-native view does. Authentication runs through Entra ID service principals or APIM managed identities, and a self-deployed runtime option keeps credentials inside the customer's own environment. Access is metadata-only: Atlan reads table, column, and report structure, not the underlying business data itself. This same coexistence pattern shows up across the rest of the Fabric estate, not just lineage. [Fabric AI agent governance questions](https://atlan.com/know/microsoft-fabric/fabric-ai-agent-governance-questions/), [who governs agent-created Fabric items](https://atlan.com/know/microsoft-fabric/who-governs-agent-created-fabric-items/), the [Fabric database agent vs. data agent](https://atlan.com/know/microsoft-fabric/fabric-database-agent-vs-data-agent/) distinction, [Fabric IQ vs. Work IQ vs. Foundry IQ](https://atlan.com/know/microsoft-fabric/fabric-iq-vs-work-iq-vs-foundry-iq/), and [Fabric MCP servers](https://atlan.com/know/microsoft-fabric/fabric-mcp-servers/) all sit on the same underlying pattern: metadata that has to reach past a single workspace before it can be trusted. [OneLake's own catalog](https://atlan.com/know/microsoft-fabric/onelake-catalog/) and [Purview's AI agent controls](https://atlan.com/know/microsoft-fabric/purview-controls-for-ai-agents/) cover the native side of that pattern well; a cross-platform graph is what extends it. The result is governed, cross-platform KPI traceability: migration validation, pre-change impact analysis, and root-cause investigation that continue past the Fabric boundary instead of stopping there. Two limits are worth stating alongside the capability rather than around it. Mapping a visual's display label back to its exact underlying measure name is a separate, documented step that does not always resolve automatically, and lineage through Spark notebooks and shortcuts remains a private preview capability, not a generally available one. The honest claim is the most complete, most clearly documented path available today, not full coverage of every configuration, a distinction worth understanding through [what a context graph actually is](https://atlan.com/know/what-is-a-context-graph/) and how it compares to a [knowledge graph](https://atlan.com/know/context-graph-vs-knowledge-graph/) before assuming either one is complete by default. --- ## Column-level lineage is a configuration choice, not a ceiling Column-level lineage for Power BI is real, but it is the most complete, most clearly documented path available today, not full coverage of every configuration by default. Reaching it depends on getting several independent things right at once: which connector you use, whether Scanner API access is off or on, and which workspace role the scanning identity holds. The limits documented here are not Fabric or Purview falling short of what they were built to do; each is scoped precisely to its native boundary, by design, and a cross-platform estate needs a graph that survives the handoff past that boundary, not a bigger native view. That handoff is going to matter more, not less. As AI agents start reasoning over Power BI metrics directly instead of a person reading a dashboard, the same lineage accuracy that resolves a broken KPI today is what will let an agent trust that number tomorrow, which makes closing this gap a [context engineering](https://atlan.com/know/what-is-context-engineering/) problem as much as a governance one. Teams building toward that point often start from [what the enterprise context layer is](https://atlan.com/know/what-is-the-enterprise-context-layer/) or [how to build an AI agent harness](https://atlan.com/know/how-to-build-ai-agent-harness/) before they touch a specific connector at all. --- ## FAQs about Power BI column-level lineage ### 1. Does Power BI support column-level lineage natively? No. Power BI's and Fabric's native lineage views are workspace- and item-level, showing external sources one step upstream. Column-level detail requires either Microsoft Purview, limited to Azure SQL Database sources, or a third-party parser that reads Power Query and DAX expressions directly. ### 2. How do I see field-level lineage in Microsoft Fabric? Fabric's Scanner API surfaces what Microsoft calls subartifact metadata: table and column names, measures, DAX expressions, and M queries that the native lineage view does not show. A catalog that parses this output, or the M and DAX expressions directly, can reconstruct field-level relationships the item-level graph alone cannot. ### 3. Can I trace a Power BI measure back to its source SQL table? Yes, when the connecting tool parses the Power Query (M) and DAX expressions inside the semantic model. Standard, non-customized M expressions resolve cleanly; heavily customized or non-standard expressions are a documented parsing limitation across tools, not one vendor's gap alone. ### 4. What is the difference between workspace lineage and end-to-end lineage? Workspace lineage shows relationships between items inside one Fabric workspace, plus external sources one step upstream. End-to-end lineage traces the full chain, from the original source table through Fabric into the semantic model, report, page, and visual, often crossing multiple workspaces and platforms that workspace lineage alone doesn't show. ### 5. How does Microsoft Purview handle Power BI column lineage? Purview captures column-level lineage and transformations for Power BI, except Dataflows, but only when the upstream source is Azure SQL Database. Other source types are not currently supported for this specific capability, per Microsoft's own documentation. That is a stated product scope, not a defect. ### 6. Why does Microsoft Fabric lineage stop before it reaches Snowflake or Synapse? Fabric lineage stops before Snowflake or Synapse because of four independently documented mechanics, not one single limitation, and each is a designed boundary rather than an oversight. First, Fabric's own native lineage view is one hop by design. Per Microsoft Learn's Fabric governance documentation, the lineage view shows relationships between all items in a workspace, plus data sources external to the workspace one step upstream. It identifies that a connection to Snowflake or Synapse exists; it does not trace the transformation history inside those external engines, and it does not show downstream items sitting in other workspaces either. Second, Purview's column-level lineage is restricted by source type, and neither Snowflake nor Synapse is on the supported list for this specific capability. Per Microsoft's own Purview-Power BI lineage documentation, column-level lineage and transformation capture, except for Dataflows, is supported only when the source is Azure SQL Database. The full set of external source types Purview can link any lineage to at all is limited to Azure SQL Database, Azure Blob Storage, ADLS Gen1, and ADLS Gen2, a list that does not include Snowflake or Synapse as a generic external source. Third, Fabric sits as an intermediate semantic and compute layer, and the transformation logic that would bridge the remaining gap lives inside Power Query (M) expressions and DAX measures, not in the object-level relationship graph. A semantic model can show a connection to Snowflake at the object level while the actual column-to-column mapping is only recoverable by parsing those expressions directly, which is why a dedicated parser matters here. Connector choice compounds this. Per Microsoft Learn's documentation on Fabric and Power BI, Direct Lake lets Power BI query a Fabric lakehouse table directly without an extra connector hop, keeping the chain intact, while routing through a generic database connector or gateway can introduce an opaque hop instead. Reaching lineage even further, down to the report page or visual, has its own separate prerequisites: a specific Fabric tenant setting, Contributor-or-higher workspace access, and Scanner API access switched off, independent of whatever the ultimate source is. Fourth, and most directly, Purview's own Fabric integration explicitly excludes external-source and cross-workspace lineage for anything other than Power BI items, and its Synapse integration excludes query and stored-procedure activities along with resource-set column lineage. For Fabric lakehouses, warehouses, and pipelines, only item-level metadata can be scanned; sub-item lineage isn't supported even where sub-item metadata scanning exists in preview. On the Synapse side, runtime lineage capture excludes query and stored-procedure activities, a large share of real Synapse workloads, and column-level lineage isn't supported when the source or sink is a resource set. Per Microsoft's own Fabric-Purview and Synapse-Purview limitations documentation, these are the most direct, primary-sourced reasons the chain stops specifically at Snowflake or Synapse. None of this means Fabric or Purview handle lineage poorly. Both do exactly what they are documented to do within Microsoft's own estate; the gap shows up specifically at the seam where a cross-platform environment needs the chain to keep going. Closing it is exactly what the prerequisite checklist and the cross-platform lineage graph described above are for. | # | Reason | Mechanism | Source | |---|---|---|---| | 1 | Fabric's native view is one hop | Identifies external connections; doesn't trace inside them | Microsoft Learn, Fabric governance and lineage documentation | | 2 | Purview's column lineage is source-restricted | Azure SQL Database only; Snowflake and Synapse aren't supported for this capability | Microsoft Learn, Purview and Power BI lineage documentation | | 3 | Fabric is an intermediate semantic and compute layer | Transformation logic lives in M and DAX expressions, not the object graph; connector choice changes what's visible | Microsoft Learn, Fabric vs. Power BI documentation | | 4 | Purview's Fabric and Synapse integrations exclude key lineage types | No cross-workspace lineage for non-Power BI items; Synapse excludes query, stored-procedure, and resource-set lineage | Microsoft Learn, Fabric-Purview and Synapse-Purview limitations documentation | ### 7. What permissions does a service account need to see Power BI report-level lineage? A Viewer role can open the lineage view but cannot see the underlying data sources. Getting report-level lineage, and anything deeper, requires a workspace role of Contributor or higher for the scanning identity, plus the tenant-level setting that allows service principals to call Fabric's public APIs. ### 8. Should I use the Fabric connector or the Power BI connector to get lineage? They surface different asset sets. The Fabric connector catalogs workspaces, lakehouses, warehouses, and pipelines; the Power BI connector focuses on semantic models, reports, and Power-Query-derived column lineage. Using only one when an estate needs both is a common reason a connection returns a few reports and no lineage at all. --- ## Sources 1. [Lineage in Fabric, Microsoft Learn](https://learn.microsoft.com/en-us/fabric/governance/lineage) 2. [Metadata and lineage from Power BI into Microsoft Purview, Microsoft Learn](https://learn.microsoft.com/en-us/purview/data-map-lineage-power-bi) 3. [Metadata scanning overview, Microsoft Fabric, Microsoft Learn](https://learn.microsoft.com/en-us/fabric/governance/metadata-scanning-overview) 4. [Roles in workspaces in Power BI, Microsoft Learn](https://learn.microsoft.com/en-us/power-bi/collaborate-share/service-roles-new-workspaces) 5. [Direct Lake overview, Microsoft Learn](https://learn.microsoft.com/en-us/fabric/fundamentals/direct-lake-overview) 6. [Data gov classic lineage, Microsoft Learn](https://learn.microsoft.com/en-us/purview/data-gov-classic-lineage) 7. [Metadata and Lineage from Fabric into Microsoft Purview, Microsoft Learn](https://learn.microsoft.com/en-us/purview/data-map-lineage-fabric) 8. [Metadata and lineage from Azure Synapse Analytics into Microsoft Purview, Microsoft Learn](https://learn.microsoft.com/en-us/purview/data-map-lineage-azure-synapse-analytics) 9. [What does Atlan crawl from Microsoft Fabric?, docs.atlan.com](https://docs.atlan.com/apps/connectors/business-intelligence/microsoft-fabric/references/what-does-atlan-crawl-from-microsoft-fabric) 10. [What lineage does Atlan extract from Microsoft Fabric?, docs.atlan.com](https://docs.atlan.com/apps/connectors/business-intelligence/microsoft-fabric/references/what-lineage-does-atlan-extract-from-microsoft-fabric) 11. [What lineage does Atlan extract from Microsoft Power BI?, docs.atlan.com](https://docs.atlan.com/apps/connectors/business-intelligence/microsoft-power-bi/references/what-lineage-does-atlan-extract-from-microsoft-power-bi) 12. [Microsoft Fabric connector overview, docs.atlan.com](https://docs.atlan.com/apps/connectors/business-intelligence/microsoft-fabric) 13. [Configure Power BI tenant settings, docs.atlan.com](https://docs.atlan.com/apps/connectors/business-intelligence/microsoft-power-bi/how-tos/configure-power-bi-tenant-settings) 14. [Reddit r/MicrosoftFabric: "What is everyone using for Data Lineage"](https://www.reddit.com/r/MicrosoftFabric/comments/1m99b6v/what_is_everyone_using_for_data_lineage/) 15. [Reddit r/MicrosoftFabric: "Import Mode in Fabric: How do you track lineage & document semantic models?"](https://www.reddit.com/r/MicrosoftFabric/comments/1n9ub15/import_mode_in_fabric_how_do_you_track_lineage/) 16. [Gartner Data Lineage: Research, Trends & Tools for 2026, Atlan](https://atlan.com/gartner-data-lineage/) 17. [The Forrester Wave: Enterprise Data Catalogs, Q3 2024, Atlan](https://atlan.com/forrester-enterprise-data-catalog-2024/)