A useful thing happens once an organisation gets serious about Microsoft Fabric. The conversation gradually stops being about moving data into it. That job obviously still matters. Fabric gives teams Data Factory, engineering workloads, warehouses, real-time processing, analytics and OneLake underneath them. Increasingly, it also gives data owners a central place to discover and govern the Fabric estate through the OneLake catalog.
But once the plumbing starts working, much older questions tend to reappear.
Are these two customers actually the same customer?
Which supplier address should finance use?
Who decided that product category was correct?
Why does one report count 48,000 customers while another counts 51,000?
Can an AI agent change this value, or only suggest that somebody else does?
None of those are really ingestion problems. They are data-management problems, and putting more data into a shared analytical platform tends to make them more visible rather than less important.
IF WE HAD TO SUMMARISE THAT:
Microsoft Fabric data management use cases are the operational jobs needed to make data reliable once it is being shared across Fabric workloads. They include entity resolution, continuous data quality, reference data, governance execution, mastered data products, agent-assisted stewardship and preparing trusted data for analytics and AI.
That is why we think about data management in Microsoft Fabric as an operational layer around the data that Fabric workloads are already moving, storing and consuming. CluedIn can move data between Fabric and its graph-based mastering environment, publish mastered data back through Fabric Open Mirroring, and make CluedIn rules available to data being worked with in Fabric.
Here are seven places where that starts becoming useful.
A lakehouse can happily store three records for the same supplier. Technically, nothing has gone wrong. Unfortunately, the person trying to calculate total spend now has a problem.
The same thing happens with customers spread across CRM and billing platforms, products arriving from several ERPs, locations with inconsistent identifiers, or organisations represented differently by regional systems. This is where entity resolution becomes part of the Fabric architecture.
CluedIn can bring records from multiple systems together, use matching rules and contextual signals to identify possible duplicates, and maintain a golden record representing the agreed business entity. Its graph model can preserve relationships around that record rather than simply flattening everything into another table. The output can then be published back for Fabric workloads to consume.
That matters because there is little point centralising analytics while allowing every analytical team to independently decide what a customer, supplier or product is.
A very ordinary example is often enough to expose the problem. Ask two finance systems for the same supplier and compare the names, addresses, tax identifiers and parent relationships. If somebody still needs a spreadsheet to reconcile them before reporting, you have found an entity-resolution use case.
Data quality projects have a habit of arriving just before something important. A migration is approaching. A dashboard is going live. A new AI initiative needs training data. Someone profiles the dataset, discovers the usual collection of missing values and strange codes, cleans enough of it to get through launch, and everybody moves on. The data, naturally, does not.
New records arrive. Source systems change. People find inventive new ways of entering telephone numbers. For Fabric teams, the more useful model is continuous quality management around the datasets that matter.
CluedIn supports profiling, validation, standardisation, quality rules, scoring, stewardship and ongoing monitoring rather than treating quality as a single transformation step. Its Fabric integration also allows CluedIn rule metadata to be retrieved and evaluated against data in OneLake from a Fabric notebook.
The architectural question becomes much more useful: which quality decisions should happen before data is published, which should run directly against Fabric data, and which exceptions genuinely need a person?
There will rarely be one answer for every dataset. An invalid country code can probably be treated differently from two customer records that look almost, but not quite, like the same person.
Reference data is rarely the glamorous part of a Fabric programme. It is also remarkably good at causing trouble. Country codes, customer statuses, organisational structures, product classifications, currencies, risk categories and dozens of other controlled lists quietly influence joins, measures, workflows and business logic throughout an estate.
When those values are maintained independently in several source systems, Fabric can bring all of the disagreement together very efficiently.
The management job is different from storage. Someone needs to decide which values are allowed, how hierarchies and relationships work, who can change them, what happens to retired values and how the approved version reaches consuming workloads.
That makes reference data a particularly good early Fabric data-management use case because the scope is understandable and the benefit spreads quickly. Instead of embedding slightly different versions of the same business definitions in pipelines and reports, teams can maintain governed values centrally and publish them to the workloads that need them. This also starts to give AI something it badly needs: the language of the company.
In customer work presented at FabCon 2026, requirements for AI agents included understanding company terminology, abbreviations and the data dictionary, not merely being able to query the records. That kind of semantic context is easy to underestimate until an automated process confidently interprets an internal acronym the wrong way.
From conflicting records to a shared business entity
Fabric’s governance capabilities have moved on considerably. The OneLake catalog gives organisations built-in discovery, governance insights, domains, endorsement, metadata scanning, policies and recommended actions across the Fabric estate. Microsoft Purview extends that picture across broader governance, protection, audit, risk and compliance scenarios.
The interesting question for data management is what happens after governance identifies something worth acting on. A catalogue can tell you that a dataset exists. A quality signal can tell you something is wrong. A policy can describe how data should be treated. Eventually, somebody or something still has to do the work.
That might mean applying a validation rule, remediating a quality issue, resolving duplicated entities, enriching incomplete data, classifying a record or asking a business owner to make a decision.
This is where CluedIn’s integration with the Microsoft estate becomes more operational. Governance-related assets and processing can be connected with Purview, while Power Automate and Teams can be used to take approvals and exceptions back to the people responsible for them.
The aim should be less distance between knowing there is a data problem and doing something useful about it.
The result of mastering data should not live in a specialist platform that only the data-management team understands.
It needs consumers.
For a Fabric environment, that usually means getting trusted entities back into the estate in a form that analytics, AI and downstream engineering can use without recreating the mastering logic.
CluedIn Streams let teams define which mastered records and properties should be published. Its Open Mirroring connector can then push data into Microsoft Fabric, where Fabric manages the mirrored database in OneLake.
This is one of the more important architectural ideas in the whole discussion.
The source data in Fabric and the mastered output in Fabric are not the same thing.
One represents what operational systems supplied. The other represents business decisions applied across those sources: these records belong to the same supplier, this attribute wins, this relationship is valid, this record passed the agreed quality threshold.
Keeping that distinction visible makes the mastered dataset genuinely reusable.
It also gives teams a much better starting point for what people loosely call a “trusted data product”. The trust has to come from somewhere.
This is where data management starts looking rather different from the MDM projects many organisations remember.
There is a large amount of work around master data that is important, repetitive and not particularly rewarding for the people doing it: spotting anomalies, looking for duplicates, proposing quality fixes, standardising values, classifying records, suggesting rules and enriching incomplete entities.
CluedIn’s current agent model is designed around those kinds of jobs. The platform supports built-in and configurable agent workflows for data-quality fixes, duplicate identification, rule suggestion and other data-management tasks, with governance, explainability, auditability and human review where required.
The useful part is not giving an agent a chat window. It is giving it a job.
What records should it inspect?
What context does it need?
What is it allowed to recommend?
Which changes need approval?
When should it run again?
What evidence needs to remain afterwards?
Fabric then becomes the environment in which the resulting trusted data is consumed, rather than another place where humans inherit the same backlog of stewardship work.
At Komatsu, the target architecture was designed around AI agents handling much of the data-management workload at significant scale while retaining governance, lineage and explainability. That is a much more interesting use of AI than adding a chatbot to a data catalogue.
A data-management job, not just a prompt
This is probably the broadest use case, but it is also the reason the others matter. Fabric makes it increasingly easy to bring enterprise data together and put powerful analytical and AI services around it. OneLake gives those workloads a common storage foundation instead of requiring every service to maintain another independent copy.
That increases the value of getting the underlying business entities right. A model asking about customer behaviour needs reliable customers. Supplier analysis needs suppliers that are not counted three times. Product AI needs classifications, descriptions and relationships that make sense outside the application they originated in.
Otherwise a very modern AI architecture ends up spending a surprising amount of effort rediscovering old master-data problems. This is why we would not treat MDM as a system sitting beside Fabric with an occasional export between them.
The better model is a working loop. Data arrives through the Microsoft estate. The records that require mastering, quality improvement, enrichment or entity resolution are managed with those decisions and controls intact. Trusted outputs flow back into Fabric. The next analytical or AI workload starts from there. New data arrives and the process continues.
CluedIn’s Microsoft Fabric integration supports both directions of that relationship: Fabric data can be brought into CluedIn, and mastered CluedIn data can be published back into Fabric. The integration also covers rules running against Fabric data and additional Fabric-oriented workflows.
That is what makes Fabric data management an operating model rather than another destination on an architecture diagram.
You do not need to begin by declaring an enterprise-wide master-data transformation. Look for a dataset already creating friction inside Fabric.
A supplier report that requires manual reconciliation. Customer counts nobody can quite explain. Product attributes that keep failing validation. A business hierarchy maintained in three places. An AI project whose team is quietly cleaning the same data every week.
Pick one. Work out what decision is currently being made manually, who owns it and where the trusted result needs to appear. Then make that decision reusable.
Once Fabric is becoming the place where more of the organisation’s data is consumed, that kind of work compounds surprisingly quickly.
If you are already using Microsoft Fabric, CluedIn can help you identify where entity resolution, data quality, mastering and governed AI agents fit into the estate you already have.
Discuss your Microsoft Fabric use caseRelated reading
Microsoft Fabric, Purview and CluedIn: how the architecture fits together
What agentic data operations actually look like in a Microsoft data estate