Microsoft Fabric – EduDataSci – Educating the world about data and leadership

What Replaces Purview Data Governance?

Microsoft is retiring Purview Data Governance. What can OneLake Catalog take over today, and where will enterprises need to replace scanning, lineage, glossary, quality, and approval workflows?

A claims analyst looking for paid claims in Fabric might find a warehouse table, a Power BI semantic model, and three reports with nearly the same name. The analyst needs to know which one Finance uses and whether the paid amount includes reversals. If the number goes into a reserve review, someone may also need to trace it back to the source and show who approved access. All of that work falls under data governance, and the catalog has to support more than the initial search.

On November 12, 2026, Microsoft announced the retirement of Purview Data Governance and named Microsoft Fabric, with OneLake Catalog, as its data governance platform. Support ends November 12, 2027. Microsoft’s Partner Center notice puts Unified Catalog, Data Map, Workflows, and the older Azure Purview governance offerings in scope. Microsoft has closed new governance account creation and put existing capabilities in maintenance mode through the end of support.

Microsoft Purview continues to handle data security and compliance. In Fabric, that includes sensitivity labels, data loss prevention, and audit. A steward who depended on a Data Map scan to identify sensitive fields in an upstream system still has to account for that scan in the transition. The security policy and the source scan do different jobs.

Where OneLake Catalog fits

I like the direction for organizations that already do much of their analytical work in Fabric. In OneLake Catalog, the analyst can use Explore to find the certified claims model, identify its owner, and see the lineage Fabric captures. If the model is configured to be discoverable, the analyst can request access from the catalog. The team that owns the model can use Govern to check curation and sensitivity label coverage, and workspace administrators can use Secure to review permissions and manage supported OneLake security roles. The people making those decisions work with the same items the analyst finds.

That proximity matters when someone uses the model outside the Fabric portal. An analyst can discover it from Excel. If the team makes it available through a Fabric data agent, the agent honors the user’s permissions on the underlying data. Finance still owns the definition of paid claims. A clear description and a certified model give people a better chance of finding the measure Finance actually uses.

OneLake also reaches selected data outside Fabric. A shortcut can reference files in Amazon S3 from a Fabric lakehouse. Metadata mirroring can surface supported Azure Databricks Unity Catalog tables while reading the data in place. Database mirroring, as with Azure SQL Database, continuously replicates data into OneLake. Those are different ways to bring external data into Fabric’s working environment. With an external shortcut that uses a configured connection identity, for example, the source authorizes that identity and OneLake controls which Fabric users can read through the shortcut. That detail matters if the analyst also has a direct way to reach the source.

The jobs that need a replacement

A team that used Unified Catalog to find Fabric assets has a straightforward starting point. A steward who used it to maintain a business glossary, approve access to a data product, and report on quality across several platforms has a broader migration. Here is how I would map that work against the capabilities Microsoft documents today.

Purview capability	What Fabric covers today	What the transition needs to cover
Discovery and domains	OneLake Catalog searches Fabric items and supported tables. Owners, tags, and endorsements provide context, and Fabric domains group workspaces by business area.	Carry over who owns and stewards each business domain, including assets managed outside Fabric.
Data Map scanning	Fabric offers tenant metadata scanning for Fabric items. Shortcuts and mirroring make selected external data or catalogs visible in Fabric.	Replace scheduled scans of external systems where teams rely on Data Map’s source-specific inventory, schema, and classification coverage.
Lineage	The catalog shows dependencies for supported Fabric items. The workspace lineage view can show external upstream sources one step away.	Preserve the path through external transformations, including column-level lineage where a report or control depends on it.
Business glossary and data products	Fabric item descriptions, endorsements, and semantic models carry business context into discovery and use.	Rehome governed glossary terms, relationships to critical fields, and curated data products that group assets across platforms.
Data quality and health	Govern tracks catalog and security posture. Fabric can apply row-level quality constraints during materialized lake view refreshes.	Replace the profiling, recurring rule runs, and quality scores reported across assets, products, and domains. Preserve the history teams use to monitor changes.
Access and publication workflows	Fabric supports access requests for discoverable semantic models and provides controls for reviewing and granting Fabric permissions.	Replace product access and publication workflows, including approver routing, terms-of-use attestations where required, and approvals to publish glossary terms.

Take the claims example. The Fabric lineage view can show the warehouse and semantic model behind a report. If a Snowflake transformation assigns the reversal flag, Finance needs to be able to follow the number through that transformation as well. Fabric can consume a supported Snowflake output through a shortcut. Tracing how the reversal flag was calculated requires lineage from the Snowflake transformation itself. For a reserve review, Finance needs to be able to follow both parts of that path.

Quality is a similar case. A Fabric engineering team could implement a rule in a materialized lake view to keep records with a missing payment identifier out of the curated table. The steward’s job includes tracking whether the rate of missing identifiers is rising and finding which upstream system introduced the problem. If the team uses Purview’s quality reports for that work, the replacement needs somewhere to store and compare rule results over time. A Fabric team could use a shared results table and report. Teams running the same checks across several platforms may need a data quality or observability tool that can pull the results together.

Fabric IQ’s ontology, currently in preview, gives the business context a place in Fabric. A team can model Claim and Payment as entities and represent how a payment relates to a claim. An agent can then use those relationships when answering questions. The steward still needs a process for approving the official definition of a paid claim, relating that definition to fields across platforms, and notifying teams when it changes.

I would make OneLake Catalog the entry point for Fabric users. Where an enterprise already runs important workloads across several platforms, I would also keep an enterprise catalog that can scan those systems and maintain the business context they share. Microsoft names Atlan, Alation, Collibra, and Informatica as integration options. If a team uses two catalogs, it should decide where stewards maintain the authoritative glossary and product definitions so the claims team has one place to change what “paid” means. Fabric governance is included in Fabric capacity. The cost of maintaining enterprise coverage depends on which other jobs and systems the organization needs to support.

I’d start the transition with a data product someone already depends on. Carry its definitions, ownership, and quality rules forward, then have a consumer find it, request access, and trace a reported number to its source. Have the steward retrieve the approval and quality history. Microsoft’s Purview self-serve analytics can publish metadata about domains, products, glossary terms, subscription requests, and quality rules and results into OneLake or Azure Data Lake Storage. That gives teams a starting inventory and a way to preserve some of the evidence they’ll want during the transition. If the approval record is part of a regulatory control, I’d review that workflow with Microsoft early, as the retirement announcement recommends for highly regulated customers.

Microsoft has already been improving discovery in OneLake Catalog. At FabCon Barcelona, it showed how users could go beyond the item name to inspect tables and columns in the catalog. Every step like that makes it easier for a data owner to give people the context they need before they start working with the data.

Microsoft Ignite is next week, November 17–20, and we may hear more about OneLake Catalog there. I’ll be listening for improvements to business glossaries and lineage across platforms. I’d like the next analyst looking for paid claims to be able to find the approved definition and trace the reversal back to its source from the same place they found the model. That feels within reach.

FUAM and the Business of Running Fabric

FUAM’s latest updates give Fabric leaders more useful evidence for capacity investments, workload improvement, ownership, and access reviews.

A request for more Microsoft Fabric capacity often arrives with a familiar explanation: usage is growing, performance is slipping, and the platform team needs more room. Approving the request may be entirely reasonable. But a business leader should also be able to ask what is consuming the capacity, which services depend on it, and whether the proposed spending addresses growth or avoidable inefficiency.

Fabric Unified Admin Monitoring, or FUAM, helps assemble the evidence for that conversation. Its latest published updates make it more useful to leaders who need to connect platform operations with spending, ownership, and business priorities.

As of October 17, 2026, the newest dated entry in the FUAM changelog is release 2026.6.1, published June 2. The developments below support a more informed discussion about how the organization runs Fabric.

Business Events Go GA in Microsoft Fabric

Business Events are generally available in Microsoft Fabric. Explore the technology, the changes to data-product design, and the operational work these signals can support.

A data platform can tell a distribution team that a customer’s order is likely to arrive late. Getting that finding to the person who can change the outcome is often a separate project. Someone has to recognize the condition, build an integration, decide who should respond, and preserve enough context to explain what happened afterward.

Microsoft’s September 2026 release lists Business Events as generally available. This gives Fabric teams a common way to publish meaningful business occurrences and connect them to downstream responses. For organizations already using Fabric to combine data and calculate business conditions, that is a substantial extension of what the platform can contribute.

I see the architectural opportunity in treating the findings produced by analytics as something other teams can subscribe to and use. Understanding that opportunity starts with what a business event represents, then follows through to the systems we build and the people whose work those systems support.

Fabric Policies and the Business of Governed Self Service

Fabric Policies bring more granular controls to selected actions in Microsoft Fabric. Explore how the preview changes architecture, delivery practices, and the business case for delegated ownership.

A finance team wants to build its own forecasting tools in Fabric. The platform team wants to support that work while keeping production engineering, network protection, and encryption decisions under clear ownership. Each request is reasonable. The difficulty is expressing both in the platform without turning every new project into another round of administrative negotiation.

Microsoft’s Fabric Policies announcement introduces a more granular way to govern selected actions. Currently in preview, the feature lets administrators define conditions for who can perform an operation and where. That makes it possible to describe an approved way of working more precisely than a broad organizational permission alone.

The business significance is the prospect of more useful delegation. Teams can take responsibility for their analytical work within boundaries the platform can enforce. Understanding that opportunity requires looking at what a policy evaluates, how its rules interact, and how we should build and operate Fabric when governance itself becomes a managed artifact.

Build a Fabric Ontology

The useful test of an ontology is whether it helps an agent answer a business question using the right entities, relationships, and calculations. A diagram full of connected objects is only the beginning.

Microsoft’s updated Fabric ontology experience gives us more to work with: semantic-model measures, richer metadata, natural-language rules, namespaces, inheritance, and an agent that can help create and query the model. This walkthrough builds a small customer-operations ontology and checks it against a result we can calculate independently.

The question is deliberately specific: which customers have an open, high-priority service case at least seven days old, and how much open order value belongs to those customers? The example includes two qualifying cases for one customer, so a careless join can double the commercial amount. That makes the exercise useful for testing meaning as well as connectivity.

Business Meaning for Enterprise AI

An AI assistant can find a customer record and still misunderstand the customer. It may confuse a legal entity with a billing account, calculate revenue using the wrong definition, or treat an unresolved service case as evidence of a commercial risk that the business has never agreed to measure that way.

These are familiar data problems. AI makes them more visible because it lets more people ask broader questions without knowing which system, measure, or subject-matter expert should supply each part of the answer.

Microsoft’s updated Fabric ontology capabilities offer a practical way to address that problem. They let an organization capture business concepts, connect them to data, reuse established calculations, and make that context available to supported agents. The late-September and October updates strengthen the connection between the analytical models companies already maintain and the wider Microsoft IQ ecosystem.

My interest is in the economics of that reuse. A company that defines its customer, product, account, and service concepts once, with accountable owners, should have less interpretive work to repeat every time it builds another agent. It also has a more precise place to investigate when an answer is wrong.

The GPU Is Not the Product: What Query Acceleration Changes in Microsoft Fabric

The moment a warehouse most needs predictable performance is usually the moment everyone asks it a question at once.

Market volatility drives simultaneous risk, liquidity and exposure queries. A card-processing incident sends analysts, applications and investigators into the same transaction history. Month-end reporting puts Finance, Operations and executives on the same governed data while automated services continue doing their own work in the background.

Microsoft Fabric’s new query acceleration preview addresses that pressure in an unusual way. The T-SQL does not change. The tables do not move. Fabric identifies eligible scans, joins and aggregations and sends them to a GPU working beside the CPU inside the warehouse execution plan.

That does not make every query seven times faster or add general-purpose GPU compute to Fabric notebooks. It makes specialized compute an internal property of the governed data product, below the interface its consumers already use.

Blog News: New Reference Pages, Practical Projects, and Blaise

Explore the new Fabric architecture reference, GitHub guides, Teacher Workbench and Lovable Deployment pages—and meet Blaise in The Anti-Squirrel Resistance.

There is a point at which a useful blog needs a better front door than its most recent post.

An article can explain an idea, take a position, and work through an example. A few weeks later, however, the reader who wants to use that idea may need something different: a current reference, the right download, a guide to contributing, or a clear place to begin. Those resources should not require remembering which Tuesday an article appeared.

I have been adding that kind of structure to EduDataSci. The new pages bring together a Microsoft Fabric architecture reference, practical projects and downloads, and a set of GitHub guides that start with the questions people actually ask. They are intended to make the site more useful after the reading is finished.

There is also a new Sunday contributor. His priorities are companionship, duck sticks, and exposing what he considers a deeply neglected squirrel problem. Blaise has acquired a section of his own, and he is taking the responsibility seriously.

The Landing Lakehouse: The Fabric Pattern Between Arrival and Use

A source begins mirroring into Microsoft Fabric on Friday. By Monday, the tables are visible in OneLake. Production engineers can build from them. Developers can query them. Testers can point validation jobs at them. Analysts can begin exploring.

The delivery looks successful because the data arrived quickly. The architecture may already be in trouble.

The first reachable version of data is rarely the version every user and environment should consume. Production needs fidelity and controlled change. Development needs realistic relationships without unnecessary exposure. Test needs stable inputs that do not shift underneath automated validation. The source team needs to retain authority over what lands and what may be published. Governance needs a defensible answer to a deceptively simple question: which version of this data is visible to whom?

A Landing Lakehouse provides that answer.

The pattern uses a dedicated Lakehouse as the controlled boundary between direct arrival and governed use. Mirrored data, external shortcuts, and source-owned Fabric data can land once. The Landing Lakehouse then exposes distinct schemas for production, anonymized development, representative subsets, Known Copies, and curated validation. Each output is a separate surface with its own purpose, access model, refresh behavior, and owner.

The point is not to add another layer for its own sake. The point is to keep the convenience of Fabric from collapsing several different contracts into one raw surface.

Microsoft Fabric Databases and AI Move Closer to Everyday Operations

A dashboard can tell a business exactly what is wrong while leaving most of the work of fixing it untouched. A collections manager sees overdue balances, then opens email to investigate a dispute, finds the relevant contract, and asks someone else to update the account. The analytical system has produced a useful answer. The operational process still depends on people carrying that answer between systems.

Microsoft’s Fabric, database, and AI announcements since the beginning of September are increasingly aimed at that gap. Fabric is acquiring more of the capabilities needed to describe a business, recognize a change, and support the work that follows. SQL databases are becoming more capable AI application backends. Foundry is adding the execution services that let agents participate in recurring processes. The Barcelona FabCon and SQLCon releases make this direction particularly visible, with the early October Decision-1 announcement adding a specialized model for the smaller judgments inside those processes.

I see this as a substantial expansion of Fabric’s purpose. Microsoft is positioning it as a shared foundation for running data-intensive business operations, extending well beyond reporting and analytical storage. The strongest part of the strategy is its use of assets organizations already own: operational databases, Power BI measures, business relationships, and established permissions. That gives the recent announcements a coherence that is easy to miss when they are read as separate feature lists.