Open any analyst’s working folder and you will find the same thing: spreadsheets, SQL scripts, Alteryx workflows, dashboards, notebooks, a model or two, and a handful of exports. Each file is the product of real effort and real judgment. And not one of them can tell you why it exists.
A file named dc_starting_inventory.xlsx does not record that it supports a weekly inventory decision worth $30,000 a year. A network-optimization workflow does not note who depends on its output, whether anyone still runs it, or what “working” would even mean. The business reason lives in someone’s head, a meeting note, a Slack thread, or a document no one can find later.
When that person changes roles, the work goes dark. The file survives; the meaning does not.
This is the gap the Use Case closes in MyDataWork. It is the layer most data tooling skips, and it is one of the reasons the product exists.
What a catalog misses
A data catalog is usually organized around the governed data asset: tables, schemas, columns, definitions, ownership, and lineage. That is useful and necessary. It helps organizations understand what data exists, where it lives, how it is defined, and how it connects.
But it often stops one level below where the analyst’s work becomes a business outcome.
A catalog may tell you that a table, spreadsheet, or report exists, what fields it contains, and how it connects technically. What it usually does not maintain is the working business record around it: that this asset supports a demand-forecasting decision, that the decision has an owner, that it is expected to be worth $30,000 a year, and that right now it is realizing none of that value because the model is not yet run on a schedule.
That second set of facts is what turns a pile of assets into a portfolio of outcomes. In MyDataWork, the object that holds those facts is the use case.
That distinction matters. MyDataWork is not trying to replace a data catalog’s role in governing enterprise data assets. It is capturing the layer around analytical work that catalogs usually do not own: the objective, stakeholder, business value, progress, notes, action plan, and practical dependencies behind the work people actually deliver.
This is also why the use case is hard for a traditional catalog to own. Catalogs are usually implemented for governance, access, definitions, and technical metadata. Use cases live closer to the analyst, the business stakeholder, and the manager trying to understand what work is active, valuable, stale, duplicated, or ready to modernize. That context changes often. It is part documentation, part portfolio management, part continuity record, and part operating view.
That is the space MyDataWork is built for.
What a use case actually is
A use case is the record that binds the business purpose of the work to the assets, people, value, and next actions behind it.
It brings together three things that are normally scattered.
The work is the specific set of assets that serve the use case: files, workflows, dashboards, notebooks, models, SQL, spreadsheets, and related data sources.
The intent is the business objective behind the work: what it is supposed to improve, what outcome it supports, what value it is expected to deliver, and how progress should be measured.
The accountability is the human context around the work: the stakeholder who depends on it, the owner or contributor who maintains it, the notes that explain what changed, and the action plan that shows what should happen next.
Around that core, a use case can carry AI-generated recommendations, progress notes, communication history, and next actions. The record is not just a description of intent. It becomes the place where the work is explained, measured, improved, and carried forward.
That is why the Use Case detail view in MyDataWork is organized around the way people actually manage work: Overview, Objectives & Progress, Assets & People, Recommendations, and Action Plan.
A use case record — the Overview tab ties objective, status, and value to the work. The tab row is how the record is managed.
How you work with it
You can create a use case by hand, but the faster path is to let MyDataWork analyze your cataloged metadata and structural signals, then propose use cases grounded in the work that actually exists. These are not generic templates dropped into an empty workspace. They are suggestions based on the assets you have connected, the tools you use, and the patterns MyDataWork can infer from your environment.
You keep the ones that match how the business thinks about the work.
From there, you build the record up.
You link the assets that serve the use case, so the catalog and the outcome are connected in both directions. You can see which assets a use case depends on, and which use cases an asset supports.
You set the objective and the numbers. Choose what you are measuring — dollars, hours, percentage, a count, or another unit that fits the work. Set a baseline, current value, and target. As the work progresses, MyDataWork calculates progress automatically so realized-versus-estimated value is visible at a glance instead of buried in someone’s status update.
Choose what you’re measuring and set baseline → target; progress is calculated for you.
You assign a stakeholder. A use case without an owner is one of the most common ways analytics work quietly stalls, so ownership is a first-class field, not an afterthought.
You log progress as things change. Notes, decisions, communications, and next actions stay attached to the use case instead of disappearing into scattered documents and conversations.
You turn recommendations into action. AI-generated recommendations can become action-plan items, so the use case is not only a record of what exists. It is a working place to decide what should happen next.
Use cases have a lifecycle too. Active ones stay in front of you. Finished, paused, or inactive ones can be archived and restored later, so the workspace reflects what is live without losing the history of what came before.
An example
Take an inventory-optimization effort built on a couple of Excel files and an Alteryx workflow. As a set of files, it is nearly invisible to the business. As a use case, it becomes legible.
Objective: reduce stockouts and carrying cost by optimizing inventory positioning.
Assets: the starting-inventory and distribution-center spreadsheets, feeding the network-optimization workflow.
The example’s three assets linked to the use case — and no stakeholder assigned yet.
Value: an estimate of $30,000 per year, a baseline of today’s performance, and a target to drive toward.
Owner: the analyst or manager accountable for the decision.
Status: active, with $0 realized so far because the model exists but is not yet run on a schedule.
That last line is the point. The use case does not just describe the work. It exposes the gap between what the work is worth and what it is delivering.
A $30,000 estimate sitting at $0 realized with no assigned owner is not a failure. It is the clearest possible signal of where to focus next.
The Workspace Agent surfaces exactly that gap: ‘Assign a stakeholder to Inventory Optimization.’
Without the use case, the organization sees a spreadsheet and a workflow. With the use case, it sees an unfinished business outcome.
Why this is the key idea, not just a feature
Most tools in this space are organized around the asset. MyDataWork is organized around the use case — the business reason those assets exist — and that choice changes what everything else can do.
Because use cases capture intent and value, the rest of the product has something real to reason about.
The Asset Health Dashboard can show portfolio value, stakeholder coverage, staleness, asset mix, and recent Workspace Agent activity because use cases turn scattered work into measurable units of management.
Because use cases carry value and ownership, the Dashboard rolls them up — value, coverage, staleness, tool mix.
AI analysis can be scoped to a use case, or to a client or project group, so recommendations and assessments are about a specific body of work instead of an undifferentiated heap of files.
The Workspace Agent can surface operational gaps that only make sense at the use-case level: a use case with no stakeholder, a high-value effort losing momentum, assets that have become quietly load-bearing, or new files that have not yet been linked to the work they support.
The Asset Estate Assessment can report portfolio-level facts — estimated value, realized value, realization rate, stakeholder coverage, health observations, and connections worth documenting — because those facts only exist once work is expressed as outcomes rather than files.
Agent Access over MCP can give an approved AI agent useful context without handing over business data values or file contents. The agent can see approved use cases, linked assets, lineage, schema signals, and outcomes as metadata. That is the difference between an agent that can list your files and one that can reason about the work those files support.
This is the deeper reason the use case matters. It gives every other feature a business anchor.
Why data teams need this layer now
For years, analytics work has been managed through a mix of folders, dashboards, ticketing systems, project trackers, docs, and memory. Each tool holds a piece of the story, but none of them holds the working relationship between assets, decisions, people, and value.
That was already a problem. Agentic AI makes it more urgent.
An AI agent cannot reason well about analytical work if all it sees is a pile of files. It needs to know what those files support, which ones matter, who depends on them, what outcome they are tied to, and whether the work is active, stale, complete, or underperforming. That context does not appear automatically just because a table exists in a warehouse or a file exists in a folder.
Someone has to capture the layer of meaning around the work. That is what the use case does.
A catalog tells you what data assets exist and how they connect. A use case tells you what the work is for, who depends on it, what value it is meant to deliver, and whether it is actually progressing.
That is the layer data practitioners never had a real system of record for — and it is the layer MyDataWork is built around.