Proving Fabric and Power BI lineage in a proof of value means testing five distinct lineage hops, source table, lakehouse or warehouse, semantic model, report, and page or visual, against a reference lineage graph you define before the trial starts, not the vendor’s demo data. Most PoV disappointments trace to one of three pre-PoV decisions: Scanner API Access mode, the Fabric-versus-Power-BI connector choice, and workspace permission level. This guide gives you the checklist, the test matrix, and a diagnostic framework for every gap you find.
No neutral, vendor-agnostic test plan for a Fabric and Power BI lineage proof of value exists today. Microsoft’s own documentation is exhaustive on the mechanics, exact toggles, exact permission levels, exact tenant settings, but none of it is framed as a buyer’s checklist. This guide is written for whoever actually runs the trial day to day, not just the person who signs off on it afterward.
| Field | Value |
|---|---|
| Category | Fabric and Power BI lineage validation, part of a broader data catalog or governance platform evaluation |
| Guide type | Proof-of-value test plan, run after shortlisting, before signature |
| Typical PoV timeline | 2-4 weeks, add 1-2 weeks if Entra ID or APIM auth setup starts from zero |
| Key stakeholders | Data governance or platform lead, AI and analytics engineering lead, Fabric or Power BI workspace admin |
| Budget range | Out of scope here, see the vendor and contract questions in the companion evaluation-questions guide |
| Core test criteria | Connector choice, Scanner API mode, workspace permission level, lineage completeness by hop, configuration-versus-limitation diagnosis |
- Most PoV disappointments are decided before the first crawl runs, by three configuration choices.
- Test lineage by hop, against a reference graph you define, not the vendor’s demo.
- Every gap gets a diagnosis: a knob nobody turned, or a documented, vendor-wide limitation.
Why a Fabric and Power BI lineage PoV needs a formal test plan
A proof of value only proves what you deliberately test, and an untested lineage claim is not a validated one. That distinction is easy to state and easy to skip once a trial is underway and the pressure is to get to a decision.
No neutral, vendor-agnostic PoV test plan for Fabric or Power BI lineage exists on the open web today. Microsoft’s own documentation is exhaustive on mechanics, permissions, and tenant toggles, but it is not written as an evaluator’s checklist, and a structured, vendor-neutral evaluation checklist already exists in the adjacent data observability category. According to the Data Observability Buyer’s Checklist (DQLabs, 2026), evaluators should confirm whether lineage extends “from source systems through transformation layers (dbt, Spark) all the way to BI tools” and whether it is available at the column level, not just the table level. That is the right shape of question. It has simply never been applied specifically to Fabric and Power BI lineage, until now.
The cost of skipping a formal plan shows up as a specific, recurring pattern rather than a vague sense that “lineage didn’t work.” In one proof of value, lineage results looked incomplete because the trial ran a Fabric connector where Power BI-specific report depth was the actual requirement, and the team briefly concluded the product had failed when the setup was wrong. That pattern, a PoV that watches the demo instead of running a deliberate test, cannot tell a real limitation from a misconfigured toggle, which is one of the most frequently repeated failure modes in PoV retrospectives, though not the only one, as the diagnostic section further down makes clear.
The person running the trial day to day, often a Fabric or Power BI admin or a data engineer, benefits most from a structured plan, but the plan works best when the whole buying committee aligns on it before the trial starts rather than after the results come back ambiguous. That alignment matters more in a Microsoft-first estate specifically, because Microsoft Fabric governance already splits the work: Fabric runs the workloads, Microsoft Purview enforces Microsoft-native policy, and this PoV exists to prove the cross-platform lineage layer that sits alongside both, not to argue that either one should be replaced. A PoV that treats the trial as a formality instead of a test plan is the fastest way to end up unable to tell a genuine cross-platform gap from a setting nobody checked.
What should you configure before a Fabric lineage proof of value even starts?
Most PoV disappointments are decided by three configuration choices made before a single crawl runs, not by a limitation in the tool being tested. Nine decisions belong on a pre-trial checklist, and getting even one wrong can make an otherwise capable platform look incomplete.
| Configuration decision | Why it decides PoV success | What to verify before the trial starts |
|---|---|---|
| Connector choice: Fabric vs. Power BI | Each surfaces a different lineage depth; running the wrong one for your primary requirement is a frequently repeated PoV failure pattern | Confirm which connector matches the trial’s primary requirement, or plan to run both (see the next section) |
| Scanner API Access mode | Enabled needs no workspace permission but blocks report pages, visuals, and lineage into them; disabled needs permissions but unlocks that full coverage | Confirm which mode the tenant runs before the crawl starts |
| Workspace permission level | Viewer-or-higher unlocks report, page, and visual lineage through the Fabric connector once Scanner API is disabled; column- and measure-to-page lineage through the Power BI connector is a separate, deeper mechanism that needs Contributor-or-higher instead, since Viewer produces nothing there | Confirm the crawling identity holds at least Viewer on every in-scope workspace, and Contributor-or-higher specifically if column- or measure-to-page lineage via the Power BI connector is in scope |
| “Service principals can call Fabric public APIs” tenant setting | Column- and measure-to-page lineage through the Power BI connector depends on this being enabled for the security group in scope; general report, page, and visual lineage through the Fabric connector does not need it | Confirm it is enabled in the Fabric admin portal for the relevant group if that deeper lineage is in scope |
| “Fetch Report Definition Extracts” setting | On by default, but column- and measure-to-page lineage through the Power BI connector silently disappears if it has been turned off | Verify it has not been disabled, do not assume the default held |
| Entra ID service principal or APIM managed identity setup | Both need Cloud or Application Administrator plus Fabric Administrator to configure; a half-finished setup produces partial results that look like product gaps | Confirm the identity is registered, added to the right Entra security group, and assigned to every in-scope workspace |
| Source-system connector crawl status (Snowflake, Synapse, Databricks) | Cross-platform lineage into Fabric only resolves when the upstream source is separately crawled with matching identifiers | Confirm the relevant source connector is already crawled before testing the cross-platform hop |
| Representative report and workspace set | A trial that tests one simple report proves little; the set has to include the lineage patterns the estate actually uses | Choose reports that include shortcuts, semantic model measures, and at least one cross-platform source |
| Reference lineage graph defined in advance | Without one, “the tool didn’t find it” and “we didn’t test for it” look identical afterward | Document the graph before the trial starts, not during it |
The most consequential lines in that table are the two permission rows, and they answer two different questions. General report, page, and visual lineage through the Fabric connector needs only Scanner API disabled and Viewer-or-higher on the workspace; nothing in that path requires Contributor access or either tenant setting. Column- and measure-level lineage traced to a specific report page is a separate, deeper mechanism, read through the Power BI connector’s report-definition API, and it needs Contributor-or-higher permission plus the public-API tenant setting and the extract setting together, because Viewer access alone produces nothing there. Miss the right piece of whichever mechanism is in scope and the crawl can complete successfully while that lineage stays empty. Microsoft’s own lineage documentation shows the same role-gating pattern inside Fabric’s native lineage view: “users with the Viewer role won’t see data sources,” even though a Viewer can still see the relationships between items in a workspace. That’s a different feature from the connector’s own report-page and visual coverage, but the pattern, a role boundary that quietly narrows what lineage shows rather than failing the request outright, is exactly what this checklist exists to catch. It lines up with Microsoft Learn on Fabric workspace roles (Microsoft Learn, 2026), which draws the same boundary for write-capable API calls generally: Admin, Member, and Contributor can perform operations, such as notebook CRUD via the Items REST API, that Viewer cannot, the same class of boundary a report-definition read sits behind.
Run this checklist before the trial starts, not during it, and a successful crawl stops being confused with complete lineage. The three decisions at the top of this table, connector choice, Scanner API mode, and permission level, often decide more of a PoV’s outcome than anything a vendor demonstrates once the trial is underway. The same discipline, test with your own data against your own criteria rather than trust the demo, is what separates a real evaluation from a sales call, and it is the identical standard work reviewing the best AI agent evaluation platforms applies when the thing being tested is an agent’s output rather than a lineage graph.
Fabric connector or Power BI connector: which one should you run in the PoV?
The Fabric and Power BI connectors are a real, substantive choice for a PoV, not a formality, and running the wrong one is one of the most frequently repeated failure patterns in PoV retrospectives. Existing market coverage frames Fabric as the “backbone” and Power BI as the “visualization layer,” which is directionally right and specific about almost nothing a PoV actually needs to know.
The Fabric connector is the right choice when Fabric-native assets, lakehouses, warehouses, pipelines, dataflows, and semantic models, and their upstream lineage matter most to the trial. It can also expose Fabric-hosted Power BI artifacts, but how deep that goes depends heavily on the API mode and permissions covered in the checklist above. The Power BI connector is the right choice when comprehensive Power BI metadata and report lineage, datasets, tables, columns, measures, reports, dashboards, pages, and downstream page lineage, is the primary requirement. Microsoft’s own registration guidance for Purview notes that scanning Fabric tenants registered with the Fabric data source has captured metadata and lineage from Fabric items including Power BI since December 2023, but that describes Purview’s own scan-type collapse, not a guarantee every third-party catalog’s two connectors behave identically. Treat them as functionally distinct until a specific vendor’s documentation says otherwise.
For a PoV specifically, the more reliable approach is to run both connectors in parallel against the same representative report set and score coverage parity, rather than guessing up front which one matches the primary requirement. That comparison is also the fastest way to surface the gap existing market content leaves open: which specific lineage edges each connector choice enables or blocks, not just which one is described as the “backbone.”
Naming the connector choice honestly, the way Microsoft names its own toggles rather than softening it into a footnote, is what separates a PoV that produces a defensible recommendation from one that produces a coin flip dressed up as a technical evaluation. The connector decision belongs in the pre-trial checklist above precisely because it is the decision most PoVs get to accidentally rather than deliberately.
How do you test Fabric and Power BI lineage across every hop, from source table to visual?
Test lineage hop by hop against a reference graph defined in advance. Watching the vendor’s demo dataset is not a test. Borrowing the discipline that Forrester and Gartner apply to broader enterprise catalog evaluations, define your own reference lineage graph and test scenarios before the trial starts rather than letting the vendor choose what gets demonstrated. The mechanics of how column-level lineage runs end to end from a source table to a Power BI visual are covered in full on the companion page; the matrix below is the test plan for proving those same mechanics hold on a live estate rather than re-explaining how they work.
| Lineage hop | What you’re testing | Pass signal | If it’s missing, check first |
|---|---|---|---|
| External source to Fabric lakehouse or warehouse table | Whether the source connector’s tables resolve into Fabric with matching identifiers | The lakehouse or warehouse table shows the external table as an upstream node | The source connector’s crawl status and identifier matching |
| Lakehouse or warehouse table to semantic model table/column | Whether column-level structure survives into the semantic model | Semantic model columns map back to source columns, not just table-level | Scanner API mode and workspace permission |
| Semantic model measure/DAX to report | Whether a calculated measure’s dependencies are traceable | The report shows which measures it consumes and what those measures reference | Whether the connector catalogs measures and DAX dependencies at all |
| Report to report page/visual | Whether lineage reaches the actual visual a business user looks at | Individual pages and visuals appear as lineage nodes, not just the report as a whole | Scanner API mode and workspace permission (Viewer-or-higher); for column- or measure-level lineage onto that page specifically, check Contributor permission and the two tenant settings instead |
| Fabric to cross-platform downstream (Snowflake/Synapse/Databricks) | Whether lineage survives the handoff out of the Microsoft estate | A downstream table in the non-Microsoft platform shows Fabric as an upstream source | Whether that platform’s own connector is crawled and its identifiers match |
| OneLake shortcuts | Whether a shortcut resolves to a real lineage edge | Registered Tables/* targets inside the crawl scope show lineage |
The shortcut’s target type before concluding it’s a gap |
| Spark notebook or pipeline transformation | Whether notebook and pipeline logic produces table or column lineage | Lineage into and out of the notebook step appears without manual annotation | Whether an optional Spark runtime-lineage path is configured |
Two of these rows deserve an honest caveat rather than a vendor’s optimistic gloss, because the underlying limitation is documented and industry-wide, not specific to Fabric or to any one catalog. Microsoft’s own OneLake shortcuts documentation states plainly that “lineage for shortcuts to warehouses and semantic models isn’t currently available.” In practice, that leaves shortcut lineage most reliable for shortcuts pointing at registered Tables/* targets inside the crawl scope; file-based and external shortcut targets, ADLS Gen2, S3, GCS, external data shares, are the ones worth testing explicitly in the PoV rather than assuming they behave the same way. Spark notebook lineage carries the same kind of caveat: an optional runtime-lineage path exists for capturing table and column lineage from notebooks and Spark jobs, but it is not on by default, and it needs its own workspace permissions to configure.
Testing every hop this way, instead of accepting a demo that only shows the easy path, is what turns “lineage worked” from a single yes-or-no verdict into a scored, hop-by-hop result the buying committee can actually act on. That discipline is also the honest version of the cross-platform coexistence story a Microsoft-first estate is really testing: not whether one platform’s lineage is good, but whether it survives the handoff between platforms, which is where lineage actually tends to break. Data lineage for AI work in general treats that handoff as the hard part rather than any single hop, and an automated, SQL-driven lineage approach is what makes hop-by-hop testing practical instead of a manual mapping exercise. The same discipline extends to Power BI’s own semantic models, where measure and DAX dependencies are worth testing directly rather than assumed, and to the broader question of what a dedicated semantic layer adds beyond a Power BI semantic model once lineage reaches that layer. Whether a semantic layer actually has lineage underneath its definitions, rather than definitions alone, is the same distinction that separates a semantic layer from a data catalog on any platform, not just Fabric. Where the reference graph reaches into Snowflake, the same hop-by-hop standard applies without exception, cross-platform lineage that only gets tested inside Microsoft’s own boundary was never really tested at all.
A lineage gap turned up in your PoV: is it a configuration miss or a real limitation?
Every lineage gap found during a PoV has one of two causes, and telling them apart is the core skill of running a rigorous PoV: is this a knob nobody turned, or a wall every vendor hits? Checking configuration first is not the same claim as assuming every gap is a configuration problem. The table below orders the check that way because it is the cheaper one to rule out, not because genuine limitations are rare; the paragraphs after it name a real one.
| Symptom | Likely configuration cause (check first) | Likely genuine limitation (documented, not a config fix) |
|---|---|---|
| No page or visual lineage at all | Scanner API mode and workspace permission, the two most commonly missed toggles: Viewer-or-higher for the Fabric connector, Contributor-or-higher if the missing lineage is specifically column- or measure-to-page via Power BI | Rare once the right permission for the mechanism being tested is corrected; if it’s already right, treat it as a candidate genuine gap rather than assume a missed toggle |
| Semantic model lineage present but reports are missing | Connector choice, confirm Fabric vs. Power BI matches the requirement | Usually a configuration question rather than a limitation, confirm before concluding otherwise |
| OneLake shortcut lineage missing | Confirm the shortcut points at a registered Tables/* asset inside scope |
File-based or external shortcut targets are a documented Microsoft limitation |
| Spark notebook lineage missing | Confirm whether the optional Spark runtime-lineage path was configured | Without it, this is a genuine gap, not a bug, off by default across the market |
| Upstream Databricks or Snowflake lineage missing | Check for parameterized M-queries or a storage path used instead of a registered table | Path-based references are a documented, cross-vendor limitation |
| Mirrored-database or stored-procedure warehouse lineage stopping early | Confirm this isn’t being mistaken for a permission issue | A known connector-scope limitation today, not something a permission change fixes |
The path-based limitation in that table is worth naming precisely, because it is easy to mistake for a Fabric-specific or vendor-specific weakness when it is neither. Microsoft’s own Unity Catalog documentation states it directly: “column lineage cannot be captured if the source or the target is referenced as path,” and is “supported only when both the source and target are referenced by table name,” per Lineage in Unity Catalog, Microsoft Learn. Interworks’ independent analysis of the same Unity Catalog behavior (Interworks, 2026) reaches the identical conclusion: “lineage breaks when data is referenced by a cloud storage path instead of a registered table name,” for example reading a raw storage path instead of a named table. OpenLineage’s own project material shows a comparable gap on the Spark side, though a narrower one: OpenLineage’s column-level lineage documentation builds lineage by traversing Spark’s logical plan, and the project’s own writeup on the current state of column-level lineage acknowledges the gap directly, noting that its column-lineage collectors “work mainly for Spark SQL operations and Data Source V2,” which “leaves out normal dataframe operations like inserting into HDFS without the use of a Hive table,” regardless of which catalog is reading the output.
That industry-wide evidence matters for how a PoV should read its own findings. One internal example worth naming honestly: a Fabric-and-Databricks estate where missing upstream lineage traced to a parameterized M-query pattern that was not being resolved, a genuine, documented product-side gap rather than a configuration miss. The lesson is not that every gap dissolves into a configuration fix, and it is also not that lineage never really works. It is that a rigorous PoV holds both truths at once: most gaps in these PoV retrospectives traced to a connector or permission choice, and at least one traced to a real, since-logged limitation. A PoV’s actual deliverable is a scored, categorized gap list the buying committee can act on, not a single “lineage worked or it didn’t” verdict, which is the discipline that separates root-cause analysis of a lineage gap from a vague complaint that a demo looked incomplete. The same “is this a knob or a wall” question extends past this table too. OpenLineage support inside a catalog like DataHub runs into the identical Spark-scope boundary, and an Airflow-plus-OpenLineage pipeline built for AI workloads hits the same wall for the same documented reason, evidence this is a market-wide limitation rather than a single platform’s failure.
Common mistakes that sink a Fabric lineage proof of value
The same three mistakes show up across PoV retrospectives, pattern-matched from internal case evidence and independently corroborated by community signal, not any one vendor’s claim.
The first and clearest mistake is running the Fabric connector when Power BI-specific report-lineage depth was the actual requirement, or the reverse, and concluding the product failed when the setup was wrong. This connector-choice pattern recurs more than any other single mistake in PoV retrospectives, and it is entirely avoidable with the connector test described earlier. The second is treating a successfully completed crawl as proof that lineage is complete, when page and visual lineage has its own separate, stricter permission and setting requirements. A green checkmark on the crawl status is not the same claim as “lineage reaches the visual,” and conflating the two is how a working configuration gets mistaken for a broken product. The third is starting the trial with no reference lineage graph defined in advance, so the PoV has no way to distinguish “the tool didn’t find it” from “we didn’t test for it,” which turns every ambiguous result into a debate instead of a scored finding.
Community and social-listening signal corroborates the same pattern without needing named sources to make the point. Recurring practitioner threads describe multi-week PoC delays traced to service-principal permissions and Scanner API or Purview scanning setup friction, with a recurring retrospective finding that “it was just a configuration problem.” That fatigue toward vendor PoCs whose failures later traced to misconfigured auth or scan rules, rather than a genuine product limit, is consistent with the internal case-pattern evidence described above, even where the individual threads themselves cannot be independently pinned down to a specific source. Building the pre-PoV checklist, the connector test, and the reference lineage graph into the trial plan from day one closes off all three mistakes before they can happen, which is a cheaper fix than discovering them in a retrospective.
How Atlan approaches Fabric and Power BI lineage in a proof of value
Most PoVs test a single platform’s lineage in isolation. The real question in a Microsoft-first estate is whether lineage survives the handoff between platforms, since that handoff, not any one tool working alone, is exactly where it tends to break.
Atlan catalogs Fabric workspaces, lakehouses and warehouses, semantic models, reports, dashboards, report pages and visuals, dataflows, and pipeline copy activities, and extends the same lineage graph into Snowflake, Databricks, BigQuery, Redshift, and other non-Microsoft systems that Purview does not reach, serving all of it to any agent over MCP rather than only to a human reviewing a lineage view. That cross-platform reach is the specific claim the checklist and test matrix above exist to help a reader verify directly, not just take on faith, and it is the same posture documented for the context layer for Databricks and its Genie ontology, and for Snowflake Horizon context, each a version of this same Fabric-and-Purview coexistence story on a different estate. Authentication runs through an Entra ID service principal or an APIM managed identity, both requiring Cloud or Application Administrator plus Fabric Administrator privileges to set up, and a self-deployed runtime option keeps credentials inside the customer’s own perimeter. Access stays metadata-only throughout: Atlan reads metadata, not the underlying business data, the same boundary Microsoft draws around Purview’s own governance objects.
Atlan’s own known limitations belong here, stated as plainly as Microsoft states its. Mirrored databases are not currently cataloged. Stored-procedure warehouse lineage inside Fabric warehouses does not carry the same query-history depth as a dedicated Synapse connector, so table-to-table lineage inside those designs can stop at the final table. And Atlan does not currently push access or role changes back into Fabric, Power BI, or Purview: it reads metadata and can route an approval decision to an external system such as Jira, ServiceNow, or a webhook, but the source-system access change itself still runs through Microsoft’s own controls or that external workflow. None of that is a reason to skip the connector-parity test or the diagnostic table above. It is the reason to run them.
Running this same checklist, connector test, and diagnostic framework against a live Fabric estate is the most direct way to see where a cross-platform enterprise context layer actually holds up.
A rigorous PoV outlasts any single vendor’s lineage claim
A PoV only proves what you deliberately test. Three configuration decisions, connector choice, Scanner API mode, and workspace permission level, decide most outcomes before the trial ever starts, which is why they belong on a checklist run before the first crawl rather than discovered during a retrospective. Test lineage hop by hop against a reference graph you define yourself, not the vendor’s demo data, and diagnose every gap that turns up instead of logging it as an undifferentiated “lineage didn’t work.”
This same rigor applies to any cross-platform lineage claim, Atlan’s included. The test plan matters more than any single vendor’s marketing, which is also why the questions above read the same regardless of which platform sits on the other side of the trial. A reader who has worked through the checklist, the connector test, and the diagnostic table is ready for a different kind of question than “did lineage work”: which specific hop, under which specific configuration, produced which specific result, and what happens to that answer once the trial reaches context engineering at scale rather than a single pilot.
That question matters beyond this one PoV, too. AI-ready data is not simply cataloged data, and AI-ready data lineage is one of the harder pillars to prove, since an agent grounded on a broken lineage graph answers confidently and wrong rather than refusing to answer at all. That is why the role of metadata management in enterprise AI keeps surfacing in AI readiness platform evaluation work well beyond Fabric and Power BI, and why the same context layer evaluation criteria that apply to a full platform decision apply, at smaller scale, to a single PoV. The distinction between a data catalog and a context layer is the same one this PoV draws in miniature: proving catalog-style discovery is not the same claim as proving the lineage an agent actually needs. The same evidentiary bar is also the argument for why AI agents need an enterprise context layer in the first place, and for treating a metadata tooling build-versus-buy decision with the same rigor as this PoV, rather than a vendor’s slide.
Once the checklist and test matrix here produce a scored result, the natural next step is working through the 20 evaluation questions in the companion buyer’s guide before the vendor conversation moves to contract terms, or reading how to implement an enterprise context layer for AI for what the rollout looks like once the PoV is behind you. Running this same checklist against a live Fabric estate, with Atlan or with any other vendor, is the most direct way to see whether a cross-platform lineage claim actually holds up; book time with Atlan to scope what that trial would look like on your own estate.
FAQs about testing Fabric and Power BI lineage in a proof of value
1. How do you validate that Fabric lineage is actually complete, not just present?
Test lineage hop by hop against a reference graph you define in advance: source table, lakehouse or warehouse, semantic model, report, and page or visual. A completed crawl is not evidence of complete lineage, since page and visual-level lineage carries its own stricter permission and setting requirements. Score each hop against the test matrix rather than accepting a single pass-or-fail verdict.
2. What permissions does a service principal or managed identity need to see report-page and visual lineage?
It depends which lineage. General report, page, and visual lineage through the Fabric connector needs Scanner API Access disabled and Viewer-or-higher on every in-scope workspace, nothing more. Column- and measure-level lineage traced to a specific report page is a separate, deeper mechanism read through the Power BI connector, and it needs Contributor-or-higher instead, plus two tenant settings: “Service principals can call Fabric public APIs” enabled for the relevant security group, and “Fetch Report Definition Extracts” left on. Viewer access produces nothing for that deeper mechanism, since Microsoft’s own report-definition API requires write permission on the report.
3. How long should a Fabric and Power BI lineage proof of value take?
Two to four weeks is typical, in line with general proof-of-concept duration norms, and add one to two weeks if Entra ID or APIM authentication setup is starting from zero. A PoV that drags well past four weeks is usually stuck on an auth or permission configuration issue rather than a genuine capability question.
4. What is the Power BI Scanner API, and how is it different from ordinary workspace access?
The Scanner API is a metadata-extraction mode that pulls Power BI and Fabric metadata without needing individual workspace permissions, trading that convenience for coverage: it cannot catalog report pages, visuals, or the lineage into them. Ordinary workspace access, Viewer-or-higher permission on each in-scope workspace, unlocks that coverage through the Fabric connector; column- and measure-to-page lineage through the Power BI connector needs Contributor-or-higher specifically, since Viewer produces nothing there.
5. Does using the Fabric connector give the same lineage as the Power BI connector?
No. The Fabric connector is strongest on Fabric-native assets and their upstream lineage, lakehouses, warehouses, pipelines, and dataflows, while the Power BI connector is strongest on comprehensive Power BI report lineage, including pages and downstream dependencies. For a PoV, run both against the same representative report set and score coverage parity rather than assuming either one covers the other.
6. Does Microsoft Purview support Fabric lineage out of the box, and does that remove the need for a separate PoV?
Yes, for lineage inside the Microsoft boundary: Purview’s Fabric and Power BI scanning has captured metadata and lineage from Fabric items, including Power BI, since December 2023. It does not remove the need for this PoV, since Purview’s scope stops at what Microsoft observes and enforces. A separate trial is what proves whether a cross-platform layer extends that lineage into Snowflake, Synapse, or Databricks as well.
7. Why does lineage stop at Fabric and never reach Snowflake or Synapse?
In short, a cross-platform hop only resolves when the upstream source connector is separately crawled and its identifiers match what Fabric exposes; skip that crawl and the chain stops at the Fabric boundary regardless of how the Fabric side is configured. The full mechanics of why this happens, and how to test for it directly, are covered in the companion guide on end-to-end column-level lineage for Power BI.
Sources
- Lineage in Fabric, Microsoft Learn
- Roles in workspaces in Microsoft Fabric, Microsoft Learn
- Connect to and manage a Power BI tenant in Microsoft Purview, Microsoft Learn
- Unify data sources with OneLake shortcuts, Microsoft Learn
- Lineage in Unity Catalog, Microsoft Learn
- Understanding Databricks governance with Unity Catalog, layer by layer, Interworks
- Column-level lineage, OpenLineage docs
- The current state of column-level lineage, OpenLineage project blog
- Data observability buyer’s checklist: 50 questions every evaluator should ask, DQLabs
