Most data-lineage tools are strongest where the work is governed, centralized, and platform-visible: warehouse tables, SQL transformations, dbt models, semantic layers, and dashboards connected to known sources. Inside that world, they can be genuinely useful.
But a lot of analytical work still happens outside that clean boundary.
It happens in Excel, in Alteryx, in local Python notebooks, in exported files, in one-off models, and in workflows that move between desktop tools, cloud warehouses, and BI platforms. That layer is where lineage often goes dark.
MyDataWork is built to light up that working layer — and connect it back to the warehouse, cloud sources, BI tools, and use cases where the same work resurfaces.
How it works: inference from metadata, not manual mapping
You do not have to draw MyDataWork’s lineage by hand. It is inferred from metadata and structural signals.
When an asset is cataloged — whether through the local Connector or a cloud source — MyDataWork performs structural metadata extraction. It looks for the signals that reveal dependencies: table names from SQL FROM and JOIN clauses, input and output tables from Alteryx workflows, sources from dbt, catalog metadata from cloud warehouses (Snowflake, BigQuery, Redshift, and Databricks), the source tables that BI assets in Power BI, Tableau, Sigma, Looker, and ThoughtSpot read from, the files that workflows and notebooks reference.
Those sources can be connected directly in Setup — data warehouses (Snowflake, BigQuery, Redshift, Databricks), repositories (GitHub, dbt Cloud), the BI and analytics tools themselves (Power BI, Tableau, Sigma, Looker, ThoughtSpot), and Dataiku — or picked up as local files by the Windows Connector. Connecting a BI tool directly catalogs its own dashboards, workbooks, and datasets, plus the source tables they read — not only the warehouse tables they sit on top of.
Crucially, this is structure only. MyDataWork does not store business data values, cell contents, formula contents, table rows, or query results. Where source content must be parsed to extract structure, the parse happens for that purpose and only the resulting metadata is retained.
From those references, MyDataWork connects assets in practical ways.
- By shared warehouse-table reference. When two assets reference the same schema-qualified table, that is strong evidence they are connected through the same source. These edges are shown as Confirmed.
- By file or unqualified-name match. For local files and less formal references, MyDataWork can match on filenames or bare table names. Filename matches are shown as Likely; unqualified table-name matches are shown as Possible.
The Lineage tab: the network-optimization workflow and the assets it connects to,
each edge labeled with its confidence tier (Confirmed / Likely / Possible) and a plain-language evidence string
Every edge carries a confidence tier — Confirmed, Likely, or Possible — and a plain-language evidence string that says why the connection was inferred. (You can also confirm or add an edge by hand; a manual edge is treated as Confirmed.)
You are not asked to take the graph on faith. You can read the reasoning behind each line.
Why it works that way
Two design choices are doing the work here, and both come from the same principle: be honest about what metadata can and cannot prove.
Metadata-only, by design. Because MyDataWork does not store business data values, lineage is inferred from structure: table references, filenames, source paths, sheet names, column headers, join keys, and similar signals. That is a deliberate boundary. It lets the product map a practitioner’s real working environment, including local files and cloud assets, without turning MyDataWork into another place where sensitive data has to live.
The result is not a row-level or value-level trace. It is a practical map of how analytical work connects.
Confidence tiers instead of false certainty. Inference across a messy, multi-tool environment is not uniformly certain. A schema-qualified table shared between two assets is strong evidence. A filename match between two local files is useful, but weaker. An unqualified table name may be suggestive, but still needs judgment.
Tools that flatten that distinction either over-claim by presenting every guess as fact, or under-deliver by refusing to connect anything they cannot prove completely. MyDataWork takes a different approach. It shows the connection, shows the confidence, and shows the evidence.
That means you can trust the Confirmed edges, review the Likely ones, and use judgment on the Possible ones.
An example
Consider a network-optimization workflow that references a customer-demand spreadsheet, a starting-inventory spreadsheet, and a distribution-center spreadsheet, then writes or depends on a results file.
Lineage also surfaces on each asset’s own detail view.
On their own, those files do not explain their relationship to each other. The spreadsheet does not know that it feeds the workflow. The workflow does not explain the business decision it supports. The results file does not announce that a downstream dashboard, analyst, or stakeholder depends on it.
Cataloged in MyDataWork, the lineage becomes visible. Because the workflow references those spreadsheets by name, each one is matched to the catalogued file and linked into the graph, with confidence and evidence attached to every inferred edge. The input files, workflow, output, and external dependency can appear together in one picture.
That graph is useful on its own. But its real payoff shows up when other parts of the product use it.
The Workspace Agent can flag work that has become stale, unsupported, or disconnected from a stakeholder.
The Asset Estate Assessment can read lineage edges and use cases together, then surface structural patterns a single asset view would miss.
For example:
- Two spreadsheets feed two different use cases — a consolidation opportunity, and a reason to coordinate before anyone changes them.
- A workflow is referenced by multiple use cases — a signal to coordinate changes so one edit does not quietly break another team’s work.
- External dependencies appear in the graph but are not owned inside the workspace — a change-management risk worth confirming upstream.
- A high-value use case depends on assets that have not been updated recently — a signal that the business outcome may be losing momentum.
Uncatalogued dependencies show as dimmed ‘Not in catalog’ ghost nodes — here netop_output.yxdb, the workflow’s output, flagged as an untracked external dependency.
The lineage graph is not decoration. It is the structural substrate that lets the rest of MyDataWork reason about how the work actually hangs together.
How it differs — and why that adds value
Two approaches dominate most lineage conversations, and MyDataWork is deliberately focused on the gap between them.
The first is platform-native or warehouse-centered lineage. It can be excellent inside a governed environment, especially for SQL, dbt, warehouse views, and column-level transformations. But it often has limited visibility into the analyst’s working layer: local files, exported spreadsheets, desktop workflows, notebooks, and models that sit outside the governed platform even though they may be critical to the business.
The second is manual documentation. It can be accurate when maintained carefully, but it decays quickly when work changes, people move, or teams are under pressure. It also rarely scales to the long tail of an analyst’s real working files.
MyDataWork infers lineage across the warehouse, cloud sources, and the local-file layer, with confidence tiers instead of false certainty. The shared warehouse-table reference becomes one bridge: when a local Alteryx workflow, SQL script, or notebook and a Power BI, Tableau, ThoughtSpot, Looker or SIgma asset read from the same warehouse table, MyDataWork can surface that relationship and show the evidence behind it, whether that BI asset is connected directly or cataloged from a file export.
That helps span the gap between where analytical work is prepared, where it is consumed, and where its business purpose is tracked.
This is not a replacement for governed, column-level lineage inside a modern data platform. It is a complement to it. MyDataWork is focused on the practical lineage of analytical work: the files, workflows, notebooks, dashboards, source references, external dependencies, and use cases that explain how work actually gets done across tools.
Where lineage meets use cases
Lineage and use cases are two layers of the same picture.
Lineage is the structural layer: which assets connect, which sources they reference, which files depend on which other files, and where there may be external dependencies.
Use cases are the business layer: which assets serve which outcome, who depends on the work, what value it is meant to deliver, and whether it is progressing.
Apart, each is half a story.
A dependency graph without a sense of purpose can tell you that assets connect, but not whether anyone cares. A list of outcomes without lineage can tell you what matters, but not what the work touches or what might break when something changes.
Together, they are what make the workspace actionable.
A use case tells you: this matters.
Lineage tells you: here is everything it touches, and everything that touches it.
When you change an asset, lineage shows you the blast radius. When you assess an estate, lineage reveals shared dependencies, reuse opportunities, and hidden infrastructure that the outcome view alone cannot see. When an AI agent needs context, lineage gives it structure while use cases give it purpose.
That combination — purpose plus structure — is what turns a collection of files into a system of record you can actually reason about.
Why this matters now
The modern analytics estate is not one clean platform. It is a working environment spread across warehouses, BI tools, spreadsheets, notebooks, local workflows, exports, shared folders, and project-specific logic. Some of that work is governed. Much of it is not. Some of it is visible to IT. Much of it lives with the analyst who built it.
That was already a continuity problem. Agentic AI makes it more important.
An AI agent cannot reason well about analytical work if it only sees isolated files or isolated tables. It needs to know how those assets connect, what depends on them, which use cases they support, and where confidence is strong or weak. It needs the practical map of the work, not just the governed map of the warehouse.
That is what MyDataWork lineage is designed to provide.
BI tools can show lineage inside their own environment. Data catalogs can show governed lineage across enterprise data assets. MyDataWork shows how analytical work connects across files, workflows, cloud assets, external dependencies, and use cases.
That is the missing layer: work-level lineage.
See how your assets, dependencies, and use cases connect across tools. Start free for 90 days.