The announcements span three connected themes: preparing the data estate for AI, curating business context with Fabric IQ, and putting that context into action through Copilot, agents, and applications.

This roundup includes conference announcements and recent releases highlighted alongside them. Availability labels distinguish GA, public preview, private preview, and forthcoming capabilities. Where component-level release statements differ between the keynotes and product documentation, those differences are noted.

As you’ll see, there are a TON of announcements, so I’ve first grouped them by availability—Generally Available, Public Preview/Coming Soon, and Private Preview/Sneak Peeks—and then by topic, such as Power BI and Fabric IQ, Data Factory and mirroring, OneLake, Data Engineering, capacity and governance, Real-Time Intelligence, and SQL. Within each group, I’ve ordered the announcements based on what I think will be most important to readers. My favorite new features are: Fabric IQ in Microsoft Copilot Chat and Cowork, IQ Sharing in Fabric, Agentic data engineering with Osmos, On-demand billing and F0 capacity, Policies in Fabric, the new unified Copilot in Fabric, and Modern Report Builder.

The Future of Fabric and Power BI

What stands out to me is how many of these announcements point in the same direction: Fabric is moving from “write all the code yourself” toward “describe the outcome, set the guardrails, and let AI do more of the implementation and operations.” The clearest examples are the new unified Copilot in Fabric, Agentic data engineering with Osmos, Modern Report Builder, Power BI Agentic Experiences, Copilot in Real-Time Intelligence, operations agents, database agents, and Build agent with AI.

Instead of manually creating every pipeline, notebook, query, report, application, and troubleshooting workflow, we are increasingly defining what we want to accomplish and letting AI help build, configure, diagnose, optimize, and maintain the solution. This is already extending into Power BI. With Power BI Agentic Experiences, developers can give an agent requirements—or even an example of the desired report—and have AI create or modify semantic models and reports, validate its work, and iterate on the results. At the same time, Modern Report Builder takes this a step further by letting users describe a complete application in natural language and generate an experience that can combine analytics with inputs, writeback, shared state, and operational workflows. Additional info

That raises an interesting question about the future of Power BI itself. As AI takes over more of the report-building work, Power BI users may increasingly start by deciding what kind of experience they actually need: a traditional report for analysis and monitoring, or a purpose-built app that combines analytics with inputs, writeback, workflows, and actions. In other words, the design decision may shift from “How do I build this report?” to “Should this be a report or an application?” AI can then help create whichever experience best fits the business need.

Reports are certainly not going away, but I can see the center of gravity gradually shifting from manually arranging visuals and writing measures toward defining the business outcome and letting AI generate the right experience around it. In some cases that will still be a report; in others it may be an application that helps users not only understand the data, but also enter information, trigger workflows, and take action.

Fabric IQ, IQ Sharing, and Policies in Fabric are important to this shift because they provide the trusted business context, shared knowledge, permissions, and governance these AI experiences need to work safely and accurately. Technical expertise remains critical, but where that expertise is applied is changing—from manually writing every line of code or building every visual to designing the architecture, defining the desired outcome, establishing the guardrails, and validating what the AI produces.

Generally Available (GA)

Power BI, Copilot, and Fabric IQ

Fabric IQ in Microsoft Copilot Chat and Cowork (GA) (more info)

Fabric IQ brings governed Power BI insights into Microsoft Copilot Chat and the Fabric IQ plugin for Copilot Cowork. Both integrations are GA, extending established business metrics into the tools where users already work. Additional info

For example, a sales manager could ask, “Using our Sales Performance report, compare this quarter’s revenue with last quarter by region.” The answer would use the report’s established revenue definitions and the data the manager is permitted to see. In Cowork, the manager could then ask, “Draft an email to my team summarizing those findings”—turning the analysis into a draft communication within the same conversation.

The Cowork experience uses Power BI reports and their underlying semantic models while respecting existing permissions and row-level security. The September announcement also highlights citations, sensitivity labels, and expanded coverage of reports published through organizational apps. Additional info

Microsoft announced these insights without additional AI token costs; normal Copilot/Cowork licensing and applicable usage charges still apply. Integration with the Copilot Code experience is coming through the Frontier program, Microsoft’s opt-in early-access program for evaluating new Copilot agents and AI features before general availability. Administrators control participation, and preview features can change. Additional info

Power BI Agentic Experiences (GA; some underlying components remain in Preview) (more info)

Power BI Agentic Experiences let BI developers delegate report and semantic-model development to AI agents instead of building everything manually. An agent can use your business context, semantic models, team conventions, and Microsoft’s Power BI skills to create or modify models and reports, then validate and refine its own work. Microsoft describes the overall agentic experience as GA, although some of the individual skills and tools that enable it remain in preview.

For example, you could give an agent a requirements document—or even a screenshot of the report layout you want—and ask it to build a sales dashboard. The agent can inspect the semantic model, create or modify DAX measures, build report pages and visuals, apply formatting, validate the report definition, reload the changes in Power BI Desktop, capture screenshots, and iterate based on the results. The workflow shifts the developer toward describing requirements and reviewing the output rather than manually building every visual and measure. Additional info

Under the covers, this combines Power BI agent skills with tools such as the Power BI Authoring MCP server and Power BI Desktop Bridge. Microsoft’s report-authoring skill can create and modify PBIR reports, while the semantic-model skill can work with tables, relationships, measures, DAX, deployment, and optimization. Some of these individual capabilities are still labeled Preview even though Microsoft’s September Power BI announcement labels the broader Power BI Agentic Experiences as Generally Available. Additional info

Fabric IQ MCP endpoint (GA) (more info)

The Fabric IQ Model Context Protocol endpoint makes trusted Power BI insights available to agent-building experiences outside the Fabric interface. This is a conversational consumption capability, distinct from the authoring MCP servers used to create or modify semantic models.

Planning in Fabric—planning and semantic-model integration (GA) (more info)

Planning brings budgets, forecasts, and scenarios into Fabric’s shared business context. The core product became GA in July 2026, rather than first launching at Barcelona.

The keynote identifies semantic-model writeback, plan-driven event triggers, a new measure model for driver-based planning, and multi-driver/multi-measure simulations as GA. Planning’s writeback is a specific capability—not a statement that every semantic-model connector supports writes. The new Native Planning Engine and certain tenant controls have separate preview status.

Fabric data agents in Copilot Studio and interactive visualizations (GA) (more info)

Fabric data agents in Copilot Studio and interactive visualizations for data agents are GA. Fabric data agents in Microsoft Copilot Chat are a different integration, shown separately as a sneak peek.

Power BI developer mode, authoring plugin, and project formats (GA) (more info)

Developer mode and the Power BI authoring plugin are GA. Power BI Projects—PBIP—and the enhanced report format—PBIR—support treating reports and semantic models as version-controlled development assets. Additional info

PBIR is now the default report format. Editing and saving a PBIR-Legacy report automatically converts it to PBIR; Microsoft documents backup and restoration behavior. This is an operational change for existing reports, not just a new option for developers.

Org Apps, Restrict from Copilot, and enhanced Power BI governance (GA) (more info)

Additional GA announcements include Org Apps, Restrict from Copilot, and enhanced governance for Power BI in Fabric IQ. These expand the distribution and governance capabilities surrounding Power BI content and its use in AI experiences.

Local Power BI Authoring MCP server (GA) (more info)

The local authoring server lets agents create and change semantic models, including models open in Power BI Desktop and PBIP/TMDL files on the local machine. Its hosted counterpart is separately in preview. Model-authoring capabilities should not be confused with the Fabric IQ endpoint for answering business questions.

Larger table-visual Excel exports (GA) (more info)

Table visuals using Data with current layout can export up to 500,000 rows. This is not a universal limit for every export mode.

Data Factory, Mirroring, and Connectivity

Data transformation with dbt jobs (GA) (more info)

Managed dbt jobs let teams build, test, and run transformations within Fabric alongside notebooks and pipelines, without a local CLI setup. The keynote lists Fusion engine support as coming soon; the Data Factory article calls the forthcoming support dbt Core v2, previously known as Fusion. That future engine support is separate from GA dbt jobs.

Extended mirroring—Change Data Feeds (GA) (more info)

Change Data Feeds expose inserts, updates, and deletes so downstream processing can consume changes incrementally. Logical view replication and Snowflake security-role replication are addressed separately because their component-specific release statements differ between sources.

Mirroring for Google BigQuery (GA) (more info)

BigQuery mirroring continuously replicates data into OneLake, where a mirrored database and SQL analytics endpoint make it available to Fabric workloads. It removes the need to maintain a custom ingestion pipeline, but it is not zero-copy access through a shortcut.

Copy Job and pipeline automation enhancements (GA) (more info)

GA additions include change data capture and audit columns in Copy Job, event-driven Copy Jobs with Fabric Activator, smart retry for pipeline activities, a Lakehouse Maintenance activity, and service principal and workspace identity support for the Outlook activity.

SharePoint Lists mirroring and SharePoint/OneDrive source support (GA) (more info)

SharePoint Lists mirroring brings business-maintained list data into OneLake. The keynote also places SharePoint + OneDrive in the GA group for shortcut and mirror sources. These related announcements should not be reduced to lists alone—or interpreted as saying that all SharePoint and OneDrive content uses the same mirroring mechanism. Additional info

ADBC driver transition for supported connectors (GA availability; phased transition) (more info)

Supported connections can adopt Apache Arrow Database Connectivity—ADBC—drivers through per-connection selection and administrative controls. This does not automatically replace every ODBC connection: the transition concerns specified embedded drivers, and controls are being enabled in phases.

OneLake and Ecosystem Integrations

OneLake shortcut performance and storage lifecycle improvements (GA) (more info)

OneLake’s GA announcements include performance upgrades for Dataverse and SharePoint shortcuts and storage lifecycle policies. Microsoft also identifies production support for storing Databricks data in OneLake—a storage-interoperability capability, not an announcement that Databricks compute becomes a native Fabric workload.

Atlan native Fabric connector (GA) (more info)

Atlan’s native Fabric connector is GA. This is a connector-specific release statement, not one availability label for every Atlan-related investment or future integration.

Data Engineering and Data Warehouse

Fabric Runtime 2.0 (GA) (more info)

Fabric Runtime 2.0 brings together Apache Spark 4.1, Delta Lake 4.2, and Python 3.13, with an enhanced native execution engine. Availability does not mean every existing workspace has automatically migrated; runtime adoption should still be configured and tested.

The keynote repeats a TPC-DS 1 TB comparison showing the native execution engine at up to 6× the performance of open-source Spark. The chart’s 6× bar is labeled December 2025; it is not evidence that upgrading to Runtime 2.0 itself creates a new sixfold improvement. Additional info

Custom live pools and materialized lake views (GA) (more info)

Custom live pools and materialized lake views are GA. The underlying materialized lake views feature remains separate from the newer optimal-refresh support for updates and deletes, which is covered in the preview section. Additional info

Result-set caching (GA release listing) (more info)

Result-set caching reuses results from eligible repeated SELECT queries in warehouses and lakehouse SQL analytics endpoints. It is enabled by default, subject to eligibility rules and invalidation when relevant data changes. This is separate from the warehouse’s preview cache-cooldown capability.

SQL query editor productivity improvements (GA) (more info)

The GA improvements include a faster results grid, improved object exploration and IntelliSense, autosave controls, bulk query management, and .sql import/export. These are separate from the keynote’s preview data profiles, visual schema design, and interactive query-result charts. Additional info

Capacity and Platform Management

Unified capacity management and larger capacity options (GA components) (more info)

The keynote brings capacity signals, alerts, surge protection, and overage together as unified capacity management. Its individual components have different rollout stages, detailed below.

The new F4096 and F8192 capacity SKUs are GA, expanding options for sustained, demanding workloads.

Capacity overage (GA) (more info)

Capacity overage bills eligible excess consumption to help prevent throttling during temporary overloads. The rate is three times the pay-as-you-go rate, applied to relevant excess CU hours—not all capacity usage. It does not increase the SKU’s underlying resources, and its rolling spending threshold is not a hard spending cap.

Capacity Metrics app enhancements (GA) (more info)

The Metrics app adds health-state duration, CU-per-second analysis, daily/hourly heatmaps, top-contributor views, and chargeback integration. These analytical capabilities complement the preview operational controls in Capacity Insights & Actions. Additional info

Capacity overview events (GA) (more info)

Capacity overview events bring capacity signals into Real-Time hub for monitoring and alerting, including Eventhouse and Activator workflows. The newer, more detailed capacity operation events have separate preview status.

Developer Tools, Governance, and Security

Git integration and bulk item-definition APIs (GA) (more info)

Compare and commit, selective branching, branched workspaces, and bulk import/export APIs are GA. They support reviewing changes, isolating development work, and moving item definitions through automated workflows. File-level commits and delegated branch-workspace administration have separate preview labels.

OneLake network protection and data-loss-prevention controls (GA, with scope-specific differences) (more info)

The keynote lists DLP restrict access, inbound network protection to OneLake, and outbound network protection as GA.

The product announcement distinguishes outbound protection for shortcuts—GA—from maps and operations agents—Preview. Additional info

Fabric MCP, CLI, and Terraform enhancements (GA) (more info)

The developer announcements include Fabric Remote MCP, Fabric Local MCP support for Data Factory and extended OneLake tools, and Fabric CLI enhancements for Azure sign-in, cross-workspace search, and bulk deployment. The Fabric Terraform Provider adds security and audit resources.

Expanded Fabric REST API quotas (GA announcement) (more info)

The documented model uses independent per-identity limits: 500 calls/minute for Platform APIs, 200 calls/minute for Job Scheduler APIs, and 500 calls/minute for Long-Running Operations APIs. Endpoint-specific limits can also apply; the keynote’s 500-calls-per-minute headline is not a universal allowance for every endpoint.

Networking Communication Policies Admin API (GA) (more info)

This API provides a tenant-wide, paginated inventory of workspace inbound and outbound networking policies, supporting centralized inspection and administration.

Real-Time Intelligence

Eventhouse accelerated shortcuts, inline transforms, and self-optimization (GA) (more info)

Eventhouse enhancements include accelerated shortcuts over OneLake Delta tables, inline transformations through update policies, and a self-optimizing engine that adjusts schema, storage, and caching using query patterns. These are separate from preview Copilot authoring and administration capabilities.

Business events in Real-Time hub (GA) (more info)

Business events provide reusable schemas for turning business moments into streaming signals. Events can be emitted across Fabric and trigger actions through Activator. The announcement also includes live event-flow previews and sample publishing for validation.

Additional Real-Time Intelligence capabilities (GA) (more info)

The keynote lists GA for MongoDB and Salesforce CDC connectors, stream processing of mirrored database change feeds, Copilot data exploration, the Eventhouse capacity planner, and Eventhouse entity diagrams.

SQL and Azure Databases

DiskANN vector indexes and search (GA) (more info)

DiskANN vector indexes are GA for Azure SQL Database Hyperscale, Azure SQL Managed Instance, and SQL database in Fabric. The SQL keynote also highlights vector compression and full data-modification support, keeping indexes maintained as data is inserted, updated, and deleted. Additional info

SSMS Agent Mode and SQL developer tools (GA) (more info)

GitHub Copilot Agent Mode in SSMS supports multistep agentic workflows. Additional GA announcements include vector and JSON support in Data API builder, Schema Compare and SQL Projects in SSMS, and SQL Formatter in SSMS and Visual Studio Code.

SQL Server on Azure Local, including disconnected operations (GA) (more info)

SQL Server on Azure Local supports connected and disconnected operations. The SQL keynote distinguishes Azure-connected management from a local appliance-VM control plane for disconnected environments, while infrastructure and data services remain local.

Larger Azure SQL Database Hyperscale compute options (GA) (more info)

The 160- and 192-vCore Premium-series service objectives are GA, providing more compute headroom for demanding workloads. These larger sizes are separate from the serverless auto-pause and higher-density elastic-pool previews.

Automatic index compaction in Azure SQL Database (GA) (more info)

The SQL keynote identifies automatic index compaction as GA, presenting it as hands-free index maintenance. This is separate from vector indexing and the larger Hyperscale compute options.

Public Preview / Coming Soon

Power BI, Fabric IQ, and Applications

Fabric IQ ontologies—Unified Semantic Modeling enhancements (Public preview) (more info)

Microsoft is expanding unified semantic modeling through Fabric IQ ontologies, bringing together operational, analytical, and business context. Ontologies provide a shared understanding of business concepts—such as customers, products, orders, and locations—and their relationships, allowing reports, applications, and AI agents to use consistent business definitions.

A key advancement is the ability to reuse existing Power BI semantic model definitions, including DAX measures and calculated columns, rather than recreating business logic. Ontologies can also connect to Fabric data sources through simplified bindings, including OneLake shortcuts and mirrored databases. This enables context-rich querying without copying the underlying data.

The updated experience introduces AI-powered ontology creation, allowing users to describe business concepts in natural language and have an AI agent help create, manage, query, and validate ontologies. The agent is grounded in Fabric data, existing semantic models, and business documents. Importantly, it follows a proposal-first approach: users review and approve recommended changes before they are applied. Natural-language business rules provide additional context, such as identifying at-risk customers or low inventory. Additional info

For example, a retailer could connect Customers, Products, Stores, Orders, and Inventory across multiple data sources, reuse an existing Power BI Revenue measure, and define business rules for declining sales and low inventory. An AI agent could then answer questions such as “Which stores have declining sales and products at risk of running out of stock?” using this shared business context.

Additional modeling enhancements include relationships without dedicated join tables, keyless bindings, complex relationships, reusable properties, inheritance, and namespaces. Overview and Instances views simplify exploration, while version history and RDF/OWL import and export support management and interoperability.

For developers, public REST APIs, SDKs, and MCP endpoints enable programmatic creation, management, and querying of ontologies. Integration with Git and CI/CD workflows also makes it easier to manage ontology development and deployments alongside other Fabric assets.

Rather than replacing Power BI semantic models, unified semantic modeling builds on their definitions and connects them with broader operational data and business relationships. The result is a reusable business-context layer that helps AI agents and applications understand not just what the data contains, but what it means to the business.

Fabric Apps enhancements (Public preview) (more info)

Fabric Apps brings data, functions, storage, and hosting together, extending Microsoft Entra identity and Fabric permissions to applications. Microsoft also announces built-in monitoring of app usage, health, and performance.

Rayfin is the open-source development framework behind Fabric Apps, not a former name for the product. Its SDK and CLI let developers and AI coding agents define application backends in code, generate APIs, develop locally, and deploy directly to Fabric, where authentication, infrastructure, and governance are managed automatically. Additional info

The broader announcement adds connections to Fabric SQL databases, warehouses, lakehouse SQL analytics endpoints, and semantic models, plus PostgreSQL support, backend functions, secure credential storage, file storage, a Universal App template, and a GitHub Copilot plugin. OneLake-integrated application storage is forthcoming, separate from the existing application file-storage capability.

Writeback remains connector-specific: warehouse and Fabric SQL database connections support writes; lakehouse SQL analytics endpoints and semantic-model connections are read-only/query-only. This does not negate Planning’s separately announced semantic-model writeback capability. Additional info · Additional info

Fabric data agent enhancements and observability (Public preview) (more info)

The announcement includes deeper Fabric IQ ontology integration, deep thinking mode, unstructured-data support, date and time awareness, User Data Functions as tools, and a consumer-to-creator feedback loop.

A standout addition is Build agent with AI, which reduces the amount of manual configuration needed to create a data agent. Instead of hand-writing all the instructions, descriptions, and example queries, creators can describe what the agent should accomplish and let AI recommend the configuration, then review and refine it. Additional info

For example, you could tell it to build a sales agent that answers questions about customers, opportunities, and regional performance. It can use available schema and supporting business context—such as semantic models, documentation, glossaries, and data dictionaries—to help generate better instructions and examples. Microsoft also identifies observability and monitoring for data agents as Preview. Additional info

Microsoft 365 Copilot inside Power BI and Fabric (Public preview) (more info)

Microsoft 365 Copilot is being embedded inside Power BI and Fabric, with shared conversation history. The initial, licensed preview is off by default.

Hosted Power BI Authoring MCP server (Public preview) (more info)

The hosted authoring server lets agents create and modify semantic models in Fabric workspaces without installing local binaries. The local server remains GA and additionally supports local Desktop and PBIP/TMDL scenarios. Both authoring options remain distinct from Fabric IQ’s conversational consumption endpoint.

Native Planning Engine and new tenant controls (Preview) (more info)

The new Native Planning Engine, built on Rust and Apache Arrow with tight OneLake integration, is explicitly in preview in the dedicated announcement. Microsoft advertises up to 10× improvements in performance and scale, not a guaranteed gain for every model. New controls for Planner/Stakeholder session upgrades and capacity-consumption warnings are also preview.

The keynote groups these improvements more broadly under GA Planning. The core product remains GA; that does not make every newly announced component GA.

Power BI modeling enhancements (Preview / Coming soon) (more info)

APPROXIMATEDISTINCTCOUNT expands to Import and Direct Lake in preview. String indexing and full-text indexing, including TEXTCONTAINS and TEXTSIMILARITY, have forthcoming previews.

Power BI reporting, connectivity, and distribution (Mixed availability) (more info)

Previews include the web report ribbon, live visuals in Outlook web and Loop, and Outlook Mail connector. DirectQuery/composite web modeling is announced; Fabric Apps in Org Apps is forthcoming.

Data Factory, Mirroring, and Connectivity

Copy Job integration with Eventstreams (Public preview) (more info)

This integration bridges batch and streaming in both directions. Supported Copy Job sources can feed an Eventstream, while Eventstream data can be routed into supported Copy Job destinations. The keynote also highlights no-code event-driven applications built on change feeds.

Snowflake Security Roles Replication (Public preview in the OneLake article; GA grouping in the keynote) (more info)

Supported Snowflake roles and permissions can be translated into OneLake security. The OneLake article says Public preview, while the keynote groups the capability under GA. Confirm supported mappings rather than assuming every Snowflake security policy transfers unchanged.

Logical view replication (Preview in feature documentation; GA grouping in the keynote) (more info)

The keynote groups logical view replication under GA extended mirroring, while the feature-specific documentation still labels Snowflake view mirroring Preview. Additional info

The documented implementation executes the source view and materializes its results as a Delta table in OneLake, with 12-hour refreshes and additional compute charges. It does not simply copy a SQL view definition or provide the same freshness as near-real-time table mirroring.

Modern Power Query Editor and reusable transformations (Public preview) (more info)

A Modern Power Query Editor in Power BI Desktop is in public preview—separate from the Modern Report Builder app experience. Other previews include multicloud and citizen-user-friendly destinations, reusable transformations through shared and visual queries, and a Business Actions activity.

Dataflow Gen1-to-Gen2 Upgrade Wizard (Public preview) (more info)

The wizard performs an in-place upgrade while retaining the dataflow’s ID, name, schedule, and connections, with assessment and upgrade reporting. The upgrade cannot be reversed. Review downstream compatibility first; Microsoft documents a Save As alternative when the original Gen1 dataflow needs to be preserved.

Dynamics 365 Business Central mirroring (Public preview announced) (more info)

Business Central mirroring is labeled Public preview in the keynote. The Data Factory article describes rollout as coming soon, bringing selected tables and companies into OneLake.

OneLake, Sharing, and Ecosystem Integrations

IQ Sharing in Fabric (Public preview announced; rollout forthcoming) (more info)

IQ Sharing is designed to distribute governed tables and files together with business context across teams, customers, and partners. Its announced launch scope includes Markdown (.md) agent instructions and RDF (.rdf) ontology files. For example, a retailer could package sales and product tables with a Markdown file explaining how to calculate net revenue and an RDF ontology describing relationships among products, stores, and transactions. These are file-based representations of context; native sharing of Fabric IQ ontology items and Power BI semantic models through IQ Sharing remains on the roadmap. Additional info

Partner announcements describe zero-copy consumption. For example, xMentium says its planned integration will make structured document-extraction results available as zero-copy assets in a customer’s own Fabric workspace. That supports an in-place sharing description for this integration, but does not establish a universal recipient item type, permission-inheritance model, or refresh guarantee for every IQ Sharing path. Additional info

The public preview is forthcoming. Additional info

OneLake APIs, Iceberg interoperability, and hosted MCP (Public preview) (more info)

The preview list includes the Table Read API for secure application and agent access, Apache Iceberg catalog federation, Iceberg Table API writes with credential vending, and hosted MCP for OneLake. Hosted OneLake MCP remains distinct from the Fabric Remote and Local MCP capabilities listed as GA.

Salesforce Data 360 sharing (Public preview) (more info)

The keynote announces Salesforce Data 360 + Microsoft Fabric with bidirectional, zero-copy sharing. Salesforce data is represented in Fabric through a shortcut, distinguishing this integration from database mirroring that physically replicates data.

AVEVA CONNECT, AWS Glue, and Google Lakehouse Catalog integrations (Public preview) (more info)

All three appear in the keynote’s public-preview shortcut and mirror sources group. Google Lakehouse Catalog integration is distinct from BigQuery database mirroring. The announcement does not provide a complete supported-object or security-policy matrix for AVEVA, so its preview designation should not be interpreted as universal support for every AVEVA dataset or policy.

ClickHouse workload in Fabric (Public preview) (more info)

The workload provisions a dedicated ClickHouse Cloud service on Azure with an embedded SQL experience in Fabric. Preview synchronization creates point-in-time copies of selected lakehouse tables from the same workspace. It does not provide scheduled or continuous replication, and it does not currently write back to OneLake. Refreshing the copy requires another synchronization.

Access revocation requires particular care: removing or downgrading someone in Fabric does not reliably revoke their existing ClickHouse Cloud access. For immediate revocation, administrators must remove the user in ClickHouse Cloud. Per-table permission synchronization from OneLake is not supported. This workload is distinct from ClickHouse’s separate OneLake Table API integrations.

Azure Monitor integration (Public preview) (more info)

Azure Monitor integration provides Fabric access to newly arriving Log Analytics data while the underlying data remains in Log Analytics storage. The documented preview is read-only and does not backfill historical data. Azure and Fabric permissions are independent, so source table-, row-, and column-level restrictions should not be assumed to carry into Fabric automatically.

Data Engineering and Data Warehouse

Agentic data engineering with Osmos (Public preview) (more info)

The Fabric data engineering agent, also called Project Osmos, goes beyond generating a notebook or suggesting a code fix. Engineers describe a complete outcome—such as modernizing an ETL process, preparing data for analytics, or tuning an existing lakehouse—along with the source data, expected outputs, and validation criteria. The agent can inspect data, create and execute Spark notebooks, write Delta tables, and refine its approach based on actual results.

For example, a retailer could ask: “Build bronze, silver, and gold layers from our customer, product, and sales files. Preserve the raw inputs, standardize and deduplicate records, create daily-sales summaries, and verify that revenue totals reconcile.” Osmos can plan the steps, generate and run the notebooks, and check row counts, keys, and totals rather than simply returning code for an engineer to execute manually. Additional info

Tasks run persistently in Fabric, so disconnecting a development client or turning off a laptop does not stop the work. Engineers can return to the same task, inspect outputs and errors, and provide further guidance. Authorized collaborators can also monitor progress and contribute context.

Before execution, engineers review settings such as writable destinations, staging versus direct updates, rerun behavior, and permitted schema changes. These settings guide execution, but Fabric and OneLake permissions—not instructions in a prompt—enforce access. Generated artifacts and validation results still require review, and Microsoft identifies the preview as intended for evaluation rather than production use. Additional info

The announced experience spans Fabric, GitHub Copilot, Visual Studio Code, Codex, and Claude Code. The documented preview starts and steers tasks through supported command-line clients, with monitoring in the Fabric lakehouse; direct interaction through Copilot in the Fabric portal is not currently supported. This specialist engineering agent remains separate from the new unified Copilot in Fabric, which was announced in private preview. Additional info · Additional info

GPU-accelerated Fabric Data Warehouse (Public preview) (more info)

GPU acceleration targets high-concurrency, AI-driven analytical workloads, with one-click enablement and monitoring from the warehouse.

Microsoft’s TPC-H 300 GB comparison shows the 7× performance headline at 64 concurrent users against selected alternative warehouses. The accompanying up to 60% lower cost statement cites internal testing in May/September 2026. Competitor configurations are undisclosed; these are workload-specific vendor results, not universal gains or a blanket GPU-versus-CPU comparison.

Optimal refresh for materialized lake view updates and deletes (Public preview) (more info)

This enhancement incrementally processes supported updates and deletes instead of falling back to a full refresh. Refresh hints declare columns that uniquely identify output rows. Fabric does not validate that uniqueness at runtime, so incorrect declarations can produce inconsistent results. This remains separate from the GA core materialized lake views feature.

Additional Data Warehouse improvements (Public preview) (more info)

The warehouse announcements include cache cooldown, richer and friendlier T-SQL, selective and incremental migrations, and agentic monitoring powered by Copilot as public previews. Warehouse CLONE is in Private preview.

Data engineering developer enhancements (Public preview) (more info)

The Analytics keynote adds high-concurrency support in all drivers, pipeline support in Visual Studio Code, and a notebook toolkit for agents to the public-preview list.

SQL query editor—visual authoring enhancements (Public preview) (more info)

New warehouse authoring capabilities include detailed data profiles, visual schema design for tables, columns, and keys, and interactive charts created from query results. These specific previews are separate from the GA editor-productivity improvements listed earlier.

Capacity and Observability

On-demand billing and F0 capacity (Public preview announced; rollout forthcoming) (more info)

F0 is a zero-provisioned entry point to Fabric and OneLake: organizations can get started without first choosing a baseline amount of compute capacity. On-demand billing is enabled by default, so supported workloads use compute as needed and are charged according to consumption. The “zero” refers to compute provisioned in advance—not to the amount of processing available or the price of running it.

Organizations do not have to choose one billing approach for everything. They can combine provisioned or reserved capacity for predictable, ongoing work with on-demand compute for eligible intermittent or spiky workloads. For example, a company could keep regular reporting on provisioned capacity while running occasional Spark data-preparation jobs on demand. Microsoft already documents that Spark configuration; F0 introduces the separate option of starting without baseline compute provisioning. Additional info

An important OneLake implication is that customers will be able to read and write data without maintaining a dedicated, running Fabric capacity simply to access the lake. This makes OneLake more practical as a shared data foundation for external analytical engines and AI applications, rather than tying data access to an always-running Fabric capacity. Additional info

F0 is not unlimited free compute, free storage, or a guarantee of lower costs. Consumption still generates charges, and applicable storage and licensing costs must be considered separately. It could suit experiments and variable demand, but sustained workloads should be compared with provisioned-capacity pricing. Spending and governance controls remain important; specific rates, workload eligibility, limits, and rollout availability should be checked as the preview becomes available. Additional info

Observability in Fabric—unified monitoring (Public preview) (more info)

The refreshed experience brings jobs, workloads, and capacities together, with operations-agent investigations and Activator alerts. Workspace monitoring can consolidate telemetry from multiple workspaces into a shared Eventhouse, with retention, caching, custom endpoints, and public APIs.

Operations agents—investigations, pre-approved actions, and performance monitoring (Public preview) (more info)

Operations agents can investigate issues, identify likely causes, and recommend responses. Pre-approved actions separately let teams define circumstances in which an agent may act without requesting approval each time, while higher-risk actions remain reviewed.

The performance view exposes the agent’s monitoring and reasoning activity, including LLM usage. This monitors the agent itself, not just the business conditions it investigates. The pipeline-investigation experience remains a narrower troubleshooting workflow; it should not be presented as unrestricted automatic repair across Fabric.

Workspace-level surge protection (Preview; GA coming soon in the product announcement) (more info)

Workspace consumption limits help contain excessive usage while allowing exemptions for critical workloads. The keynote groups surge protection under GA unified management, but the detailed announcement says GA coming soon. Additional info

Capacity Insights & Actions and operation events (Public preview) (more info)

Capacity Insights & Actions combines monitoring with surge, overage, workspace-migration, and resizing controls. Operation events add workspace- and item-level detail alongside GA capacity overview events.

Developer Tools, Governance, and Security

OneLake catalog—expanded discovery, search, and governance (GA and Public preview) (more info)

OneLake catalog is becoming the central place in Fabric for finding, understanding, governing, and securing enterprise data. The expanded discovery experience goes beyond Fabric items to let users drill into tables and columns, review descriptions, preview data, and use filters such as domains and tags before deciding whether a dataset is appropriate. These granular discovery capabilities are GA.

For example, an analyst looking for customer data could search the catalog, find a relevant lakehouse or mirrored source, inspect its customer table and columns, preview the data, and review its business context before using it in a report or notebook. Developers can also discover Fabric content from GitHub Copilot CLI through Skills for Fabric, bringing governed data discovery directly into the development workflow. Additional info

Discovery is also expanding outside the Fabric portal. OneLake catalog discovery in Excel is in preview, while Microsoft Foundry integration brings governed enterprise data into AI-development workflows so trusted data can be used with agents and applications.

The OneLake catalog Search API, currently in preview, adds programmatic discovery across Fabric items and supported OneLake tables. This allows applications and agents to search the data estate without maintaining a separate inventory. Additional info

On the governance side, the expanded Govern experience is GA and brings governance insights, recommended actions, and administration of areas such as domains, capacities, workspaces, tags, and policies into a more centralized experience. Additional info

Availability varies by component: granular discovery, expanded Govern, and GitHub Copilot CLI discovery are GA, while the enhanced Search API, Excel integration, and Microsoft Foundry integration remain in preview.

Policies in Fabric (Public preview) (more info)

Policies provide attribute-based controls across Fabric, giving administrators much more precision than broad tenant-wide settings. Rules can evaluate attributes such as the user or group, item type, workspace, and capacity to determine whether an action should be allowed. Initial scenarios include controlling item creation and workspace security, with additional policy types expanding over time. Additional info

For example, an organization could create a policy allowing only members of the Data Engineers group to create Lakehouses, Notebooks, and Data Pipelines in designated production workspaces. Other users—or attempts to create other Fabric item types—could be blocked even if broader tenant settings normally permit creation. This gives organizations more granular governance without eliminating self-service for approved teams. Additional info

Policies are managed centrally through the Policies experience in OneLake Catalog. APIs, monitoring, and CI/CD support also make it possible to manage governance rules more like code—deploying and maintaining them consistently across environments instead of configuring each workspace manually. Additional info

Deployment plans (Public preview) (more info)

Deployment plans define ordered rollouts through a drag-and-drop canvas backed by YAML. Ingestion and validation can become pre- or post-deployment actions, making them part of a repeatable deployment instead of a separate manual checklist.

Additional security and administration capabilities (Public preview) (more info)

The keynote’s preview list includes customer-managed-key operations and administration APIs, workspace-level Private Link for ontologies, and nested security-group support in SQL endpoints. The OneLake access-audit interface’s conflicting release statements are addressed separately below. Additional info

Git integration—file-level commits, delegation, sensitivity labels, and branch switching (Public preview) (more info)

Preview additions include file-level commits, delegated administration of branch workspaces, and sensitivity labels as part of item definitions. Additional info

Contributor branch switching is a separate capability: contributors can switch the connected Git branch when an administrator enables it.

Spark granular runtime lineage (Coming soon) (more info)

Finer-grained Spark runtime lineage will provide more context about how data is used and transformed across the Fabric estate.

FQDN allowlists for outbound-protected Spark workspaces (Public preview coming soon) (more info)

Approved fully qualified domain names will provide another connectivity-control option for outbound-protected Spark workspaces. Preview rollout is forthcoming.

Real-Time Intelligence

Copilot in Real-Time Intelligence (Public preview) (more info)

New experiences support natural-language Real-Time Dashboard creation and Eventhouse administration, including tables, policies, schemas, and cluster inspection. Query-aware schema recommendations and optimization guidance are also announced. These preview authoring and administration features remain separate from GA Copilot data exploration.

Additional streaming, Eventhouse, and Activator capabilities (Public preview) (more info)

The Real-Time Intelligence announcements include custom stream connectors, event handling for non-schematized streams, AI-guided Eventhouse onboarding, and Activator rule management in Real-Time hub. Copy Job batch-source ingestion into Eventstreams is part of the separate batch/stream integration described above.

Fabric Maps in Real-Time Dashboards (Public preview) (more info)

Maps can be pinned into Real-Time Dashboards, combining geographic context with operational metrics. The dashboard references the map rather than copying its configuration; access to the map and its underlying sources still matters.

Databases and Sovereign Cloud

Database Hub in Fabric (Public preview) (more info)

Database Hub combines fleet management, observability, and database-agent experiences. The keynote’s database-family overview includes Azure SQL, SQL Server, Fabric databases, Azure HorizonDB, Azure Database for MySQL, Azure Cosmos DB, Azure DocumentDB, and Azure Database for PostgreSQL. That overview shows the intended breadth—not identical support for every administrative operation across every service.

Database agents for SQL and PostgreSQL (Public preview rolling out) (more info)

Database agents analyze performance and workload health, investigate problems, and prioritize recommendations. Preview is rolling out through Database Hub and Visual Studio Code, with actions subject to role-based access controls, approvals, auditing, and operational safeguards.

The keynote describes the agent cycle as detect, understand, verify, learn, and automate, using database context, skills, tools, and connectors.

Hyperscale serverless auto-pause and higher-density elastic pools (Public preview) (more info)

Serverless auto-pause reduces idle compute consumption by pausing compute during inactivity. Higher-density elastic pools support up to 50 databases per pool. A paused compute state does not eliminate every storage or other service charge.

Azure Arc migration experience for Hyperscale (Public preview) (more info)

An Azure Arc-enabled migration experience supports moving databases from on-premises environments and other clouds to Azure SQL Database Hyperscale. It brings assessment, provisioning, migration, validation, and cutover into a centralized workflow.

Microsoft Fabric for GCC High (Public preview) (more info)

Fabric’s expansion to Microsoft 365 Government Community Cloud High is announced as Public preview. This supports organizations requiring U.S. sovereign-cloud environments; the preview label is not a blanket assertion of every possible compliance authorization.

Foundry Local on Azure Local (Public preview) (more info)

Foundry Local brings model inference to Azure Local infrastructure, including disconnected scenarios. It is a separate preview from GA SQL Server on Azure Local, and deployment access is currently by request.

Microsoft SQL Agent Skills and the MSSQL extension experience (Public preview) (more info)

The SQL developer previews include Microsoft SQL Agent Skills and an updated MSSQL extension welcome page in Visual Studio Code. These are separate from GA SSMS Agent Mode and the other SQL development tools.

Private Preview / Sneak Peeks

The new unified Copilot in Fabric—discover, create, and maintain (Private preview) (more info)

This is a distinct new Copilot experience designed to provide one AI companion across the complete Fabric data lifecycle, rather than requiring users to move among separate workload-specific Copilots. The goal is for Copilot to understand the broader project you are working on—helping you discover relevant data and Fabric assets, create or modify solutions across workloads, and then troubleshoot, optimize, and maintain those solutions over time.

For example, a developer could start by asking Copilot to find the customer and sales data needed for a new analytics solution, then have it help build the ingestion pipeline, create transformations and a semantic model, and prepare the reporting layer. Later, the developer could return to the same project and ask Copilot to investigate a failed pipeline or performance problem without having to completely re-explain the project. The key idea is that Copilot retains project context and history across multistage work rather than treating every prompt as an isolated interaction.

The experience is also designed to follow developers into the tools where they already work. Microsoft says users will be able to work with the same Fabric context from Fabric itself or from supported IDE and command-line experiences. That complements Microsoft’s broader Skills for Fabric initiative, which teaches AI coding tools the Fabric APIs, query patterns, authentication requirements, and recommended implementation practices needed to work across Fabric workloads. Additional info

Microsoft highlights GitHub Copilot with Fabric Skills as one way to bring this Fabric-specific knowledge into development workflows. Skills are available for areas such as authoring, querying, operations, migrations, notebooks, T-SQL, KQL, Dataflows Gen2, Eventstreams, and semantic models, and can also be used with tools such as Claude Code, Cursor, Windsurf, and Codex-compatible environments. Additional info

The unified Copilot remains in private preview, so it should be viewed as Microsoft’s direction for a more persistent, cross-workload AI development experience rather than a replacement today for every existing Copilot in Fabric. Current Fabric Copilot experiences remain tailored to individual workloads and scenarios. Additional info

Modern Report Builder—the app-building experience in Power BI Desktop (Sneak peek; preview forthcoming) (more info)

Modern Report Builder represents a significant expansion of what authors can create from Power BI Desktop. Instead of starting with a blank report canvas and manually assembling visuals, authors will be able to describe the experience they want in natural language, start from a trusted semantic model, and iteratively refine the generated application. The resulting experience can go beyond a traditional dashboard by accepting user input, maintaining application state, writing data to supported destinations, and participating in operational workflows.

For example, a sales manager could start with an existing governed sales semantic model and ask for an application that shows sales performance by region, highlights accounts that are behind target, and lets regional managers enter revised forecasts or comments. The analytical portions of the app can remain grounded in the existing Power BI semantic model and its business definitions, while the new inputs can be stored in the app’s writable backend and incorporated into the workflow. This makes the experience much closer to building a lightweight business application than simply generating another report.

Under the covers, the experience builds on Fabric Apps. Fabric Apps provides application hosting, Microsoft Entra authentication, APIs, and a managed SQL database that can hold application-specific data and state. Semantic models can remain the governed analytical source, while the SQL backend can store information such as comments, approvals, forecasts, or other user-entered data. The semantic model itself does not become writable simply because it is used by the application. Additional info

This also creates a path from self-service BI to professional application development. A Power BI author could use prompts to create the initial experience and then hand the resulting Fabric App to a developer or IT team to extend it with additional logic, data sources, or custom functionality rather than rebuilding the application from scratch. Fabric Apps are standard web applications, so developers can continue working with the generated project after the initial AI-assisted creation. Additional info

The related More Power for Power BI Pro announcement brings these capabilities beyond customers with dedicated Fabric capacity. Microsoft says the forthcoming preview will be available to Power BI Pro and Premium Per User customers as well as Fabric capacity customers. Pro and PPU customers will receive Fabric Apps and Fabric Database capabilities of up to 1 GB per app at no additional cost, giving Power BI authors a managed application backend without first purchasing a Fabric capacity. Additional info

Modern Report Builder should not be confused with the existing paginated Power BI Report Builder product or with the separate Modern Power Query Editor. The keynote presents this new Power BI Desktop app-building experience as a sneak peek, with preview availability forthcoming.

Are AI-generated reports the future? Check out this interesting Reddit discussion about it.

Semantic views in OneLake (Sneak peek) (more info)

Semantic views are an early look at bringing governed business definitions closer to the data in OneLake. They overlap with Power BI semantic models in that both can describe business concepts such as Revenue, Customer, relationships, and metrics, but they appear to serve a different purpose. A Power BI semantic model is a full analytical model with tables, relationships, measures, security, and a query engine that reports and other clients consume. A semantic view is intended to make business meaning more open and reusable at the OneLake layer so the same definitions can potentially be consumed by analytics, applications, AI agents, and other platforms.

For example, today an organization might define Net Revenue as a DAX measure inside a Power BI semantic model. With semantic views, the goal would be to define that business meaning closer to the underlying OneLake data and reuse it across multiple experiences instead of recreating the definition for every model, application, or agent.

Microsoft has not yet documented how semantic views will handle calculations, security, authoring, query execution, or exactly how they will coexist with Power BI semantic models, so I would not describe them as a replacement for semantic models. They look more like an open, reusable semantic layer beneath or alongside them.

Warehouse CLONE (Private preview) (more info)

Warehouse CLONE was announced in private preview as a new warehouse-level cloning capability for Fabric Data Warehouse. The goal is to make it easier to create a copy of an existing warehouse for scenarios such as development, testing, experimentation, or validation without having to rebuild the environment manually.

Microsoft has not yet published enough detail to say exactly which warehouse objects are included, whether clones can span workspaces, how quickly they are created, or whether they use metadata-only, copy-on-write, or full physical data copies. It should therefore be treated as a new warehouse-level capability rather than assumed to behave like the existing table-cloning feature.

Fabric data agents in Microsoft Copilot Chat (Sneak peek) (more info)

Microsoft previewed bringing Fabric data agents directly into Microsoft Copilot Chat, allowing users to interact with specialized agents that understand their organization’s governed Fabric data and business context from the Copilot experience they already use.

For example, a sales user could ask a Fabric data agent in Copilot Chat, “Which customers had the largest drop in revenue this quarter, and what products drove the decline?” The data agent could use the Fabric data sources and instructions it was configured with to answer the question without requiring the user to open Fabric or understand the underlying tables.

This is different from the GA Fabric IQ experience in Copilot Chat, which is grounded primarily in Power BI reports and semantic models, and from Fabric data agents in Copilot Studio, which are already GA for building agents and extending Copilot experiences. The Copilot Chat integration for Fabric data agents remains a sneak peek.

Additional Announcements and Component-Level Qualifications

Guided modernization from Azure Data Factory and Azure Synapse (Announced) (more info)

The new Azure Data Factory upgrade experience lets customers view existing assets in Fabric, assess pipeline and activity compatibility, and plan incremental migration. Existing ADF assets remain the source of truth during evaluation rather than being silently replaced.

The Synapse Spark migration assistant copies supported artifacts and maps lake databases through OneLake shortcuts while underlying data remains in place. This is a distinct guided modernization experience, not another name for Osmos or warehouse migration tooling.

Apache Ossie and cross-platform semantic interoperability (Open-source initiative; incubating) (more info)

Microsoft and Snowflake are collaborating on Apache Ossie, a vendor-neutral standard for exchanging semantic metadata. The announcement highlights converting an Ossie document into both a Snowflake Semantic View and a Power BI semantic model. DAX recognition and ontology support are future contributions, not completed capabilities implied by the announcement.

Pipeline dependencies, Fabric API activities, and approvals (Announced) (more info)

The Data Factory announcement adds pipeline-level dependencies, native activities for invoking Fabric platform APIs, and an Approval activity for human-in-the-loop decisions. These are distinct from the already-listed retry, maintenance, and Outlook-identity improvements; the roundup does not assign one release stage to every new activity.

Additional Copy Job and Dataflow Gen2 capabilities (Announced; component availability varies) (more info)

Additional capabilities include Slowly Changing Dimension Type 2, configurable staging locations, and expanded destinations. Dataflow Gen2 gains optimized lakehouse writes, V-Order controls, broader modern-evaluator support, downloadable diagnostics, and richer monitoring. Destinations expand toward Snowflake, SharePoint, Excel, and email; Amazon S3 and Google BigQuery destinations are forthcoming.

Graph query and refresh enhancements (September update; individual release stage not specified) (more info)

Graph Analytics over Ontology introduces a configurable, managed graph with incremental refresh for analyzing complex relationships across business entities. It can uncover multi-hop dependencies, hidden patterns, and risks that traditional reporting may miss. For example, an organization could trace how a supplier disruption affects products, inventory, stores, and ultimately customers.

Additional graph enhancements include expanded GQL query composition and aggregation, unbounded variable-length path traversal, and incremental data and schema updates.. Additional info

Planning connections and organizational-app distribution (Announced enhancements) (more info)

Planners can connect to semantic models using their signed-in identity. Planning and Intelligence Sheets can also be embedded in organizational apps alongside reports, governed by existing audiences and access rules. This is separate from the forthcoming Fabric Apps integration with Org Apps.

OneLake security access auditing and role management (GA and Public preview) (more info)

The two announcements appear to refer to related but different parts of the OneLake security experience. The redesigned View users in role experience is GA and is focused on auditing access: administrators can see who can access a particular table, inspect what data an individual user can see, assign users to multiple roles, and revoke access from a centralized security view. Additional info

Separately, the keynote labels the newer Members and Data views in the OneLake Security UI as Public preview. These appear to correspond to the role-management experience where administrators inspect the Members in role and Data in role tabs for a specific OneLake security role—showing which users or groups belong to the role and exactly which tables, folders, rows, or columns that role can access. Additional info

So the simplest way to think about it is: the GA experience is primarily for auditing who has access, while the preview UI enhancements are focused on examining and managing the membership and data scope of individual OneLake security roles. They are part of the same security system, but they are not necessarily the same feature with conflicting release statuses.

Additional Real-Time Intelligence integrations (Announced) (more info)

Several additional Real-Time Intelligence capabilities were announced to make streaming data easier to enrich, expose to AI agents, and visualize in business context.

Reference Data Join lets Eventstream enrich live events with slower-moving business data stored in Lakehouse Delta tables. For example, an incoming stream of IoT device events could be joined with a device-reference table containing location, model, owner, and service tier before the event is routed downstream. It supports both visual joins and SQL-based enrichment and is currently in preview. Additional info

The Eventhouse MCP Server gives AI assistants and agents a standard MCP endpoint for working with Eventhouse data using natural language. Agents can discover schemas, generate KQL, sample data, and query both real-time and historical information without requiring a custom integration. The hosted Eventhouse MCP server is in preview. Additional info

Feature Service Support brings external geospatial data directly into Fabric Maps without first copying it into Fabric. It supports standards such as OGC Web Feature Service, OGC API – Features, and Esri Feature Services, making it possible to combine live operational data with authoritative GIS layers such as roads, parcels, service territories, or infrastructure. Feature Service Support is in preview. Additional info

Together, these additions expand RTI beyond ingesting and querying event streams: Reference Data Join adds business context, Eventhouse MCP exposes that real-time data to agents, and Feature Service Support adds geographic context for operational monitoring.

Deployment Note, Certification, and Upcoming Conferences

Power BI Desktop file-picker retirement (more info)

Starting October, Desktop versions from March 2026 or earlier lose OneDrive/SharePoint save-and-share through the old file picker. Update Desktop to retain this functionality.

Upcoming FabCon and SQLCon conferences

The next U.S. FabCon and SQLCon takes place in Atlanta, March 8–12, 2027, with workshops March 8–9 and the main conference March 10–12. Additional info

The closing keynote also announces an APAC conference in Sydney, April 6–9, 2027. Additional info

The next European conference takes place in Amsterdam, October 25–28, 2027. Additional info

Microsoft Certified: SQL AI Developer Associate (more info)

The certification covers AI-enabled database solutions across Microsoft SQL platforms, including T-SQL, CI/CD, AI capabilities, security, optimization, and deployment. Its official name is Microsoft Certified: SQL AI Developer Associate, associated with Exam DP-800.

More info:

FabCon and SQLCon 2026 in Barcelona: Building the data foundation for Microsoft Copilot and agents

Power BI’s next chapter: The evolution of business intelligence

Power BI September 2026 Feature Summary

Fabric September 2026 Feature Summary

Bringing governed analytics into the flow of work: Fabric Analytics at FabCon Europe 2026

What’s new in Microsoft OneLake and its rapidly growing ecosystem

Build, deploy, and govern Microsoft Fabric at scale

Planning in Microsoft Fabric: From insight to action

Trusted AI starts with Microsoft Fabric, Real-Time Intelligence, and IQ

From prompt to production: What’s new in Fabric Apps

FabCon/SQLCon Barcelona 2026: What’s new in Fabric Data Factory

Modernize your Azure Data Estate with Microsoft Fabric: A guided path from Azure Data Factory and Azure Synapse

Microsoft and Snowflake’s commitment to Apache Ossie

Connecting apps, databases, and AI on one foundation

SQLCon Barcelona 2026: Advancing SQL with greater control, scale, and intelligence

SQL Server on Azure Local is now generally available

ClickHouse for Microsoft Fabric—documentation and preview limitations

Power BI Authoring MCP server

Dataflow Gen1-to-Gen2 Upgrade Wizard

Fabric REST API quotas and throttling

Transition from ODBC to ADBC drivers

Microsoft Copilot Frontier program

Skills for Fabric

What’s new in Microsoft Fabric

(This is the final article in a three-part series on making data AI-ready. Part 1 covered what AI-ready data means, Part 2 looked at the Microsoft tools that support it, and this article focuses on how Prep data for AI and Fabric Data Agent instructions work together.)

You have connected a Power BI semantic model to a Fabric Data Agent, and now you want to explain that People means Customers and Revenue means Net Sales Amount. Several configuration names sound relevant: AI instructions, Data Agent instructions and data-source instructions, and example queries. Should you repeat the explanation everywhere to be safe? I would not take that approach, because these capabilities have different responsibilities and are not all available for semantic models. The useful distinction is between preparing the semantic model for AI and configuring the agent that decides when to use it.

Understand the two different jobs

The Fabric Data Agent architecture separates orchestration from source-specific querying. The agent interprets a question, chooses the relevant source or sources, and invokes the appropriate tool to generate and execute a query. For a Power BI semantic model, that involves DAX; other source types use their own query mechanisms. After the results return, the agent assembles a response for the user. I would describe the division this way: agent instructions address “When should I use this source, and how should the overall agent behave?” while model-specific configuration addresses “Once this model is selected, how should its data be understood and queried?”

The reason this distinction matters is that the Data Agent and the DAX generator have different jobs. Think of the Data Agent as the orchestrator. Its instructions help it interpret the user’s question, decide which source or sources to use, apply cross-source rules, and determine how the final response should be presented. If the agent decides that a Power BI semantic model is the right source, it then hands the question to a separate DAX-generation tool whose job is to understand that semantic model and create the appropriate DAX query.

That DAX-generation tool does not receive the Data Agent instructions. Instead, Microsoft’s semantic-model best practices state that it uses the semantic model’s metadata and its Prep data for AI configuration. This means an instruction such as “Use the Sales semantic model for revenue questions” belongs at the Data Agent level because it helps the agent choose a source. But an instruction such as “When the user says Revenue, use the Net Sales Amount measure” belongs in Prep data for AI because it tells the DAX generator how to interpret and query that particular semantic model.

Another way to think about it is that Data Agent instructions get you to the right source, while Prep data for AI helps generate the right query once you get there. Keeping semantic-model-specific knowledge with the model also makes that context reusable by supported experiences beyond a single Data Agent, including Power BI Copilot.

The easiest way to see the division of responsibility is to compare the capabilities side by side:

Capability	Scope	Supported for a Power BI semantic model source?	Used for semantic-model DAX generation?	Best use
Prep data for AI – AI Data Schema	Semantic model			Control which tables, columns, and measures AI should focus on
Prep data for AI – AI Instructions	Semantic model			Define terminology, business rules, synonyms, and interpretation
Prep data for AI – Verified Answers	Semantic model			Provide approved question/answer patterns that help guide DAX generation
Semantic model metadata	Semantic model			Table, column, and measure names/descriptions, synonyms, relationships, measure definitions, and other metadata that help NL2DAX understand the model
Data Agent Instructions	Entire Data Agent			Routing, overall behavior, source selection, response formatting, and cross-source terminology
Data Source Instructions	Individual source		—	Source-specific guidance for supported sources such as SQL, KQL, and graph
Schema Object Descriptions	Individual schema object		—	Explain the business meaning of individual SQL tables, columns, and other schema objects; especially useful for ambiguous or technical names
Example Queries	Individual source		—	Show how natural-language questions map to SQL, KQL, or GQL queries

That fourth column is especially important. Data Agent instructions can help the agent decide to use the Sales semantic model, but those instructions are not passed to the DAX-generation tool. Prep data for AI provides the model-specific context used to understand and query the semantic model once that source has been selected.

What should Data Agent instructions say?

Use agent-level instructions for routing, cross-source behavior, and presentation rather than the detailed interpretation of one semantic model. In a hypothetical sales-and-support agent, you might write: “Use the Sales semantic model for revenue, margins, customers, and sales performance. Use the Support lakehouse for support tickets, and consult both sources when a question requires sales results and ticket information.” A separate instruction could request a brief summary followed by a table and clearly identified reporting periods. Common terminology can belong here when it helps the agent understand questions across sources, but that does not replace the model-level definitions needed to generate correct DAX.

What belongs with the semantic model?

Prep data for AI supplies three model-level capabilities: AI data schemas, AI instructions, and Verified Answers. Together with the model’s names, descriptions, relationships, and measures, they provide context for supported AI experiences using that model. Calling Prep data for AI the source-specific configuration layer is a helpful mental model, although it is not the only configuration involved. You can still select semantic-model tables when adding the source to a Data Agent, and the underlying model remains important. I would prepare the model first rather than treating AI instructions as a replacement for unclear measures or incorrect relationships.

An AI data schema narrows attention to relevant tables, columns, and measures. Suppose a model contains Gross Sales, Net Sales Amount, Sales Before Returns, and several internal helper measures; exposing everything without context leaves more room for choosing the wrong metric. Focus the schema on what your agent should answer, while retaining necessary dependencies. Microsoft recommends aligning the agent’s table selection with the model’s AI data schema. Treat this as relevance configuration, not a substitute for permissions: the schema’s behavior varies across Power BI capabilities, and it does not redefine what a user is authorized to access.

AI instructions are where model-specific terminology and analytical rules belong. For our hypothetical model, you could write: “The People table contains purchasing customers; Person_ID identifies a customer. When users ask about revenue, use the Net Sales Amount measure, which excludes returns. GM refers to the Gross Margin Percentage measure, and sales-period questions use Order Date unless the question explicitly concerns shipments.” Notice that these instructions do more than expand abbreviations: they identify the intended objects and interpretation. Use actual model names, confirm the definitions with the business, and keep the guidance specific enough that you can test whether it was applied.

There is also a reuse benefit to keeping this knowledge with the model. Microsoft’s Prep data for AI FAQ explains that these configurations are stored on the semantic model rather than on individual reports, although different Copilot capabilities use different parts of the configuration. That is a reason to maintain shared definitions centrally instead of copying them into every agent. It is not a promise that every AI product automatically consumes every setting. Keep “Use the Sales model” at the orchestration level and “Revenue means this measure” with the model, even when both statements contribute to answering the same question.

Verified Answers are not an example-query text box

Verified Answers associate trigger questions with approved Power BI visuals and their relevant configuration. For example, you could use a reviewed visual showing Net Sales Amount by fiscal quarter and associate it with questions about quarterly sales performance. The value is not simply that someone supplied sample words; the visual embodies an agreed choice of measures, dimensions, and filters. For a question such as “What were sales last quarter?”, verify that the underlying calculation and time interpretation actually match that request. A visual permanently filtered to one historical quarter is not automatically a correct answer to a moving time-period question.

When a Fabric Data Agent uses a Verified Answer, it does not return the Power BI visual itself. Instead, the visual’s measures, columns, and filters help guide DAX generation. That is different from entering a natural-language question and arbitrary DAX into a Data Agent example-query box. Review the current Verified Answer limitations: Microsoft documents limitations for row-level and object-level security and says Power BI Copilot does not return Verified Answers when Fabric IQ is enabled. I would validate behavior in the exact experience you are deploying instead of assuming that a successful Power BI demonstration proves identical behavior in every consuming tool.

What changes for other source types?

Microsoft’s source-configuration support matrix is explicit: Power BI semantic models do not support Data Agent data-source instructions, data-source descriptions, or example queries. Model-specific guidance belongs in Prep data for AI instead. SQL and Eventhouse/KQL sources support source instructions and question-query examples, as do graph sources in preview. Ontology sources support neither source instructions nor example queries. For a SQL source, a description might explain what business area the source covers, while source instructions explain joins, status codes, and calculation rules. Those are different jobs: selecting the appropriate source is not the same as generating the appropriate query within it.

SQL sources can also use schema object descriptions, currently in preview, to explain what individual tables, columns, and other schema elements mean. For example, you could describe People as “one row per purchasing customer,” explain that Person_ID is the customer identifier, or document the meaning and units of an abbreviated column. These descriptions are especially useful when object names are ambiguous or highly technical. They are currently available only when the Data Agent uses the preview runtime.

For a concrete example, SQL source instructions could say, “People contains purchasing customers; join SalesHeader to SalesDetail using SalesOrderID.” An example query could pair “How many customers are recorded?” with SELECT COUNT(DISTINCT Person_ID) FROM dbo.People;, assuming those objects and that interpretation match your source. More complex examples can demonstrate date filters, joins, and aggregations that are difficult to explain in prose alone. These are question-query patterns supplied as context, not a separate requirement to retrain a model. Validate both the query and its business meaning, because syntactically valid SQL can still answer the wrong question.

Avoid contradictions, then test the result

Separating responsibilities reduces confusion, but it does not eliminate every possible conflict. Suppose your model’s AI instructions define Revenue as Net Sales Amount while a Verified Answer uses Gross Sales for the same question; those two model-level signals disagree. Or suppose agent instructions route a sales question to a different source than the one containing the approved calculation. Neither problem is solved by assuming one instruction automatically overrides another. Microsoft’s guidance on writing focused AI instructions warns about conflicting guidance, so I would resolve the definitions and routing rather than depend on an undocumented precedence rule. Instructions are guidance, not guaranteed enforcement.

Finally, test questions with known answers and inspect the generated query, not just the wording of the response. Try variations involving customers, clients, revenue, margins, and date periods, then check which source, measure, filters, and relationships were used. Microsoft provides Data Agent evaluation capabilities to support repeatable testing, but business review remains important. My working rule is simple: agent instructions govern source choice and overall behavior; Prep data for AI explains how to understand and query the semantic model. Combined with clean data and sound modeling, that separation gives you a more maintainable starting point than repeatedly adding instructions to whichever box happens to be open.

(This is the second article in a three-part series on making data AI-ready. Part 1 covered the fundamentals of AI-ready data, this article looks at the Microsoft tools that support it, and Part 3 explains how Prep data for AI and Fabric Data Agent instructions divide their responsibilities.)

Making data AI-ready involves more than choosing an AI product. You need reliable values, understandable business concepts, appropriate access, and enough context for the system to answer the questions people actually ask. In Part 1, a People table containing customers illustrated the gap between storing data and explaining it. Now comes the practical question: Which Microsoft capabilities help close that gap? I would organize them by the problem they solve, rather than treating them as a shopping list where every solution requires every product.

Clean and curate the underlying data

For physical preparation, start with familiar data-engineering capabilities. Fabric Dataflow Gen2 uses Power Query to clean, shape, merge, and enrich data through a low-code experience. You could standardize customer-status codes, remove confirmed duplicates, add readable descriptions alongside abbreviated values, and write the results into curated lakehouse or warehouse tables. A useful output might be a Customers table with consistent identifiers and documented rules about which records qualify as customers. This is where you fix the actual data rather than instructing an agent to work around known problems every time someone asks a question.

Fabric notebooks provide a code-first option for transformations that need custom logic, while Data Factory pipelines can orchestrate preparation activities and their dependencies. For example, a pipeline could run ingestion, execute a notebook that reconciles customer identifiers, and then refresh the curated output. SQL views are another option when you need clearer names or filtering without changing the original production tables. I would keep the distinction clear: pipelines coordinate the work, while dataflows, notebooks, and SQL perform the relevant transformations. The value comes from the preparation you implement, not from the presence of a pipeline alone.

Give the data reusable business meaning

A Power BI semantic model is an important part of this preparation, even before adding AI-specific configuration. Business-friendly names, descriptions, relationships, hierarchies, and explicit measures turn technical storage structures into a model people can analyze consistently. In our example, the model could expose Customers even though the original table remains People, and provide a Net Sales Amount measure rather than asking each consumer to reconstruct revenue logic. I would put shared calculations in measures whenever practical. That gives reports and supported AI experiences a defined calculation to use instead of several independently written versions of the same business rule.

Microsoft Purview addresses a related question: Which data should the organization trust, and who is responsible for it? Its governance capabilities include business concepts, cataloging, ownership, lineage, and data-quality management. For our customer example, that could mean identifying the authoritative customer data product and linking it to the agreed definition of Customer. However, I would not assume that writing a glossary definition automatically inserts it into every agent’s prompt. Treat governance metadata as something your architecture must make available to the consuming experience, and distinguish catalog permissions from access to the underlying data.

Where Fabric Ontology helps

Fabric IQ Ontology, currently in preview, makes business concepts and their connections explicit. I think of it as a business meaning layer that sits above the physical data and describes the business in terms people and AI can understand. I covered Fabric Ontology in more depth in my earlier post, Understanding Fabric Ontology. Entity types describe Customer, Order, and Product; properties describe their facts, relationships connect them, and constraints clarify their meaning. You then bind those definitions to actual data instead of leaving them as a diagram disconnected from the systems people use. Its graph connects instances of those business concepts, providing a shared context layer that supported tools and agents can consume. I would consider it when several sources or teams need a consistent understanding of the same business concepts, not simply because one column has an inconvenient name.

For example, imagine a legacy table with Person_ID, Nm, Addr, and Rev_YTD. In an ontology, you could define Customer with properties such as CustomerID, CustomerName, Address, and YearToDateRevenue, then map the source fields through data bindings. Customer is the business concept; People is one physical representation of it. The mapping tells a consumer how the concept connects to the data without requiring a production-table rename. You still need correct identifiers, agreed definitions, and appropriate source preparation; an ontology does not discover the right business meaning merely because you gave it a clearer label.

The larger benefit appears when relationships span several concepts. Imagine People, SalesHdr, SalesDtl, and Prod represented as Customer places Order, Order contains Order Line, and Order Line references Product. A question such as “Which customers bought products in the Outdoor category?” now has an explicit business path to follow. Microsoft’s ontology and Data Agent tutorial demonstrates adding an ontology as a source so answers can use its definitions and bindings. This differs from repeatedly writing the same explanation in individual prompts: the business meaning layer becomes reusable across consumers that connect to the ontology, rather than each consumer having to rediscover what the underlying data means.

Add context specifically for AI

Power BI’s Prep data for AI, also documented as preview, adds three complementary capabilities to a semantic model. AI data schemas focus attention on relevant model objects, AI instructions explain terminology and analytical rules, and Verified Answers connect common questions with approved visual responses. For example, you might clarify that Revenue means Net Sales Amount and that People represents Customers. These settings belong to the semantic model rather than an individual report. They complement good modeling; they do not replace correct relationships, accurate source values, or well-defined measures. Their role is to reduce ambiguity when supported AI experiences use the model.

Fabric Data Agent configuration addresses how a particular conversational agent should work with its sources. Agent instructions can guide source selection and response formatting, while supported data-source instructions supply local business and query context. Data-source descriptions help distinguish what each source contains, and example queries demonstrate how a business question maps to valid query logic. These are related capabilities inside agent configuration, not separate products. Crucially, support differs by source type: you should not assume that an instruction mechanism available for a warehouse is also available for a Power BI semantic model. That distinction is the focus of the third article.

For supported SQL sources, schema-object descriptions provide more targeted context about individual tables and columns. You could explain that People contains one record per customer and that Person_ID is the customer identifier. This capability requires the Data Agent preview runtime, and descriptions edited in the agent do not overwrite the source object’s description. That is useful when you cannot change a shared source, but it also introduces a maintenance decision. Prefer shared source metadata where appropriate, and use agent-specific descriptions intentionally rather than creating several slightly different definitions of Customer without realizing it.

A third-party tool for measuring AI readiness

BI Pixie’s AI Readiness capability adds another useful question: How do you know whether your Power BI semantic model is actually ready for AI? BI Pixie analyzes semantic models and produces an AI Readiness score, looking for areas such as missing descriptions, ambiguous names, AI data schema configuration, AI Instructions, and implicit measures. It can also recommend improvements for review and provide benchmarking capabilities that let you test Copilot or Fabric Data Agent answers against expected results. BI Pixie is a third-party product rather than a Microsoft-native capability, so I would view it as complementary to the Microsoft tools above. The interesting idea here is that AI readiness becomes something you can assess and repeatedly test, rather than simply configuring a few settings and assuming the job is finished.

Prepare documents for retrieval

Structured analytics is only part of the picture. With Azure AI Search integrated vectorization, an indexing pipeline can retrieve content, split documents into passages, apply enrichment, and generate embeddings for vector search. An embedding is a numerical representation used to find related content; it is not a replacement for the original text or its business definitions. Think of a policy manual becoming searchable passages with titles, dates, section information, and source links. I would describe this as retrieval preparation: making the right supporting material available to an AI system when it needs to answer a question.

Retrieval choices matter alongside document preparation. Full-text search finds matching terms, hybrid search combines text and vector retrieval, and semantic ranking reranks initial results for relevance. These capabilities serve different purposes; they are not substitutes for explaining what a business term means. Azure AI Search also supports synonym maps for equivalent terms in text queries, which can help with approved acronyms or alternate names. A Fabric Data Agent can use an existing Azure AI Search index as a source, currently in preview, but that connection does not remove the need to prepare and maintain the index.

Microsoft Foundry IQ builds on Azure AI Search with reusable, configurable knowledge bases that multiple agents can share. Think of a knowledge base as a managed retrieval layer between an AI agent and the organization’s information. You connect it to sources such as OneLake, SharePoint, Azure Blob Storage, or Azure AI Search, and agents call the knowledge base when they need information. When a user asks a question, Foundry IQ can determine which connected sources are relevant, plan searches, retrieve and rerank useful content, and return grounded information with citations for the agent to use in its response. Instead of connecting every agent separately to every information source, you can create a shared knowledge base once and let multiple agents use the same prepared knowledge. For indexed sources, Foundry IQ can also automate tasks such as chunking, generating embeddings, and extracting metadata. Availability varies by feature and API version, so I would check the current documentation rather than describe the whole offering as either preview or generally available. Foundry IQ manages knowledge retrieval; Fabric Ontology models business concepts and relationships. They address different needs and can be complementary.

Choose the layer that matches the problem

My recommendation is to work backward from a specific question and a specific failure. Incorrect values call for cleaning; unclear calculations call for modeling; ambiguous terminology calls for definitions; missing document evidence calls for retrieval preparation. Use an ontology when shared concepts and relationships justify it, and add agent configuration where the consuming experience needs guidance. You do not need every tool to make one dataset useful for AI. Next, I will explain how Prep data for AI and Fabric Data Agent instructions divide responsibilities—and why the distinction matters.

(This is the first article in a three-part series on making data AI-ready. Part 1 explains what AI-ready data actually means, Part 2 looks at the Microsoft tools that help you get there, and Part 3 explains how Prep data for AI and Fabric Data Agent instructions work together.)

Suppose you ask an AI assistant, “How many customers did we acquire last month?” Your database contains the answer, but the relevant table is called People, its identifier is Person_ID, and the date you need is First_Purchase_Dt. Would you expect someone unfamiliar with that system to immediately know which fields to use? That is the challenge you are handing to AI when you provide access to data without explaining its meaning. Before discussing models, agents, or prompts, I would start with a simpler question: What would someone need to understand this data correctly?

This goes deeper than my earlier post, Getting Your Data GenAI-Ready: The Next Stage of Data Maturity. Here is the definition I would use: “AI-ready data is data that is accurate, well-described, semantically clear, governed, accessible, and enriched with enough business context for AI to interpret it correctly.” Notice that accuracy is only the beginning. A dataset can contain valid values and still leave important questions unanswered about what those values represent. Microsoft’s guidance on preparing data for AI makes the same broader point: reducing ambiguity requires context, not just access. For generative AI, preparation means helping the system find relevant information, interpret it appropriately, and use it within the right boundaries.

Start with the quality of the data

Data cleaning still matters, and I would not skip it because a tool now accepts natural-language questions. Start by looking for duplicate records, missing values, inconsistent spellings, invalid dates, outdated information, and contradictory records. For example, counting customer rows will give the wrong answer if the same customer appears three times and your query does not account for that duplication. Decide what identifies a unique customer before removing anything, because two people with the same name are not necessarily duplicates. This is also where Master Data Management (MDM) can play an important role by establishing trusted, consistent definitions and records for core business entities such as customers, products, suppliers, and locations across multiple systems. An MDM process can help determine which customer record is authoritative, reconcile conflicting values, and create a consistent identity that downstream AI systems can rely on. Tools such as Power Query’s data profiling capabilities can help expose errors, empty values, and unusual distributions before you build an AI experience on top of them.

Standardization also needs business judgment rather than a blanket cleanup rule. Suppose one system stores customer status as A, another uses Active, and a third uses Current; map those values only after confirming that they describe the same condition. A missing revenue amount should not automatically become zero, because “unknown” and “no revenue” are different statements. Document currencies, time zones, date formats, and whether an amount represents dollars or thousands of dollars. Likewise, explain whether a margin value of 0.25 represents 25 percent, and whether a date refers to an order, shipment, or invoice. These decisions belong in the preparation process, not in whatever interpretation the AI happens to choose.

Translate the language of the business

Expanding acronyms is a practical place to start. Instead of documenting only ARR, preserve both forms: ARR — Annual Recurring Revenue, so someone asking with either expression has a clear connection to the same concept. Apply the same approach to abbreviations such as NRR (Net Revenue Retention), ASP (Average Selling Price), ACV (Annual Contract Value), and NPS (Net Promoter Score), using your organization’s actual definitions. Be especially careful with overloaded abbreviations: GM might mean Gross Margin in one dataset and General Manager in another. Descriptive names help, too: cust_id becomes Customer ID, while netrev_qtd becomes Net Revenue Quarter-to-Date. The objective is not to eliminate every abbreviation; it is to make its meaning explicit in the context where it is used.

Now return to the People table. Suppose it contains only customers who have made a purchase, not employees, prospects, or suppliers; document that definition instead of expecting the table name to communicate it. You might describe it as, “One record per purchasing customer; the technical table name is People.” Add customer, client, and buyer as synonyms only where those words really are interchangeable in this system. If the table also contains prospects, then “People means Customers” is incorrect without an additional filtering rule. This is more than renaming: you are mapping system-specific language to an authoritative business concept, sometimes called semantic enrichment or business glossary mapping.

Business definitions need similar care even when the names look perfectly understandable. Consider Active Customer, Revenue, Region, and Churn: what would you calculate for each, and would someone in another department calculate the same thing? In a hypothetical sales system, Active Customer might mean a customer with at least one completed transaction during the previous 90 days. Revenue might mean net sales after returns, while Region might mean the customer’s assigned sales territory rather than their mailing address. Write down those choices, including exclusions and time boundaries. AI instructions in Power BI provide one place to express that context, but you first need agreement on what the definitions should be.

Explain more than the column names

Metadata is where much of this understanding becomes reusable. For each important table, column, measure, or document collection, I would describe its business purpose, source system, owner, refresh frequency, and relevant limitations. Explain the level of detail: does one row represent a customer, an order, an order line, or a monthly snapshot? Include lineage so someone can trace a result back to its origins, and distinguish the authoritative dataset from an experimental copy. Microsoft’s semantic-model optimization guidance emphasizes meaningful names, descriptions, and clear modeling. A label tells you what something is called; useful metadata explains how to interpret and use it.

Relationships deserve the same attention as individual fields. In a simple example, CustomerID in Orders relates to CustomerID in Customers, while Product belongs to Category, which belongs to Business Unit. Documenting those connections tells the consumer how the business fits together, not just where its pieces are stored. Also explain whether one customer can have many orders and whether a customer can belong to more than one segment. Otherwise, a seemingly reasonable join could multiply rows and overstate a total. I would treat relationships, hierarchies, and the meaning of a row as essential context rather than details that the AI should reconstruct from similar-looking names.

Governance belongs in this discussion because useful data must also be appropriate for the person asking the question. Identify sensitive information, clarify ownership, and decide which users should have access to which datasets and results. Microsoft Purview supports the cataloging, lineage, business context, and data-quality work behind those decisions. However, a description saying “confidential” is not a substitute for enforcing permissions in the systems that serve the data. I would make authorized access part of the design from the beginning, rather than adding a sentence to a prompt and assuming the security problem is solved.

Change the data, or explain the data?

There are several ways to supply this meaning, and physically changing the production database is only one of them. You could clean values, standardize codes, or rename fields in a curated dataset, but a legacy application might depend on the original names. In that situation, leave dbo.People alone and expose an AI-friendly view such as vw_Customers, with descriptive fields and the correct customer filtering logic. A semantic model can provide another layer of business-friendly names, relationships, and calculations without requiring a production-table rename. My preference is to fix shared meaning in a reusable layer when practical, so each consuming application does not need its own explanation of the same problem.

You can also leave the data unchanged and provide metadata, definitions, or AI-specific instructions. For example, a description could explain that People contains customers and Person_ID is their unique identifier, while an instruction could explain when to use that information. With Fabric Data Agents, the supported configuration depends on the source; a Power BI semantic model follows a different path from a SQL source. The important distinction is that instructions guide interpretation, whereas cleaning changes values and a semantic layer formalizes meaning. These approaches can complement each other, but an instruction cannot make an incorrect source value correct.

Documents need preparation, too

The same principles apply to policy manuals, contracts, support articles, and other unstructured content. Use meaningful titles and headings, identify owners and effective dates, and distinguish current documents from obsolete or duplicate versions. When splitting documents into smaller passages for retrieval, preserve enough context that a passage still makes sense outside its original page. Microsoft’s guidance on document chunking explains why document structure and chunk boundaries matter. I would retain the document title, section, source link, and applicable product or customer context alongside each passage, rather than handing the AI disconnected sentences and hoping it reconnects them correctly.

Where should you start? Pick a small set of real business questions, identify the data required to answer them, and list everything a knowledgeable employee would need to explain to someone new. Then decide whether each gap needs a quality fix, a business definition, a relationship, retrieval preparation, or an instruction in the appropriate product. Test the answers against an agreed result instead of judging them only by how convincing they sound. In the next article, I will map those needs to Microsoft tools. The goal is not simply cleaner data; it is less guessing about what the data means and how it should be used.

More info:

Microsoft Fabric: AI Needs Clean Data, But What Does That Actually Mean?

What is a Microsoft Fabric data agent?

You build that virtual analyst by connecting selected data sources and supplying the context it needs: agent instructions, data-source descriptions and instructions, a focused schema, and example question-and-query pairs where supported. When a question arrives, the agent considers the question, conversation history, available sources, and those configurations, then creates a plan and decides which configured data source, or combination of data sources, it needs to query. It runs under the caller’s identity, respects underlying source permissions, and generates read-only queries for supported structured sources. The result is returned as a human-readable explanation, table, or insight, with the generated query and run steps available for inspection. That transparency matters because “the AI said so” is not a very useful governance strategy.

Working with structured data

The most familiar Data Agent scenario is asking natural-language questions of structured data. Supported SQL sources include the SQL analytics endpoint of a lakehouse, a Data Warehouse, a SQL database in Fabric, and a mirrored database. At a high level, the built-in natural-language-to-SQL tool uses the selected schema, source instructions, and relevant example queries to generate T-SQL. Fabric validates that the query refers only to approved tables and views, executes it through the SQL analytics endpoint, and turns the results into a natural-language response. The standard runtime provides the generally available version of this flow and is the right place to begin for production scenarios that need predictable behavior.

Connecting a database is only the beginning. A good Data Agent needs a deliberately limited schema, clear business definitions, guidance about relationships and joins, and examples that demonstrate the query patterns people actually use. Otherwise, the model must infer too much from object names that were often created for developers rather than business users (Customer_Agg_02 probably made sense to someone). The more ambiguity you remove before the question is asked, the less guessing the agent must do afterward. Figure 1 shows the structured-data flow, including orchestration, SQL generation, validation, execution, answer generation, and the security controls that apply throughout the process.

Structured data does not have to come directly from SQL sources. A Fabric Data Agent can also use a Power BI semantic model as a source. In that case, the Data Agent uses natural-language-to-DAX (NL2DAX) to translate the user’s question into DAX, validates the query against the selected schema, and executes it against the semantic model. This can be especially useful when your organization has already invested in a well-designed semantic model containing trusted measures, relationships, hierarchies, and business definitions, because the agent can build on that curated semantic layer instead of starting from the underlying tables. Semantic models can be prepared for AI in either Power BI Desktop or the Power BI service using Prep data for AI, which stores AI Data Schemas, AI Instructions, and Verified Answers with the semantic model. These settings can then be reused by Fabric Data Agents and other Copilot experiences that work with the model.

Another structured source is an Eventhouse KQL Database, which is particularly useful for real-time, event-driven, telemetry, log, and time-series data. Instead of generating T-SQL or DAX, the Data Agent can use natural-language-to-KQL (NL2KQL) to translate a user’s question into KQL and query the Eventhouse. This opens up scenarios where the same Data Agent can reason over historical business data alongside operational events or telemetry, rather than treating real-time information as a separate analytical world.

Working with unstructured data through Azure AI Search

Many business questions depend on information that does not fit naturally into rows and columns. The Azure AI Search connection, currently in preview, lets a Fabric Data Agent use an existing search index built from PDFs, Word documents, text files, web pages, and similar content. The indexing pipeline is completed ahead of time; the Data Agent connects to the finished index rather than building it. In the Data Agent configuration for that index, you choose whether to use full-text search, hybrid search, or semantic search, along with how many document chunks to retrieve and context describing what the index contains and when it should be used. The agent retrieves the most relevant content, synthesizes an answer, and can provide citations when the index includes a URL or path field. Figure 2 shows how the finished index is queried and how the grounded answer is produced.

Letting the agent choose—and combine—the right sources

This is where Fabric Data Agents become much more interesting. A single agent can work across as many as five data sources, combining structured data from a Warehouse, Lakehouse, SQL database, or mirrored database; curated business logic from a Power BI semantic model; real-time and event data from an Eventhouse; relationship-oriented data from Graph or Ontology; and unstructured content exposed through Azure AI Search. Data source routing then helps the agent decide which source, or combination of sources, is most appropriate for each question.

The orchestrator uses signals such as the source name, description, selected schema, example queries, and any explicit routing rules in the agent instructions. It can call one source, review the result, and then call another when more information is needed. Azure AI Search participates through the context you provide for the index, so unstructured content becomes another governed tool available to the same agent. Figure 3 illustrates the larger pattern: one agent, multiple sources, and one grounded answer.

A practical example

Consider a repair-warranty question. The warranty policy may be indexed in Azure AI Search, while repair claims, failure codes, service-center details, dates, and costs live in a Fabric Data Warehouse. The agent can retrieve relevant policy passages, query the repair records, compare the rules with each repair, calculate the cost that appears to qualify, and explain which items need review. The final response can include document citations along with the Fabric source and query details, giving the user both an answer and a way to validate it. Figure 4 shows this pattern without pretending that either document search or a database query can answer the entire business question by itself.

Data Agents complement reports and dashboards

A Data Agent is powerful, but it is important not to confuse a conversational answer with a governed report. As I wrote in GenAI vs Dashboards: Not the Same (And Never Will Be), reports and dashboards are still the better choice when you need consistent, repeatable, auditable answers to known business questions. Data Agents are strongest when users are exploring, asking ad-hoc questions, or combining information that was never designed to fit neatly on a dashboard. In simple terms, use reports when you already know the questions and need the same trusted answer every time; use Data Agents when you want the flexibility to ask new questions and follow the data wherever it leads. The future is not Data Agents instead of dashboards. It is knowing when to use each one.

What is the difference between a Data Agent and Copilot?

The technology behind a Fabric Data Agent and Copilot is similar because both use generative AI to reason over data, but they are designed for different jobs. Copilot in Fabric is an assistant embedded in a Fabric experience that can help generate and explain notebook code or assist with queries. Copilot in Power BI can create or edit report pages, summarize reports, and answer questions about a report or semantic model. A Data Agent is a separately configured domain expert that works across selected sources, uses source-specific guidance and examples, and can be published for other people, applications, or agents to call. In simple terms, Copilot helps you perform work in the product, while a Data Agent provides an independently consumable Q&A capability over a defined data domain. Neither replaces the other, and the former direct connection between Copilot in Power BI and Fabric Data Agents was retired in August 2026.

Fabric IQ, integrations, and the Data Agent MCP server

Data Agents are part of the Fabric IQ workload, which is currently in preview, and they are also available as part of the Fabric Data Science workload. Fabric IQ provides shared business context across unified data, business intelligence, operational intelligence, and agents, making Data Agents a natural way to consume that knowledge. Publishing Data Agents to Microsoft 365 Copilot is generally available, and the current Microsoft Copilot Studio integration is also generally available. Integration with Microsoft Foundry and the Data Agent MCP server are still documented as preview. A published Data Agent can expose an MCP endpoint where the whole agent appears as one tool, and its description helps an outside orchestrator decide when that tool is appropriate.

What is coming next?

The roadmap is moving quickly, so pay attention to the runtime and feature status you are using. The preview runtime includes Advanced NL2SQL capabilities such as better example-query following, improved filter handling, schema object descriptions, and clarifying questions when a request is ambiguous. The preview code interpreter provides a sandboxed Python environment for calculations, statistics, forecasting, cross-source analysis, and Python visualizations, while preview Fabric visuals can return interactive charts in the Fabric conversation.

Graph and Ontology are also supported Data Agent sources in preview. Graph is useful when relationships between entities are central to the question, while Ontology adds business context by modeling entities, relationships, and organizational meaning on top of the underlying data. These sources extend the Data Agent beyond simply querying tables by giving it more information about how business concepts relate to one another.

My advice is to start with a narrow domain, curate the sources and instructions carefully, test the questions people really ask, inspect the run steps, and expand only after the answers are consistently trustworthy. The technology provides the reasoning, but your context is what makes that reasoning useful.

First, understand what “running out” means

A Fabric capacity is a pool of compute measured in Capacity Units, or CUs. An F64 provides 64 CUs, an F128 provides 128 CUs, and multiple workspaces and workloads can consume those resources at the same time. Fabric can temporarily let operations use more compute through bursting, then spread that consumption into future time windows through smoothing. I describe smoothing as “buy now, pay later,” except the payment is made with future capacity instead of a credit card. That is why utilization can briefly exceed 100 percent without everything immediately falling apart. If accumulated usage keeps growing, however, Fabric begins throttling work by delaying and eventually rejecting operations.

A short spike and a sustained capacity problem are therefore not the same thing. Fabric is designed to absorb temporary bursts, so a spike in the Capacity Metrics app does not automatically mean you chose the wrong SKU. What matters is whether smoothed usage repeatedly accumulates until users are delayed, operations are rejected, or important workloads are affected by less important ones. I would install the Capacity Metrics app from day one rather than waiting until somebody says, “Fabric is slow.” It lets you trace CU consumption back to workspaces, items, operations, and users, which is where the real decision-making begins.

Set alerts before users tell you there is a problem

Don’t wait for users to tell you that a capacity is overloaded. Set up notifications for capacity usage exceedance so admins or specified contacts are notified when usage exceeds the configured threshold, and use the Capacity troubleshooting guide to investigate and respond when those notifications occur. For more sophisticated or near-real-time monitoring, Capacity Overview Events in Real-Time Hub can be used with Activator to trigger customized alerts when capacity-health measures cross thresholds. The Fabric Capacity Metrics app then helps you investigate utilization, throttling, and which workloads are consuming the capacity.

Choice 1: Optimize

My first question when a capacity is under pressure is simple: are we using the CUs well? Look for inefficient semantic model refreshes, expensive SQL queries, oversized Spark jobs, pipelines running more often than necessary, or development workloads that somehow found their way onto production capacity (they are very social that way). If one item consumes an unreasonable share of the capacity, scaling up may just give that item a larger buffet. Use Capacity Metrics to identify expensive operations and the Fabric Chargeback app if you want workspace owners to understand how much shared capacity they consume. Optimization is usually the cheapest response, but once workloads are reasonably designed and legitimate demand keeps growing, it is time to stop optimizing around the real problem.

Choice 2: Scale up

If the workloads are healthy and the entire capacity needs more compute, scaling up is usually the cleanest answer. One of the nice things about Fabric is how quickly you can change capacity size: Microsoft says that scaling a capacity smaller than F64 up to a larger capacity happens almost immediately, although the associated capacity license update can take up to a day in some cases. You can also scale the capacity back down through Azure when the additional CUs are no longer needed, making resizing useful for both permanent growth and temporary periods of higher demand. Microsoft provides capacity planning guidance and the Fabric SKU Estimator to establish a starting point, but I would still test representative workloads and realistic concurrency rather than treating an estimate as a promise carved into stone. Scaling up works especially well when workloads have similar importance and usage patterns, and the ability to resize quickly means you do not necessarily have to size a capacity for your worst-case demand from day one. But scaling up does not solve the noisy-neighbor problem; if one class of workload should not be allowed to hurt another, you have an isolation problem rather than a sizing problem.

Choice 3: Scale out

Scaling out means adding capacities and distributing workspaces across them. This can cost more and create underused capacity, so I would not give every department its own F SKU just because the org chart has boxes. Instead, group workloads according to criticality and behavior. Production reporting, self-service analytics, development and testing, and large periodic engineering workloads often have very different performance expectations and risk profiles. Separating them lets you apply different capacity sizes, settings, and governance while reducing noisy-neighbor risk. The tradeoff is straightforward: consolidation usually improves utilization and cost efficiency, while isolation improves predictability and protection.

This is where workspace design and capacity design need to work together. A workspace is mainly a boundary for content, ownership, security, and deployment, while a capacity is the compute boundary underneath it. Those boundaries do not need to match one-for-one; dozens of workspaces might share one capacity while a handful of mission-critical workspaces sit on another. Microsoft discusses this consolidation-versus-isolation decision in its capacity planning guidance for decentralized analytics. The key is to isolate because the business impact justifies it, not because more boxes make an architecture diagram look impressive.

Choice 4: Isolate

I like three practical isolation patterns: tryout, timeout, and rescue capacities. A tryout capacity is a small F SKU where new workspaces or items can prove themselves before reaching production; run them there, measure their CU consumption, optimize them if necessary, and promote them only after you understand how they behave. A timeout capacity works in the opposite direction: if a workspace is hurting a shared capacity, move it out while the owner fixes the problem. It is the Fabric equivalent of telling a misbehaving workload to go sit in the corner for a while. Both patterns give you somewhere to deal with risky workloads without making everyone else pay the price.

A rescue capacity protects the workloads you cannot afford to have disrupted. Keep an F SKU paused, resume it during an incident, and temporarily reassign priority workspaces while you deal with whatever is hurting the main capacity. Pausing must be used carefully because Fabric reconciles smoothed usage when a capacity is paused, and OneLake storage continues to be billed. A rescue capacity is therefore not free insurance. But when an hour of disruption would cost far more than maintaining an emergency option, it can be a useful operational tool.

Add guardrails, but don’t confuse them with architecture

Fabric also offers tools that can protect shared compute before trouble spreads. Surge protection can limit excessive background or workspace consumption, while capacity overage (in preview) provides another way to handle excess usage rather than relying only on throttling. Autoscale Billing for Spark can isolate especially bursty Spark compute, and Fabric Copilot capacity can direct Copilot and data agent consumption for selected users to a designated capacity. These are useful capabilities, but I would not enable every option simply because it exists. Each should answer a specific question: what workload am I protecting, what am I isolating it from, and what am I willing to pay to keep it running?

What I would actually deploy

For a typical enterprise, I would start with a general-purpose production capacity sized for normal demand rather than the worst five minutes of the year. I would strongly consider a separate capacity for broad self-service analytics and another smaller capacity for development, testing, and tryout workloads. If critical reporting cannot tolerate disruption, I would consider a paused rescue capacity as well. Large bursty Spark workloads and widespread Copilot usage deserve separate evaluation because Fabric provides specialized ways to handle their consumption. Most importantly, I would review Capacity Metrics regularly, configure alerts so the right people know when a capacity is approaching trouble, and use chargeback or showback to create accountability, and expect the topology to evolve as Fabric adoption grows.

Here is the bottom line: when a Fabric capacity starts running out, “scale up” should not be the automatic response. First determine whether you have a waste problem, a growth problem, or an isolation problem. Optimize waste. Scale up when healthy workloads collectively need more compute. Scale out when different workload classes need separate resource boundaries. Isolate new, problematic, or mission-critical workloads when the business impact warrants it. Then add monitoring and alerts so you find capacity pressure before your users do. Fabric gives you many levers; the architecture skill is knowing which one to pull. The goal is not to guarantee that Fabric never experiences a spike. The goal is to make sure one spike does not become everybody’s problem.

More info:

Microsoft

• Plan Your Microsoft Fabric Capacity: Strategic Guide Overview
• Microsoft Fabric Capacity Planning Guide — Part 1: Plan Your First Deployment
• Microsoft Fabric Capacity Planning Guide — Part 2: Scale for Decentralized Analytics
• Microsoft Fabric Capacity Planning Guide — Part 3: Scale for Centralized Analytics
• Microsoft Fabric Capacity Planning Guide — Part 4: Manage Growth and Governance
• Choose a Microsoft Fabric Deployment Pattern — Azure Architecture Center
• Overload to Optimal: Tuning Microsoft Fabric Capacity

Other blogs

• How to Choose the Best Microsoft Fabric Capacity?
• Microsoft Fabric Workspace Topology Patterns
• Bursting and Smoothing – Yin and Yang of the Fabric Capacity!
• Fabric Capacities Optimization — Everything You Need to Know
• Pausing a Fabric Capacity – What Does It Actually Mean?
• Microsoft Fabric Pricing Model – Everything You Need to Know!
• How to Choose the Right Microsoft Fabric SKU: A Practical Guide for Executives
• Capacity Reservation in Microsoft Fabric: Configuration Guide

Imagine separate Sales, Finance, Shared Data, and Executive Analytics workspaces. Sales owns sales transactions, Finance owns budgets, and Shared Data owns common tables such as Customer, Product, and Date. Executive Analytics needs selected data from all three, but it does not want to copy everything into another lakehouse and maintain another set of pipelines. Instead, it creates shortcuts to the authoritative tables and presents them together in its own lakehouse.

This is where the beauty of Fabric OneLake shortcuts becomes obvious. To a report developer or analyst, the Executive Analytics lakehouse can look like one complete collection of tables. That person might not even know which tables are physically stored there and which are shortcuts—and usually should not need to know. Fabric resolves those paths behind the scenes, which is one reason I call Fabric “the great data unifier”: it can present one logical data estate without forcing all the data into one physical location.

What a OneLake shortcut really does

A OneLake shortcut is a reference to data stored somewhere else. The source can be another Fabric item, workspace, tenant, or cloud storage account, while the shortcut appears as a folder or table in the consuming lakehouse. The data stays at its original location, so you avoid another physical copy and ingestion process. You do not need a shortcut simply because two lakehouses exist; Spark notebooks, pipelines, dataflows, and semantic models can often connect directly when permissions allow. A shortcut becomes valuable when you want selected remote data to appear alongside local data through one organized data surface.

OneLake shortcuts are currently created primarily in lakehouses and KQL databases, although many other Fabric items—including Warehouses, SQL databases, mirrored databases, KQL databases, and other lakehouses—can provide the source data. Warehouses cannot yet generally host standard user-created OneLake table shortcuts, but that is expected to change. Microsoft has Shortcuts in Fabric Data Warehouse on the roadmap for public preview in Q4 2026. The planned feature will allow users to create table shortcuts directly inside a Fabric Warehouse through T-SQL or the Fabric user interface, making internal and external data queryable without first loading it into the Warehouse. As with all roadmap items, the timing and details can change.

Same workspace, different workspace, or different tenant?

Within the same workspace, T-SQL can often query another lakehouse, warehouse, or mirrored database by using cross-database three-part naming, such as Database.Schema.Table. Across workspaces in the same tenant, Spark can also access another lakehouse directly when the user has permission, so another workspace does not automatically mean you need a shortcut. The decision changes when you want a remote table to appear through the consuming lakehouse’s SQL analytics endpoint. That endpoint discovers Delta tables registered in its lakehouse, including tables exposed through shortcuts. To make a Delta table from another workspace available through the current SQL endpoint—and therefore through the usual Power BI and Direct Lake table experience—create a shortcut under Tables.

This is how shortcuts appear in Explorer under SQL analytics endpoint, with a small paperclip-looking icon:

Across tenants, use a formal sharing pattern. Fabric External Data Sharing lets one organization share live, read-only OneLake data with another tenant without copying it. The recipient accepts the share and chooses a lakehouse, where Fabric creates a shortcut pointing back to the source. This gives the receiving organization current data without requiring a duplicate ingestion pipeline.

Tables versus Files

Where you create the shortcut matters. A regular shortcut under Files can point to any file format; Microsoft does not publish a finite extension list because the shortcut exposes the file or folder rather than interpreting it. Examples include CSV, TSV, PSV, TXT, JSON, JSONL, NDJSON, Parquet, XML, Avro, ORC, Excel, PDFs, Office documents, logs, images, audio, video, and other binary files. Whether a workload can process a file depends on whether that workload understands its format.

A Files shortcut is useful to Spark and other file-aware tools, but it is not automatically a table. The lakehouse SQL analytics endpoint, Direct Lake, and the normal Power BI lakehouse table experience expect registered Delta tables under Tables. To use raw files through those table-oriented experiences, transform or load them into Delta; the Files shortcut itself does not make them SQL-queryable. A shortcut under Tables is intended for table behavior, and its source should normally be a valid Delta table containing Parquet data files and a Delta transaction log. A folder containing only Parquet files is not a Delta table. Once registered under Tables, the shortcut can be consumed through Spark, SQL, Power BI, and Direct Lake.

Handling raw files

If file-level access is sufficient, create a shortcut under Files and process the data with Spark. If the files need to become a queryable table, use a shortcut transformation. It can copy and convert homogeneous CSV, TSV, PSV, delimited TXT, JSON, JSONL, NDJSON, Parquet, or Excel files into a managed Delta table synchronized with the source. Because Fabric creates a Delta output, this is not completely zero-copy. Shortcut transformations are convenient, but they do not replace Data Factory pipelines, copy jobs, dataflows, notebooks, or eventstreams when you need complex joins, business rules, custom orchestration, or movement outside OneLake (sadly, we still have jobs).

AI-powered shortcut transformations

Fabric also supports AI-powered shortcut transformations for unstructured .txt files. These built-in transformations can summarize content, detect sentiment, translate languages, detect and redact personally identifiable information, or extract named entities such as people, organizations, and locations. Fabric checks the source folder every two minutes and keeps the resulting queryable Delta table synchronized as files are added, modified, or deleted. The feature is currently in public preview and supports only .txt input, so it is best suited to targeted text-processing scenarios rather than as a general replacement for Fabric AI Functions or a complete data-engineering pipeline. I blogged about this at Microsoft Fabric shortcut‑based AI transformations.

What about Iceberg?

Apache Iceberg is supported through OneLake metadata virtualization. When you create a table shortcut to a supported Iceberg table, OneLake generates virtual Delta metadata so Fabric workloads can use it without rewriting the underlying Iceberg data. This is especially helpful with Snowflake-managed Iceberg tables stored in ADLS, Amazon S3, Google Cloud Storage, OneLake, or supported S3-compatible storage. Snowflake can remain the system of record and primary writer while Fabric reads the same data through a shortcut. I cover the architectural choices in Three Ways to Use Snowflake Data in Microsoft Fabric.

The tradeoffs: performance, caching, and source dependency

Shortcuts are useful, but they have tradeoffs. Because the data stays at the source, performance can depend on its location, network latency, file design, availability, and the engine reading it. Creating a shortcut does not preload or copy the complete target into the consuming lakehouse. The data is fetched when a workload requests it, so the first or “cold” read—particularly from an external cloud or on-premises source—can be slower than reading a local copy.

For supported external shortcuts, OneLake shortcut caching can reduce this penalty for repeated reads. Caching is enabled at the workspace level and currently supports Google Cloud Storage, Amazon S3, S3-compatible storage, and shortcuts accessed through the on-premises data gateway. As OneLake reads an eligible file, it fetches that file from the remote source and stores it in the workspace cache. Later requests can be served from the cache instead of crossing the network again. The cache fills file by file as users access the data—it is not populated when the shortcut is created.

Cached files can be retained for one to 28 days, and each access resets the retention period. If the source has a newer version of a file, OneLake retrieves that version and refreshes the cached copy. Individual files larger than 1 GB are not cached. This cache is separate from engine-specific caching, such as Spark intelligent cache or Direct Lake loading data into memory. Caching can improve repeated-query performance and reduce cross-cloud egress costs, but it does not guarantee that a shortcut will perform exactly like a locally stored table.

Sources that do not support OneLake shortcut caching, such as ADLS Gen2, can still benefit from caching within the Fabric engine that consumes the data. Spark intelligent cache can store accessed data on the local SSD cache of each Spark node. Direct Lake loads the columns needed by a query into the semantic model’s VertiPaq memory, while the SQL analytics endpoint transparently caches accessed data in memory and on local SSD. Therefore, running the same or a similar query again does not necessarily mean that all the data must be retrieved from the original source again.

These engine-specific caches are separate from OneLake shortcut caching. They are workload-specific, can be evicted when resources are needed elsewhere, and might not be available to a different engine querying the same shortcut. If the required data is no longer cached, has changed at the source, or was not accessed by the earlier query, the engine retrieves it from the source again. The performance benefit therefore depends on which engine is used, how much data is repeatedly accessed, and whether that data remains in the relevant cache.

Performance is not the only tradeoff. A shortcut depends on the source path, permissions, schema, and availability. Moving or deleting the target can break the shortcut, and source schema changes can affect downstream consumers. You also do not have the same control over Delta table maintenance that you have with a locally owned table. When predictable performance, independent availability, regional residency, or complete maintenance control matters more than zero-copy access, copying or replicating the data can be the better decision.

Should you create a central shared-data workspace?

A shared workspace can be a strong pattern for genuinely reusable and governed data, such as Customer, Product, Date, Currency, or organizational reference tables. Other workspaces can shortcut to only what they need, providing one authoritative source without duplicate copies. However, do not turn that workspace into a dumping ground for every table another team consumes. The better design is usually a hybrid: keep enterprise-wide conformed data in a shared workspace, keep specialized data with the domain that owns it, and let consumer workspaces shortcut directly to those sources. An executive lakehouse can then combine local tables with shortcuts to Sales, Finance, and shared dimensions while presenting users with one clean experience.

Shortcuts, Mirroring, or Data Factory?

Use a shortcut when the source is in an open format such as Delta or Iceberg and virtual access satisfies your performance, security, availability, and control requirements. Use Mirroring when you want an external database or catalog represented in Fabric. When a source stores data in a proprietary database format, Mirroring replicates the selected data into OneLake as analytics-ready Delta tables; when a supported source already uses an open format, Mirroring can reference that data in place through shortcuts. Once the source is available through a mirrored database, other workspaces can shortcut to selected tables without creating more copies—“mirror once, shortcut many times.” Use Data Factory when Mirroring does not support the source or when you need substantial transformation, orchestration, custom scheduling, or destination control.

A practical decision tree

Is the source already Delta or Iceberg?
    Yes → Use a shortcut when you want zero-copy access.
    No  → Continue.

Is the source CSV, JSON, Parquet, or Excel files?
    Yes → Need only Spark or file-level access?
              Yes → Create a Files shortcut.
              No  → Use a shortcut transformation or load into Delta.
    No  → Continue.

Is the source unstructured .txt files?
    Yes → Do you need summarization, translation, sentiment analysis, PII redaction, or named-entity extraction?
              Yes → Consider an AI-powered shortcut transformation.
              No → Use a Files shortcut or another text-processing tool.
    No → Continue.

Is the source a supported operational database?
    Yes → Need ongoing replication into Fabric?
              Yes → Use Mirroring.
              No  → Use Data Factory for controlled movement.
    No  → Use Data Factory, a notebook, a dataflow, or another ingestion method.

The bottom line

Use shortcuts to make selected, trusted data appear where consumers need it without another unnecessary copy. They can give users one clean lakehouse experience across workspaces, domains, clouds, and tenants, often without users realizing shortcuts are involved. In plain English, shortcuts let a lakehouse present data owned elsewhere as part of its own organized table and folder structure. Users see the data they need, while OneLake handles where it actually lives. However, the source still matters: its location, performance, permissions, availability, and file design can affect the experience. Shortcut caching can improve repeated reads for supported external sources, but it does not preload every file or make every shortcut behave exactly like local storage. Fabric may be “the great data unifier,” but good architecture still requires deciding when virtual access is enough and when a physical copy is worth it.

This post is a complete replacement for and update to my April 2022 post, Power BI Performance Features. That post focused on several performance features that were new or in preview at the time. Four years later, many of those features have matured, Microsoft Fabric has changed the architecture choices available to us, and Direct Lake has become an important part of the conversation. So rather than keep adding notes to an old feature list, I decided to step back and answer the more useful question: How should you design, diagnose, and improve Power BI performance today?

Here’s the bottom line: Power BI performance is not one feature, one setting, or one capacity size. It is the result of a chain that includes the data source, data preparation, storage mode, semantic model, DAX, report design, security, refresh process, and Fabric capacity. A weakness anywhere in that chain can become the bottleneck, which is why randomly changing DAX or buying more capacity often does not solve the real problem. The best approach is to make the right architectural choices first, measure what is slow, and then fix the layer that is actually causing the delay. For more info, see Optimization guide for Power BI.

Start by choosing the right storage mode

The first major decision is how Power BI will access the data. Import, Direct Lake, and DirectQuery are table storage modes, while composite models and hybrid tables are architectures that combine storage modes in different ways. This distinction matters because people sometimes compare all five as though they are equivalent choices. They are related, but they answer different questions: a storage mode tells Power BI how to query a table, while a composite or hybrid design tells you how those modes are arranged across a model or within a table.

There is no universally best storage mode, and that is not a very satisfying answer until you look at the requirements. Import should usually be your starting point because it offers fast in-memory queries and the broadest modeling flexibility. Direct Lake becomes especially attractive when the curated data already lives in Fabric and is too large or changes too often for a traditional import process. DirectQuery is appropriate when there is a specific reason to query the source at report time, but it should not be selected simply because the source contains a lot of data. For more info, see DirectQuery in Power BI and Direct Lake overview.

Import mode: still the right default for many models

Import mode remains the simplest path to consistently fast report interaction. Data is compressed and stored in the semantic model, and report queries are answered by the VertiPaq engine instead of repeatedly going back to the source. That separation is valuable because a report user can click a slicer without waiting for a database, network connection, or gateway to respond every time. Import also gives model authors the richest set of Power Query and DAX capabilities, which is one reason Microsoft continues to recommend starting with Import unless size, latency, governance, or another specific requirement pushes you elsewhere.

The tradeoff is that imported data is only as current as the latest refresh, and a large model needs memory both when it is queried and when it is refreshed. The answer is not automatically to abandon Import; it is often to import less data, reduce unnecessary columns, use appropriate data types, pre-aggregate where practical, and configure incremental refresh for large fact tables. High-cardinality text columns can consume surprising amounts of memory, while columns that nobody uses still have to be stored, processed, and refreshed, so the simplest optimization may be to remove them. For more info, see Data reduction techniques for Import modeling.

Direct Lake: a major Fabric-era option

Direct Lake is a Power BI table storage mode designed for Delta tables in OneLake. Like Import, it uses the VertiPaq engine to process report queries, but it does not create and maintain a traditional full copy of the source data inside the semantic model. A Direct Lake refresh is primarily a metadata operation called framing, which updates the model’s references to the latest Delta table files. This can reduce the time and resource cost associated with making new data available, especially when the source contains a large amount of curated data in a Fabric lakehouse or warehouse.

Direct Lake is not a universal replacement for Import, and bypassing a traditional full import does not make every model automatically fast. Its performance depends on the layout and health of the underlying Delta tables, including file counts, row groups, and table maintenance, as well as model design and available capacity. For new models, Direct Lake on OneLake is the recommended Direct Lake option; unlike Direct Lake on a SQL endpoint, it does not fall back to DirectQuery when a request cannot be served directly from Delta tables. You should still build a proof of concept with realistic data volumes and concurrency rather than assuming the architecture will behave perfectly on the first try. For more info, see Direct Lake overview and Cross-workload table maintenance and optimization.

Direct Lake also shifts more of the data-preparation work to the layer before the semantic model. Instead of creating every transformation inside Power BI, you would typically build cleaned dimension tables, reusable business logic, and summarized fact tables in a Fabric lakehouse or warehouse, where they can be shared by multiple semantic models and other workloads. This is generally a good architectural approach, but it requires the data engineering team and the semantic model developers to work closely together. Even a well-designed semantic model cannot fully overcome poorly organized Delta tables, excessive numbers of small files, or inefficient table structures underneath it. For more info, see Develop Direct Lake semantic models.

DirectQuery: use it for a reason

DirectQuery keeps data in the source and sends queries to that source when users interact with a report. It is useful when data must remain at the source, when source-enforced security is required, when the data changes more quickly than an Import model can reasonably be refreshed, or when the dataset is so large that importing the required level of detail is not practical. By “not practical,” I mean that the data may be too large for the available semantic model or capacity limits, may require too much memory, or may take too long to load and refresh within the available refresh window. In those situations, DirectQuery may be the best option because Power BI can query only the necessary rows from the source instead of copying the entire detailed dataset into the semantic model. The important phrase, however, is “when required.” DirectQuery is not simply Import without a refresh; it changes the performance contract because every visual can depend on the source system, network latency, gateway overhead, and the workload created by every other user. It also depends heavily on query folding, which is the process of translating Power Query transformations into queries that the source system can execute. When query folding works well, filtering, joining, and other processing happen at the source; when it does not, Power BI may need to retrieve more data or perform more work itself, which can significantly reduce performance.

Before choosing a fully DirectQuery model, consider whether incremental refresh, a hybrid table, Direct Lake, or aggregations can meet the requirement with less runtime dependency on the source. If DirectQuery is the right choice, begin by testing representative source queries under realistic concurrency, not just by opening one report when nobody else is using the system. Make sure transformations fold, filter data as early as possible, optimize joins and common predicates, and return only the columns and rows that the report needs. A slow source query does not become fast because Power BI generated it, and increasing the number of simultaneous queries can sometimes make the source slower rather than faster. For more info, see DirectQuery model guidance in Power BI Desktop and Understanding query evaluation and query folding in Power Query.

Report design matters even more with DirectQuery because user actions create source activity. A page with many visuals, several slicers, cross-highlighting, and expensive totals can send a substantial collection of queries from one click. Use query-reduction options, Apply buttons for slicers and filters, and fewer interactions when they improve the experience. There is no magic number of visuals that is always safe, because a simple card and a detailed matrix do very different amounts of work, but every visual should earn its place on the page. For more info, see Optimize ribbon in Power BI Desktop.

Composite models and hybrid tables are not the same thing

A composite model is a semantic model that contains tables using different storage modes, or DirectQuery tables that belong to different source groups. For example, a model might use Import for small dimension tables and DirectQuery for a very large fact table, or combine Direct Lake tables with an imported planning table. Composite models provide flexibility at the table level, but they also introduce more execution paths, relationship considerations, and opportunities for queries to cross storage modes or data sources. In a model that combines Import and DirectQuery, a shared dimension table can be configured with Dual storage mode, which allows Power BI to treat the table as either Import or DirectQuery depending on the query. This can improve performance by letting Power BI answer queries from the in-memory copy when possible, while still allowing the dimension to participate correctly in queries that must be sent to the DirectQuery source. Dual mode should be used deliberately for shared dimension tables, rather than applied to every table by default.

A hybrid table is much more specific. It is one table with one or more Import partitions and a single DirectQuery partition, usually created by configuring incremental refresh and enabling the option to get the latest data in real time. Historical rows are answered from fast in-memory partitions, while the newest time window is queried from the source. A semantic model containing a hybrid table is therefore composite, but most composite models do not contain a hybrid table. You may hear the phrase “hybrid model” in conversation, but the official Power BI feature is a hybrid table, and keeping that terminology straight makes architecture discussions much easier.

The easiest way to remember the difference is this: composite is model-level, while hybrid is table-level. Use a composite model when different tables genuinely require different access patterns or data sources. Use a hybrid table when one time-partitioned fact table needs imported history and near-real-time recent data. In either case, test queries that cross the storage boundaries, because those are often the queries that reveal design problems. For more info, see Use composite models in Power BI and Semantic model modes in the Power BI service.

Incremental refresh: refresh what changed, not everything

Incremental refresh partitions a table so Power BI can refresh a recent range instead of repeatedly reloading the entire history. This is especially valuable for large fact tables in which older rows rarely change, because the refresh process can focus on the newest or recently updated partitions. It reduces refresh time, source load, and capacity consumption, while also making it practical for an Import semantic model to retain more history. With supported capacity, the policy can also include a DirectQuery partition for the latest data, which is how the common hybrid-table design is created.

Incremental refresh does not rescue a poorly designed ingestion query. The date filters used by the policy must reach the source efficiently, and the Power Query transformations should fold whenever the connector and source support folding. Check the generated native query, filter early, avoid unnecessary columns, and confirm that the source can isolate the requested date range without scanning everything. Also plan the initial historical load carefully, because the first refresh still has to populate the partitions before subsequent refreshes receive the full benefit. For more info, see Configure incremental refresh and real-time data for Power BI semantic models and Best practices when working with Power Query.

Aggregations: answer common questions with less work

User-defined aggregations can dramatically improve a DirectQuery model when users repeatedly ask questions at a summarized grain. Instead of sending every query to a very detailed fact table, Power BI can answer eligible queries from a smaller imported aggregation table. If you worked with aggregations in SSAS Multidimensional, the basic idea will feel familiar: the engine tries to answer common summarized queries from a pre-aggregated structure instead of repeatedly scanning detailed data. The implementation is different, however, because Power BI typically uses a separate aggregation table that is mapped to the detailed table through aggregation properties, relationships, and measures. This works best when you understand the common query patterns and create aggregation tables that reflect how people actually use the reports.

Automatic aggregations take a more managed approach by using query history and machine learning to create and maintain in-memory aggregations for eligible DirectQuery semantic models on supported capacity. They can reduce the specialized modeling effort required to identify useful aggregates, but they are not a reason to ignore the source or the model. You still need representative usage history, enough capacity headroom, and a DirectQuery design that behaves correctly when a query cannot hit an aggregation. For more info, see User-defined aggregations and Automatic aggregations overview.

Query caching is a different feature and should not be confused with aggregation tables. For eligible Import semantic models on supported dedicated capacity, it can cache results for the initial report page a user opens, with results kept in the appropriate user and security context. It does not cache every interaction a user performs after the page opens, and it does not turn a slow model into a fast one. Think of it as a useful optimization for repeated landing-page queries, not as a substitute for good modeling or DAX. For more info, see Query caching in Power BI Premium or Power BI Embedded.

Build a semantic model that can be fast

A star schema remains the best starting point for most Power BI semantic models. Dimension tables describe the things you filter and group by, while fact tables contain the events or measurements you summarize. This structure gives users a model that is easier to understand and gives the engine clear, efficient relationship paths. A complicated web of tables may feel flexible while you are building it, but that flexibility often becomes ambiguity, slower queries, and DAX that has to work around the model instead of working with it.

Model size matters because every unnecessary byte has a cost somewhere: refresh, memory, eviction, paging, or query scanning. Remove columns and rows that have no reporting purpose, use numeric keys where practical, choose appropriate data types, avoid storing excessive precision, and pay special attention to high-cardinality text columns. Disable automatic date/time when an explicit date dimension is the better enterprise design, and avoid calculated columns that materialize values you could create upstream or calculate efficiently as measures. None of these choices is glamorous, but performance work is often a collection of sensible decisions rather than one dramatic setting.

Relationships deserve the same discipline. Prefer clear one-to-many relationships from dimensions to facts, and minimize bidirectional filtering because it can add processing and create confusing filter behavior. Many-to-many and bridge-table patterns are sometimes necessary, but they should represent a real business relationship rather than repair an unclear model after the fact. Row-level security also adds filters to queries, so design it around efficient dimensions and relationships, then measure performance both with and without the intended role applied. For more info, see Understand star schema and the importance for Power BI, Bi-directional relationship guidance, and Row-level security guidance.

Tune DAX after you identify the slow query

It is tempting to start performance tuning by rewriting the most complicated-looking measure. Sometimes that is the right measure, but sometimes the delay is visual rendering, a source query, a relationship path, or another visual that is blocking the page. Start with Performance Analyzer, find the slow visual, and capture the DAX query it is actually running. Then use DAX query view to test changes in the same filter and grouping context instead of guessing from the measure definition alone.

Once you have identified the DAX bottleneck, look for repeated expressions, unnecessary iteration over large tables, expensive context transitions, filters operating at the wrong grain, and calculations that could be simplified by a better model. Variables can improve readability and avoid reevaluating the same expression, while Boolean filter arguments to CALCULATE can be more efficient than wrapping an entire table in FILTER when the requirement allows it. FILTER is not “bad,” and iterators are not “bad”; they are tools that become expensive when they evaluate more rows or more complex logic than the result requires. For more info, see Use variables to improve your DAX formulas and Avoid using FILTER as a filter argument.

Design report pages with a performance budget

Every visual has a cost. It can issue one or more queries, wait behind other work, render data in the browser, and trigger additional queries when the user changes a slicer or cross-highlights another visual. A page with fewer purposeful visuals is usually easier to understand and often faster than a page trying to answer every possible question at once. Detailed tables and matrices deserve special attention because they can request large result sets, expensive subtotals, and distinct counts that users may not need on the opening page.

Use drillthrough, tooltips, bookmarks, and navigation to reveal detail when it is needed instead of loading everything immediately. For DirectQuery reports, use query-reduction features and Apply buttons so a user can make several selections before Power BI sends new queries. Review visual interactions and disable those that do not add business value, especially when one click causes every visual on the page to recalculate. Then test the report as a user would use it, including common slicer paths, mobile layouts if applicable, row-level security, and the actual capacity where it will run. For more info, see Optimize ribbon in Power BI Desktop.

Large semantic models and high concurrency solve different problems

The large semantic model storage format allows semantic models on supported Fabric capacities to grow beyond the default size limit of 1 GB. This limit refers to the size of the compressed semantic model stored in the Power BI service, not the original amount of data in the source system. With the large storage format enabled, the model can grow up to the limit supported by the Fabric capacity or a lower limit configured by the capacity administrator. For example, a 5-GB Import model would exceed the default 1-GB limit, but it could be supported on an appropriately sized Fabric capacity with the large semantic model storage format enabled. The format also supports XMLA-based write operations and provides more flexibility for managing large models in the service. However, making a larger Import model possible does not make it free: the model still requires memory, refresh processing, sensible partitioning, and enough capacity headroom. Incremental refresh becomes especially important because it allows Power BI to process only the partitions that have changed instead of repeatedly processing the entire model.

Semantic model scale-out addresses a different challenge: many concurrent users querying the same semantic model. It can distribute report queries across one or more read-only replicas while the primary read-write replica handles refreshes and other write operations. For example, users can continue querying a read-only replica while the primary replica processes a refresh, reducing the effect of that refresh on interactive report performance. Scale-out can increase query throughput and help support a larger number of simultaneous users, but it does not make an individual inefficient DAX query run faster. That distinction is important because model size, single-query performance, refresh pressure, and concurrent-user demand are separate problems that may require different solutions. For more info, see Large semantic models in Power BI Premium and Power BI semantic model scale-out.

Diagnose the bottleneck before changing the architecture

Performance Analyzer should be one of the first tools you open when a report feels slow. It records how long each visual takes and separates the time into categories such as the DAX query, DirectQuery activity, visual display, and other processing. That breakdown tells you whether to investigate the measure and model, the underlying source, the visual itself, or contention from other work. You can copy the query or run it in DAX query view, which gives you a repeatable way to inspect results, change measure definitions, and compare behavior.

The Optimize ribbon is useful while building a report because you can pause visual queries instead of waiting for every visual to refresh after each model or formatting change. This is especially helpful with DirectQuery models, where report development itself can generate a surprising amount of source activity. It also exposes optimization presets and query-reduction options, helping you design the interaction pattern rather than accepting the default behavior for every page. For more info, see Use Performance Analyzer to examine report performance, Work with DAX query view, and Optimize ribbon in Power BI Desktop.

When performance is good in Power BI Desktop but inconsistent in the service, examine the Fabric capacity rather than assuming the report changed on the way up. The Fabric Capacity Metrics app shows capacity-unit consumption, utilization over time, throttling, rejected operations, and the items or operations contributing to load. Look for overlap between refreshes, data engineering workloads, and peak report usage, because a well-designed model can still struggle when the capacity has no room left to serve it. Scaling capacity may be the correct decision after you understand the evidence, but scaling first can simply make an inefficient design more expensive. For more info, see What is the Microsoft Fabric Capacity Metrics app? and Evaluate and optimize your Microsoft Fabric capacity.

A practical Power BI performance workflow

When a report is slow, I would work through the problem in the following order. This sequence moves from evidence to architecture instead of starting with the most expensive or disruptive change. You may find the issue in the first few steps, which is much better than rebuilding the model and discovering that one visual was the real culprit. It also gives you a record of what you measured and why you changed something, which will help when another report develops similar symptoms later.

1. Reproduce the slow experience using realistic filters, security, data volume, and capacity conditions.
2. Use Performance Analyzer to identify the visual and determine whether the delay is DAX, DirectQuery, rendering, or waiting on other work.
3. Test the captured query in DAX query view and compare changes rather than relying on impressions.
4. Review the semantic model: star schema, relationships, cardinality, unnecessary columns, data types, calculated columns, and row-level security.
5. Review the storage mode and confirm that Import, Direct Lake, DirectQuery, composite, or hybrid architecture matches the actual freshness, scale, and governance requirements.
6. For source-dependent queries, verify query folding and inspect the generated source query, source execution plan, indexing or table layout, and concurrency behavior.
7. Reduce unnecessary report work by simplifying visuals, interactions, detailed results, and slicer behavior.
8. Review refresh schedules, incremental-refresh policies, and overlap with peak interactive usage.
9. Use the Fabric Capacity Metrics app to check capacity pressure, throttling, and competition from other workloads.
10. Scale capacity only after the measurements show that efficient workloads still need more resources.

The order is not a law, but the principle is important: measure before you redesign, and redesign before you simply spend more. Performance problems often cross team boundaries, so involve the report author, semantic model owner, data engineer, source-system owner, and capacity administrator when the evidence points to their layer. The goal is not to make one benchmark look good in isolation; it is to create a reliable experience for real users under real workload conditions. For more info, see Optimization guide for Power BI.

Final thoughts

Power BI now gives us more ways to balance speed, scale, freshness, governance, and cost than it did when I wrote the original post in 2022. Import remains an excellent default, Direct Lake is a major option for Fabric-centered solutions, DirectQuery still has important use cases, and composite and hybrid designs let you mix behaviors when the requirements truly call for it. Incremental refresh, aggregations, query caching, large-model support, and scale-out can all help, but each one solves a particular kind of problem. The hard part is not finding a performance feature; it is matching the feature to the bottleneck.

Here’s the advice I would leave you with: keep the model simple, choose storage modes deliberately, prepare data at the right layer, and measure the actual user experience. Do not assume that the newest architecture is automatically the fastest, or that a larger capacity can repair every design problem. Power BI performance is usually won through a series of clear decisions made from the source all the way to the visual. That may not sound as exciting as one performance setting, but it is much more likely to work.

More info:

Power BI DirectQuery Mode: A Better Choice Than You Might Think

At its simplest, a copilot is an AI assistant that lets you describe what you are trying to accomplish in natural language. It can help generate, summarize, explain, analyze, and transform information, and some Copilot experiences can also use tools or take actions on your behalf. The real value is not simply that you can type a question into a chat box. It is that Copilot can reduce the distance between knowing what you want to do and knowing every command, menu, formula, language, or product feature required to do it.

That makes Copilot useful to both beginners and experienced professionals, although often for different reasons. A beginner can use it to get past the intimidating blank screen and learn how a product works, while an expert can use it to accelerate repetitive work, explore alternatives, and stay focused on the larger problem. The benefit becomes much greater when Copilot is grounded in useful context, such as the document you are editing, the meeting you attended, the report you are viewing, the data model behind it, or the code in a repository. Of course, better context does not make AI infallible (we have not reached that happy day), so generated content, queries, calculations, and recommendations still need human review.

The naming can be confusing because several related products use the Copilot name. Microsoft Copilot is the general-purpose AI companion intended primarily for personal use. Microsoft 365 Copilot is the work-focused experience that connects AI with Microsoft 365 applications and, depending on licensing and permissions, organizational information available through Microsoft Graph. Microsoft 365 Copilot Chat is the conversational entry point for work, but what it can access and do varies depending on the user’s license and the organization’s configuration. These products are related, but they are not interchangeable.

The other Copilot experiences are usually shaped around a specialized job. GitHub Copilot focuses on software development, while the Copilot experiences in Microsoft Fabric and Power BI are designed around data, analytics, and business intelligence workflows. Copilot Studio is different again: rather than being only an assistant you use, it is a platform for creating and managing custom agents connected to an organization’s knowledge, systems, and processes. A useful way to think about this is that Copilot is often the front door, while agents are the specialists that can be brought into the conversation to handle a particular task.

The easiest way to understand the Microsoft Copilot landscape is therefore not to memorize every product name. Start by asking where you are working, what context Copilot can access, what permissions it inherits, and whether you need assistance, content generation, analysis, development help, or an agent that can perform a more specialized job. The sections below organize the major Copilot experiences by the products and workloads in which they appear, beginning with the broad set of data and analytics capabilities available in Microsoft Fabric. These cover the Copilot experiences most relevant to productivity, data, analytics, agents, and development (and does not cover areas such as GitHub Copilot in SQL Server Management Studio (preview), Microsoft Copilot in Azure, Microsoft Security Copilot, Copilot in Power Apps, Power Automate and Power Pages, and some Microsoft 365 surfaces such as OneNote, OneDrive, and SharePoint).

Copilot and AI in Microsoft Fabric

(see What is Copilot in Fabric?)

Copilot in Power BI / Fabric chat experiences (consume data agent preview)

• Ask natural-language questions about reports, semantic models, and Fabric data agents
• Discover relevant analytics content
• Generate summaries, explanations, and insights
• Interact with data using conversational analytics
• Learn more: Copilot for Power BI overview, Ask Copilot questions about your data, Consume a Fabric data agent from Copilot in Power BI

Copilot for Power BI report authoring

• Create report pages using natural language
• Generate visuals and narrative summaries
• Summarize report findings
• Accelerate report development
• Learn more: Create and edit Power BI reports with Copilot

Copilot in Power BI web modeling / semantic models (preview for web modeling)

• Analyze semantic models and identify improvement opportunities
• Assist with DAX query and measure-related work
• Generate measure descriptions
• Rename tables and columns
• Create or modify relationships
• Apply semantic modeling best practices with AI assistance
• Learn more: Use Copilot with semantic models in Power BI, Edit semantic models in the Power BI service

Copilot for Data Engineering and Data Science (preview)

• Generate Spark, Python, and notebook code
• Explain existing code
• Troubleshoot errors with Fix with Copilot
• Assist with data exploration, preparation, and machine learning workflows
• Learn more: Copilot for Data Engineering and Data Science overview, Use the Copilot chat pane in Fabric notebooks

Copilot for Data Factory

• Generate Dataflow Gen2 transformations
• Create pipelines from natural-language descriptions
• Summarize pipelines
• Troubleshoot pipeline errors with explanations and recommendations
• Learn more: Copilot in Fabric Data Factory overview, Get started with Copilot in Data Factory

Copilot for Data Warehouse and SQL analytics (preview)

• Generate T-SQL queries from natural language
• Use AI-assisted SQL code completion
• Explain SQL code and warehouse schema
• Fix query errors and suggest SQL best practices
• Accelerate analytics development across Fabric Warehouse and SQL analytics endpoint scenarios
• Learn more: Copilot in the Data Warehouse workload, Use the Copilot chat pane in Fabric Data Warehouse, Use Copilot code completion in Fabric Data Warehouse, Copilot for SQL analytics endpoint announcement

Copilot for SQL database in Fabric

• Generate SQL queries from natural language
• Use AI-assisted SQL code completion in the SQL query editor
• Explain SQL code and database schema
• Fix SQL errors with quick actions
• Ask documentation-based questions about SQL database capabilities
• Accelerate database development, operations, and troubleshooting
• Learn more: Copilot in SQL database in Fabric, Use the Copilot chat pane in SQL database in Fabric, Copilot FAQ for SQL database in Fabric, Release status of AI and Copilot experiences in Fabric

Copilot for Real-Time Intelligence

• Generate and refine KQL queries
• Explore streaming, event, and log data
• Build real-time insights and dashboards
• Learn more: Copilot for Real-Time Intelligence, Copilot-assisted real-time data exploration

Fabric Data Agents

• Create conversational AI experiences over enterprise data
• Query Fabric data sources using natural language, including lakehouses, warehouses, Power BI semantic models, KQL databases, ontologies, Microsoft Graph, and other supported sources
• Publish data agents for business users
• Integrate with Microsoft 365 Copilot, Copilot Studio, Power BI experiences, and other supported agentic consumption paths
• Explore agentic analytics and multi-agent scenarios
• Learn more: Fabric data agent overview, Create a Fabric data agent, Consume Fabric data agent in Microsoft 365 Copilot, Consume Fabric data agent in Copilot Studio

Also: Copilot in Power BI apps, Copilot in Power BI Mobile (preview), Copilot in securely embedded Power BI reports

Copilot outside of Microsoft Fabric

Microsoft 365 Copilot Chat

• Enterprise AI chat experience
• Web-grounded research and content generation
• Work-data grounded scenarios when enabled and licensed
• Learn more: Get started with Microsoft 365 Copilot Chat, Microsoft 365 Copilot Chat, your AI assistant for work, How Copilot Chat works with and without a Microsoft 365 Copilot license, FAQ for Microsoft 365 Copilot Chat

Copilot in Outlook

• Draft emails
• Summarize long email threads
• Generate suggested responses
• Improve tone, clarity, and reader sentiment with coaching
• Ask questions and take action from within Outlook
• Learn more: Draft an email message with Copilot in Outlook, Summarize an email thread with Copilot in Outlook, Get email coaching with Copilot in Outlook, Chat with Copilot in Outlook

Copilot in Teams

• Meeting summaries
• Action item extraction
• Meeting and chat Q&A
• Chat and channel catch-up
• Message rewriting and communication assistance
• Learn more: Catch up on meetings with Microsoft 365 Copilot in Teams, How to use Microsoft 365 Copilot in Teams chats and channels, Start a conversation with Microsoft 365 Copilot Chat in Teams, FAQ for Copilot in Microsoft Teams

Copilot in Word

• Document creation and rewriting
• Executive summaries
• Content transformation
• Key takeaways, action items, and document Q&A
• Learn more: Welcome to Copilot in Word, Draft and add content with Copilot in Word, Rewrite text with Copilot in Word, Create a summary of your document with Copilot in Word

Copilot in PowerPoint

• Create presentations from prompts or documents
• Generate slides, outlines, and speaker notes
• Summarize presentations
• Ask questions about presentation content
• Learn more: Create a new presentation with Copilot in PowerPoint, Prepare your presentation with Microsoft 365 Copilot, Add speaker notes to your presentations using Copilot, Summarize your presentation with Copilot in PowerPoint

Copilot in Excel

• Data analysis and exploration
• Formula generation
• Chart, PivotTable, sorting, filtering, and formatting assistance
• Trend identification and summarization
• Learn more: Get started with Copilot in Excel, Visualize your data with Copilot in Excel

Copilot Studio (connected-agent scenarios in preview)

• Create custom AI agents
• Connect agents to business systems and enterprise data
• Add knowledge sources and tools
• Integrate with Fabric Data Agents
• Explore connected-agent and multi-agent orchestration scenarios
• Learn more: Copilot Studio overview, Add tools to custom agents, Knowledge sources in Copilot Studio, Connect to a Microsoft Fabric Data Agent, Consume a Fabric Data Agent in Microsoft Copilot Studio

Developer and advanced AI-assisted development topics

GitHub Copilot

• AI-assisted code generation
• Code completion, code explanation, refactoring, test generation, and documentation assistance
• Developer productivity scenarios across IDEs, GitHub.com, CLI, and agentic coding workflows
• Integration with Fabric development workflows through Skills for Fabric, MCP servers, Fabric CLI, notebooks, SQL, KQL, PySpark, Power BI projects, and other Fabric development assets
• Learn more: What is GitHub Copilot?, GitHub Copilot code suggestions, Get started with GitHub Copilot Chat in your IDE, Using GitHub Copilot CLI, Enhancing GitHub Copilot agent mode with MCP, Skills for Fabric overview

Power BI Agentic and Power BI agent skills (preview)

• AI-assisted Power BI semantic model and report development
• Create, edit, deploy, and manage Power BI semantic models across Power BI Desktop, PBIP projects, and the Fabric service
• Create new semantic models in Import, DirectQuery, or Direct Lake mode
• Edit tables, columns, relationships, measures, DAX, report pages, visuals, filters, formatting, and themes
• Author, modify, and validate Power BI reports in PBIR / PBIP format
• Power BI project automation, including validation, publishing, report management, and iterative design improvements
• Integration with GitHub Copilot CLI, VS Code Copilot, Claude Code, Cursor, Codex/Jules, Windsurf, MCP servers, and other AI coding assistants
• Related blog post: Microsoft Build 2026 announcements | James Serra’s Blog
• Learn more: Power BI Agentic overview, Power BI Semantic Model Authoring skill, Power BI Report Authoring skill, Power BI Report Design skill, Power BI Report Planner and Management skills, Skills for Fabric on GitHub

More info:

Update from Copilot in Microsoft Fabric | James Serra’s Blog

However, OneLake security is not the native security model for every data location in Fabric. Some data stores use SQL security, some use KQL/Kusto RBAC, some use Power BI semantic model security, and shortcut-based data may require both source-system authorization and OneLake security. A simplified way to think about it is:

Why this matters

The big shift here is that security moves closer to where the data lives. In the old world, it was common to secure the warehouse one way, the semantic model another way, the notebook experience another way, and then hope everyone remembered to duplicate the same rules in the next thing someone built. That may work when you have a small number of reports and users, but it becomes painful as the environment grows. And when AI enters the picture, with more engines, copilots, agents, notebooks, and APIs touching the same data, “remember to configure it everywhere” is not exactly a strategy.

This is why OneLake security is such an important concept in Fabric. It is Microsoft trying to make the data layer itself a more consistent security boundary, so that the same table or folder can be governed once and then safely used through multiple Fabric experiences. That does not mean every security problem magically disappears (unfortunately, the “make security easy” button is still not in the product), but it does reduce the number of places where teams have to repeat the same rules.

Think of OneLake security as the baseline guardrail

The cleanest way to think about OneLake security is as a baseline guardrail for data stored in OneLake. If a user should not see a table, a folder, certain rows, or certain columns, you want that rule defined as close to the data as possible. Then, when that user accesses the data through a supported path, the same baseline applies.

But the word “baseline” is important. OneLake security does not replace every other Fabric security model, and it does not mean you can stop thinking about workspace roles, item permissions, SQL permissions, KQL roles, or semantic model security. Those layers still matter because Fabric has many different data experiences, and not all of them are native OneLake storage. A Warehouse table is governed differently than a Lakehouse table, and a Power BI Import model is different because the data has been imported rather than queried from OneLake at runtime.

The table above is useful because it helps avoid the most common trap: assuming that “Fabric security” means one thing everywhere. Sometimes the answer is OneLake security, sometimes it is SQL security, KQL/Kusto RBAC, Power BI semantic model security, or some combination of those layers.

How this works with Power BI and Direct Lake

Power BI is where many people will feel the impact first, because Direct Lake can read data directly from OneLake while still giving users the familiar report and semantic model experience. In that pattern, OneLake security can provide the source-level view of what the user is allowed to see, while the semantic model still controls the BI-facing experience, including model permissions and any additional semantic model security. If the report goes through the governed Direct Lake path, the user should inherit the secured view of the underlying data.

The nuance is that security layers can stack. If you use OneLake security for broad data-layer rules and semantic model RLS for report-specific rules, the user must satisfy the effective rules that apply in that path. The semantic model should not be treated as a way to grant back data that was denied at the source. I would use semantic model security when it is truly about the model or reporting experience, and use OneLake security when the rule should follow the data across engines.

How to apply OneLake security

At a high level, applying OneLake security starts with the Fabric item that stores the data, such as a Lakehouse, mirrored database, or mirrored catalog that supports OneLake security. From the item menu, you choose Manage OneLake security and create a new role. You give the role a name, choose the Grant role type, select the permission you want to grant, and decide whether the role applies to all data or only selected tables and folders. For selected data, you choose the specific tables or folders that members of the role should be able to access.

Once the table or folder is in the role, you can add more granular restrictions where they make sense. For folders and files, the rule is about the path: can this user read or write this part of the lake? For tables, you can go further and configure row-level security or column-level security. RLS uses a SQL-style predicate to limit which rows are returned, while CLS removes access to selected columns so users cannot see the data values in those columns.

The final step is assigning members to the role. You can add individual users, Microsoft Entra groups, or security principals, and in some cases use permission-based membership so users with certain Fabric item permissions are included automatically. Whenever possible, I would use groups instead of individual users. Individual assignments feel easy on day one, but they become a maintenance headache later when someone changes jobs, joins a new team, or leaves the company.

Where teams get tripped up

The biggest mistake I see with any centralized security model is assuming it applies everywhere just because the product branding is the same. OneLake security is powerful, but it is not a universal replacement for every Fabric security mechanism. If you are querying a Warehouse through its SQL endpoint, you need to think in SQL security terms. If you are using native Eventhouse tables, you need to think in KQL/Kusto RBAC terms. If you are using an imported Power BI semantic model, you need to think about Power BI model security because the query is not going back to OneLake at runtime.

Shortcuts deserve special attention because they often look simple, but the security story depends on what the shortcut points to and how authentication is handled. An internal shortcut can require permissions on both the shortcut path and the target path, while an external shortcut may require source-system authorization plus OneLake security on the shortcut path. That is why shortcuts should be documented as part of your security design, not just treated as convenient plumbing.

Final thought

My advice is to treat OneLake security as a major step toward simpler, more consistent data-layer governance in Fabric, but not as a reason to stop designing security carefully. Start with the data locations that have the highest reuse, the most sensitive data, or the greatest number of downstream experiences. Define the baseline rules in OneLake where supported, then layer on SQL, KQL, or semantic model security only where that is the correct security model for the access path. And because Fabric is evolving quickly, always verify the latest Microsoft documentation before rolling this into production, especially for supported engines, limitations, shortcuts, and Direct Lake behavior.

More info:

OneLake Security in Microsoft Fabric: Centralized Data Access Control for AI Readiness

Video Introduction to OneLake Security in Fabric (Row, Column & Object Level Security)

The biggest announcements across Microsoft Fabric and databases can be found in the Microsoft Build 2026: Building agentic apps with Microsoft Fabric and Microsoft Databases blog post.

Here you go:

Agent Skills for Power BI (Preview):

This was one of the biggest announcements for me. Agent Skills for Power BI are about using an AI assistant or AI agent to help create and improve the analytics experience itself, including automatic creation of semantic models, report pages, layouts, PBIR files, publishing, and iterative design improvements. More broadly, Skills for Fabric is basically a set of reusable instructions that make an AI coding assistant much smarter about Microsoft Fabric. Skills tell the AI assistant, such as GitHub Copilot CLI, VS Code Copilot, Claude Code, Cursor, or Windsurf, how to work with Fabric correctly. MCP servers and other tools then give that assistant live access to actually do things (for example, a skill can call a Power BI Modeling MCP server to build a semantic model). The important point is that the agent is not just guessing against a pile of tables. It can work through the trusted semantic layer, where the business logic, relationships, measures, and definitions already exist. That matters because a pretty report is nice, but a pretty report based on bad assumptions is just a faster way to be wrong. Start using it via AI-Powered Power BI reporting: From design to deployment with agent skills (Preview). Skills include PBI report authoring, PBI report design, PBI report planner and management, and PBI semantic model authoring. Note these report authoring skills work with PBIP/PBIR projects and Power BI Desktop; web-based report authoring is not currently supported.

This is different from using Copilot in the Power BI report authoring experience, whether in Power BI Desktop or the Power BI service. Copilot helps you create or refine report pages, usually from an existing semantic model, and can use a screenshot or image as a design reference with your text instructions. Agent Skills for Power BI go further by letting an AI assistant, such as GitHub Copilot CLI, help create and manage semantic models, author PBIR/PBIP report files, validate reports, update formatting and themes, and support more of the end-to-end Power BI project.

Fabric Apps (Preview):

Fabric Apps are different from Agent Skills for Power BI. In the current experience, the data app template is a Fabric Apps starting point for building custom web apps connected to Power BI semantic models. Agent Skills help create analytics assets, such as semantic models and Power BI reports, while Fabric Apps help developers turn governed data and analytics assets into custom application experiences. This is important because custom web apps can go beyond the limits of traditional BI reports, especially when developers need more flexibility, embedded workflows, write-back style experiences, custom user interfaces, or highly specialized business requirements. In short, Fabric Apps are a new workspace item type for making web apps, meaning programs that live in your browser. This web app can be many things, including a dashboard or an interactive app to manage data, services, or Fabric itself.

At a high level, Fabric Apps introduce a new AI-first approach to building custom web apps, with Microsoft Fabric serving as the managed backend and the open-source Rayfin SDK helping power the experience. The data app template can use Power BI semantic models as a trusted foundation, including governed business logic, metrics, relationships, and security, instead of recreating that logic somewhere else. It also uses Agent Skills to teach the LLM how to generate DAX, query the model, and handle Fabric-specific authentication, visualization, and formatting patterns.

In plain English, this helps close the gap between analytics and operational applications, because the same semantic model used for reporting can also support richer business apps. One important clarification: Fabric Apps overall are broader than semantic models, but the current analytics/data app template is focused on building apps connected to Power BI semantic models. More Fabric data sources are expected in the future. The app shows up directly in a Fabric workspace with the item type of “App,” and eventually these apps are expected to be embeddable outside of Fabric as well. For a video on Agent Skills and Fabric Apps, check out Build Agentic Analytics with Power BI and Microsoft Fabric.

Fabric Skills for GitHub Copilot, Claude, Cursor, Windsurf, and CLI (Available now / open source):

I also really like the announcement around Skills for Fabric, also referred to as Fabric Skills for GitHub Copilot, Claude, Cursor, Windsurf, and CLI. The problem with general AI coding tools is that they often know the syntax, but not the product-specific details that make code actually work. They may produce something that looks right, calls the wrong endpoint, misses the correct authentication pattern, or invents something that sounds plausible but does not exist. Fabric Skills are meant to give those tools Microsoft-authored instructions, API patterns, CLI guidance, and best practices so the AI agent has a better chance of doing the right thing the first time.

Unlike Agent Skills for Power BI, which are focused specifically on planning, designing, authoring, and improving Power BI semantic models and reports, Skills for Fabric span the entire Fabric platform. They provide domain expertise for many Fabric workloads—including Data Factory, Data Engineering, Data Warehouse, Real-Time Intelligence, OneLake, Fabric IQ, and Power BI—so AI agents can create, manage, and automate Fabric artifacts beyond just analytics and reporting.

That is the difference between “AI helped me build this” and “AI created a scavenger hunt for me.” In short, Agent Skills for Power BI are a subset of the broader Skills for Fabric ecosystem: Power BI skills help build analytics solutions, while Skills for Fabric help AI agents work across the entire Fabric platform.

Copilot in web modeling (Preview):

Copilot in web modeling is another practical step toward making semantic model development easier. The idea is to let model authors use natural language directly in the Power BI service to analyze and improve an existing semantic model, including schema cleanup, table and column renames, relationship changes, and DAX measure creation. I would not describe this as creating a brand-new semantic model from scratch. For that, the related Agent Skills for Power BI approach is the better fit, because the semantic model authoring skill can create new semantic models in Import, DirectQuery, or Direct Lake mode. That distinction matters. Copilot in web modeling helps improve the model you already have, while Agent Skills can help create and author new analytics assets. Reports get the attention, but the semantic model is what determines whether the answers are actually useful.

GPU-accelerated Fabric Data Warehouse (Early Access Preview):

The GPU-accelerated Fabric Data Warehouse announcement is a very big deal. The idea is simple: use NVIDIA accelerated computing to make eligible SQL queries run faster without requiring users to rewrite their queries or manage a separate system. That last part is the key. Data teams usually do not want one more specialized engine to administer, tune, explain, fund, and eventually apologize for. If this works as advertised, it makes the warehouse more useful for high-concurrency reporting, agent-driven analytics, and application workloads where every query is suddenly part of an interactive experience.

Graph in Fabric (Generally Available):

Graph in Fabric is now generally available, and I really like this one because so much of business is about relationships, not just rows and columns. Customers are connected to orders, products are connected to suppliers, devices are connected to identities, and one small change can ripple across the whole business. Graph helps model, visualize, and analyze those relationships directly in Fabric. This is especially important for AI because agents need to understand how things are connected, not just retrieve a value from a table and pretend the rest of the world does not exist.

OneLake shortcuts to SharePoint and OneDrive (Generally Available):

The general availability of OneLake shortcuts to SharePoint and OneDrive is another practical announcement that may not sound flashy at first, but will matter a lot in the real world. A lot of important business data still lives in files, folders, spreadsheets, and productivity content. Being able to connect that content into OneLake without constantly copying and moving it helps reduce duplication and makes the data estate feel more connected. This is one of those features that sounds simple until you think about how many organizations are still running critical processes out of Excel files sitting in someone’s OneDrive (not that any of us have ever seen that before).

Shortcuts from Fabric Data Warehouses (Preview):

Along with the OneLake shortcut updates, Microsoft also announced the ability to create shortcuts directly from Fabric Data Warehouses, now in preview. I like this because it continues the zero-copy story, which is one of the most important architectural ideas in Fabric. The more we can avoid copying data just to make another engine happy, the better. Copies create cost, confusion, governance problems, reconciliation debates, and the occasional “which version is the truth?” conversation that nobody enjoys.

Fabric IQ and Operations Agents (Generally Available):

Fabric IQ and Operations Agents are about giving people and agents a shared understanding of the business. That means more than connecting to data; it means understanding business entities, relationships, semantic models, live signals, rules, and actions. Operations agents are designed to monitor real-time data, detect patterns or anomalies, and act based on predefined business logic. This is where the agent story becomes more interesting, because the goal is not just answering questions. The goal is helping organizations observe what is happening, understand what it means, and take action while it still matters.

Fabric IQ integrations with Microsoft Foundry and Agent 365 (Preview):

Another important announcement is the expansion of Fabric IQ across more agent experiences. Ontologies are becoming available as knowledge sources in Microsoft Foundry, and Fabric IQ is being integrated with Microsoft Agent 365 as a first-party MCP tool. Fabric IQ tools and skills for data insights are also accessible through GitHub Copilot CLI, which means developers can ask natural language questions about Fabric data, Power BI reports, and semantic models right from the terminal. That may sound like a developer convenience, but it is bigger than that. It brings governed business context closer to where work is actually happening.

Org apps in Power BI (GA coming soon):

Org apps in Power BI are also worth calling out. Microsoft announced that general availability is coming soon, bringing a more polished, stable, enterprise-ready way to distribute curated analytics experiences at scale. This matters because not everyone needs to see everything, and not every user should have to navigate the underlying workspace structure to find what they need. The best analytics experiences often feel boringly simple to the end user. That is a compliment, by the way.

Visualizations in data agents (Preview):

Visualizations in data agents are coming soon in preview, and this is a very useful addition. Today, natural-language questions are often answered with text or tabular results, which is helpful, but not always the fastest way to understand what is happening. Visualization support will let users turn natural-language questions into charts directly in the data agent experience, making it easier to explore trends, compare results, and spot patterns. That matters because many business questions are visual by nature. Sometimes you do not just want the answer; you want to see the shape of the answer.

Data agents in Microsoft 365 Copilot (Generally Available):

Data agents in Microsoft 365 Copilot are now generally available, which brings Fabric data questions into the place where many users already work. Users can ask questions about governed Fabric data without needing to leave their normal productivity experience. The latest improvements also support longer-running operations, so more complex questions can complete instead of timing out. This is a big part of the “meet users where they are” story. Most business users do not wake up excited to learn another portal. Shocking, I know.

Real-Time Dashboards powered by AI (Preview):

The new AI-assisted editing experience for Real-Time Dashboards is another good step forward. Users can describe what they need in natural language and have Copilot generate a visualization, while still allowing developers to refine the KQL and formatting manually. I like this pattern because it does not pretend everyone wants to become a KQL expert before building a useful operational dashboard. It lowers the barrier for business and operations teams while still leaving room for technical users to fine-tune the result.

Real-Time Dashboards Live Refresh (Generally Available):

Live Refresh for Real-Time Dashboards is now generally available, and this is one of those features that feels obvious once you see it. Instead of refreshing on a fixed schedule regardless of whether anything changed, dashboards can refresh when new data arrives. That should help with both responsiveness and cost, because the dashboard is reacting to actual data activity instead of constantly polling like an impatient child in the back seat asking, “Are we there yet?” For operational monitoring scenarios, that is exactly the kind of behavior you want.

Business Events in Eventhouse and Real-Time Dashboards (Preview):

The Business Events in Eventhouse and Real-Time Dashboards preview is another announcement I like because it makes events more durable and useful. A business event could be a payment failure, shipment delay, equipment outage, or some other meaningful business moment. With Eventhouse enabled by default, those events can be stored, queried with KQL, analyzed historically, and visualized in Real-Time Dashboards. That means business signals do not just disappear after an alert fires. They become part of an analytical record you can learn from.

Activator as a Business Event Publisher (Preview):

Activator as a Business Event Publisher is a nice complement to that story. Activator can now publish structured business events when it detects a condition in a Power BI report, Real-Time Dashboard, KQL query, or Fabric Warehouse SQL query. This turns an alert into something more reusable: a governed signal that can be discovered, consumed, analyzed, and acted on across the organization. That is a subtle but important shift. It moves from “someone got notified” to “the business now has an event it can reason over.”

Mirrored Database Change Feed connector for Eventstreams (Preview):

The Mirrored Database Change Feed connector lets users stream Delta Change Data Feed updates from mirrored databases directly into Fabric Eventstreams. That means inserts, updates, and deletes can flow into real-time processing without writing custom Spark jobs or polling for changes. It supports sources such as Azure SQL, Snowflake, Cosmos DB, Oracle, PostgreSQL, and Open Mirroring partners. This is important because many organizations already have operational data flowing into Fabric through mirroring. This gives them a cleaner path from “we have the data” to “we can react to changes as they happen.”

Eventstream observability through Workspace Monitoring (Preview):

Eventstream observability through Workspace Monitoring is another practical improvement. It gives teams visibility into Eventstream health, throughput, and errors through automatically created monitoring tables in Eventhouse. That means you can query status, metrics, and error information with KQL, build dashboards, and set alerts when something goes wrong. This is the kind of feature that may not sound exciting until you are the person responsible for troubleshooting a streaming pipeline at 2:00 a.m. Then suddenly it sounds very exciting.

Migration Assistant for Fabric Data Warehouse live connectivity (Generally Available) and SQL file migration (Preview):

The Migration Assistant enhancements for Fabric Data Warehouse are important for the less glamorous but very real world of modernization. Migration Assistant now supports live connectivity generally available, so teams can connect directly to source systems without requiring a DACPAC file. It also supports migration using SQL files in preview, which helps with offline or disconnected scenarios. This matters because migrations often fail not because the destination platform is bad, but because the path to get there is too manual, too risky, or too confusing. Reducing friction here is a big deal.

SQL analytics endpoint and warehouse operations improvements (Preview):

There were also several warehouse and SQL analytics endpoint improvements that are worth mentioning together. CI/CD support for the SQL analytics endpoint, pre- and post-scripts for Fabric Warehouse deployments, ALTER COLUMN support, Datawarehouse Monitor, configurable retention, and time travel in the SQL analytics endpoint are all in preview. The enhanced metadata sync for SQL analytics endpoints is especially interesting because it targets fresher metadata availability after delta logs reflecting a data change are available in storage. These may sound like “plumbing” features, but plumbing matters. Nobody compliments the plumbing until it breaks.

OneLake storage tiers and item-size reporting (Preview):

OneLake storage tiers and lifecycle management are in preview, giving admins a way to automatically move older data into more cost-effective tiers based on rules. OneLake item-size reporting is also in preview, providing better visibility into storage usage across items in a workspace, including system and soft-deleted data. These features matter because as data platforms grow, storage becomes both a cost issue and a governance issue. It is much easier to manage what you can actually see. That sounds obvious, but in enterprise data, obvious things are often the hardest things to get right.

Azure HorizonDB (Public Preview):

On the database side, Azure HorizonDB is worth watching. It is a new fully managed, PostgreSQL-compatible database in public preview, designed for the demands of AI-powered applications. It includes capabilities such as vector search, integrated AI model management, and connectivity to Microsoft Foundry and Fabric. I see this as part of a broader trend: operational databases are becoming part of the AI architecture, not something sitting off to the side waiting to be copied into an analytics system later.

More info:

Fabric June 2026 Feature Summary – Microsoft Fabric Community

Fabric Apps explained: Visualization as code in a data app dashboard

We tested the New Power BI Report Skills: The Future of AI-Powered Reporting? [Steb by step demo] (video)

Microsoft Fabric Apps Tutorial – How I Built a Fabric App with Copilot (video)

GitHub Copilot CLI for Beginners (video playlist)

How Data Apps make semantic models better in Fabric

This blog is about best practices for Microsoft Purview data governance, not the data security and compliance side of Purview. I covered the broader value of Purview data governance in my post, Microsoft Purview: The key benefits of data governance, but here I want to get more practical and a bit more opinionated. Microsoft Purview has many capabilities across governance, risk, compliance, and security, but this post focuses on the governance experience: cataloging data, improving metadata, helping users find trusted data, understanding lineage, organizing data products, and making data easier to use. Microsoft also has helpful guidance, including data governance planning, Unified Catalog planning, Purview deployment best practices, deployment checklist, and getting started but the real lesson is this: the tool is only as good as the operating model around it.

Make Purview part of the data creation process

One of the first best practices is to notify the Purview administrator when new data sources need to be scanned. Purview does not automatically know about every new database, file share, lakehouse, warehouse, report, or application that shows up in your environment. Someone has to tell the Purview team that a new source exists and should be registered and scanned. This sounds simple, but it is a big deal. If new systems are created and nobody tells the Purview admin, then the catalog will always be incomplete, and once users lose confidence in the catalog, it is hard to get that trust back.

A good governance process should make this notification step part of the normal lifecycle for new data projects. When a new source is created, when a new data product is published, or when a new reporting dataset becomes important, there should be a clear step that says, “Has this been registered in Purview?” This is not just an administrative detail. It is how you prevent Purview from becoming a stale inventory that people stop using. If the catalog is always six months behind reality, users will go back to asking around, searching folders, or messaging the person they think might know where the data is.

Train people to search before they build

You also need to train people to use the data catalog before they build new reports, pipelines, notebooks, or ETL processes. This is one of the biggest culture changes with any catalog. If users do not search Purview first, they will reinvent the wheel, create duplicate datasets, rebuild logic that already exists, and possibly use the wrong data. Purview can help people discover existing assets, understand who owns them, see definitions, review classifications, and find related reports or pipelines. But again, this only works if people know the catalog exists and make it part of their normal workflow.

This training should not just be a one-time demo where someone shows the search box and says, “Good luck.” Users need examples that match how they work. A report developer should see how to find an existing certified dataset before creating a new one. A data engineer should see how to locate source tables, understand lineage, and identify the owner before building a pipeline. A business analyst should see how glossary terms, descriptions, and contacts help them decide whether a dataset is trustworthy. The more practical the training, the more likely people are to use the catalog when it matters.

Use Purview to reduce random access requests

Another important best practice is to train people to use the Request Access feature in Purview instead of sending emails, making phone calls, walking over to someone’s desk, or submitting random tickets through a help desk. We have all seen the old way: someone needs access to a table, they ask five people who might know who owns it, and eventually someone forwards an email to the right person. That process is slow, hard to track, and easy to lose. Request Access gives the organization a cleaner way to capture who requested access, what they requested, who approved or denied it, and why.

This is where governance starts to become real. It is not just about knowing that data exists; it is about creating a repeatable process for using that data responsibly. If access requests happen outside the catalog, the catalog becomes disconnected from the actual user experience. But if users can discover data, understand it, identify the owner, and request access from one place, Purview becomes a working part of the data ecosystem instead of just a metadata repository.

Use Purview as a starting point, not just a search tool

Purview should also be used as a jumping-off point for creating reports and connecting to data. For example, instead of emailing an administrator and asking for the fully qualified name of a data source, users can search in Purview and use features such as “Open in Power BI Desktop.” Purview does not store the actual data, but it stores the metadata needed to find and connect to that data. When a user opens an asset from Purview, the qualified name can be passed into Power BI Desktop, making the experience much easier. This is a great example of why a catalog should not just be a passive inventory; it should help people take action.

This point is important because business users do not want governance for the sake of governance. They want to get their job done. If Purview helps them find the right data faster, avoid waiting on an admin, and start building a report with the correct source, then it becomes valuable to them. If it just gives them a long list of cryptic table names, they will avoid it. The catalog needs to meet users where they are and help them move from discovery to action.

Do not assume scanned metadata is good metadata

After a scan runs, someone should review the metadata and determine whether it is correct. This is one of those steps that people sometimes skip because they assume the scan did everything. But a scan can miss a classification, classify something incorrectly, get a data type wrong, or pull in a CSV file that has no headers and shows columns as col1, col2, and col3. That is not very helpful to a business user trying to decide whether the data is useful. The metadata may need to be supplemented with better descriptions, column definitions, tags, data asset attributes, glossary terms, or friendlier names for tables and fields.

This manual review process is not a sign that Purview is failing. It is just the reality of enterprise data. Metadata in source systems is often incomplete, inconsistent, or just plain confusing. A table name might make sense to the developer who created it 12 years ago, but nobody else. A field might be called CUST_ID in one system, PERSON_KEY in another, and CLIENT_NUM in a third. Purview can help bring order to that chaos, but only if someone curates the metadata and adds business meaning where the technical metadata falls short.

Use glossary terms, contacts, domains, and data products

Glossary terms are important because they help connect business meaning across inconsistent technical names. A customer might be called customer in one table, person in another, client in another, and account holder somewhere else. Without a glossary, users have to guess whether these terms mean the same thing or something different. With glossary terms, you can tag related columns and assets so users can understand the business meaning, even when the physical column names are inconsistent. This is one of the places where Purview can make a big difference, but only if the glossary is maintained and actually used.

It is also helpful to manually add contacts (experts and owners) to assets so users know who to contact with questions. This sounds basic, but it is one of the most practical things you can do. When someone finds a dataset, they often want to know who owns it, who understands it, who can approve access, and who can explain whether it is the right source. A catalog without contacts can become a museum of metadata. A catalog with owners and experts becomes a living system that helps people collaborate.

Governance domains and data products should also be created intentionally. Do not just scan a bunch of assets and hope users can figure it out. Manually organize assets into governance domains and data products so people can browse and search in a way that matches how the business thinks. Microsoft’s Unified Catalog guidance describes governance domains and data products as key concepts, and that makes sense because most users do not think in terms of servers, schemas, and storage accounts. They think in terms of finance, sales, customer, operations, claims, inventory, or whatever domain matters to their business.

Treat lineage as something you manage, not something you magically get

Lineage is another area where expectations need to be realistic. Purview can capture lineage from supported tools, and Microsoft has documentation on data lineage, but it cannot automatically know everything that happens outside those tools. If someone copies and pastes data manually, moves files by hand, exports data to Excel, or runs custom scripts, Purview may not know that lineage unless someone tells it. For non-standard movement, you may need scripts or API calls to update lineage. This is especially important for organizations that have a mix of ADF pipelines, stored procedures, notebooks, custom Python scripts, legacy ETL tools, and manual data movement.

Lineage from ETL jobs, stored procedures, and notebooks is especially hard because parameters can change what data is read or written at runtime. Static analysis can only go so far. A stored procedure may build dynamic SQL, a notebook may use variables, or a pipeline may pass different source and target names depending on the job configuration. The most accurate approach is similar to how Azure Data Factory lineage works: capture what actually happened when the job ran, then send that runtime information to Purview after the job completes. That is how you move from guessed lineage to real lineage.

Act when sensitive data and quality issues are found

A strong best practice is to create a process for what happens when sensitive data is found through classifications. For example, suppose a SQL database scan finds Social Security numbers in a comment field. That should not just sit quietly in the catalog as an interesting piece of metadata. The right person, such as the SQL DBA, data owner, security team, or privacy lead, should be notified so they can confirm that the data is protected properly. Classification is useful because it finds potential risk, but finding risk is only step one. Someone has to act on it.

Purview can also help score and monitor data quality, as described in Microsoft’s data quality overview, but it is important to understand what that means. Purview can identify, measure, and expose data quality issues, but it does not magically fix the data. The fixing usually happens in the source system, data pipeline, transformation layer, or business process that created the bad data in the first place. That distinction matters. Purview can shine a bright light on quality problems, but someone still has to walk over and clean up the mess (unfortunately, no magic button yet).

Use APIs and think catalog of catalogs

The Atlas APIs are also worth understanding because they can help with bulk metadata changes, lineage updates, and integration with sources that do not have a native connector. If you have data sources that Purview cannot scan directly (via a pull), you may be able to push metadata into Purview through APIs. If you have ETL jobs outside of Azure Data Factory, you may be able to capture lineage through custom logic. This is especially useful in mature environments where data movement happens through a mix of modern and legacy tools. The API layer is one way to close some of the gaps that automation alone cannot solve.

Purview can also be used as a catalog of catalogs, especially in environments that already use tools such as Databricks Unity Catalog. Many organizations will not have just one catalog. They may have specialized catalogs for different platforms, teams, or technologies. Purview can provide a broader enterprise view across those environments, helping users discover assets even when the underlying metadata is managed elsewhere. The key is to be clear about which catalog owns what, how metadata flows between them, and where users should go for enterprise-wide discovery.

Bottom line

Here’s the bottom line: Purview can automate a lot, but it cannot automate everything. There will always be manual intervention needed to make metadata accurate, useful, and trusted. This is because source metadata may be missing or wrong, data may move manually, lineage may depend on runtime parameters, new data sources may not be automatically discovered, and business definitions may live in people’s heads instead of systems. Purview is a powerful tool, but it is not a substitute for governance discipline.

The best Purview implementations combine automation with human ownership. They scan what they can, curate what matters, train users how to search before building, create clear access request processes, review sensitive data findings, improve lineage, organize data products, and keep business metadata current. That is how Purview becomes more than a catalog. It becomes a trusted starting point for finding, understanding, governing, and using data across the enterprise.

I’m happy to share that the book is now available in several translated printed editions, making it accessible to a much broader global audience.

Current printed editions include:

• English
• Portuguese
• Polish
• German
• Russian
• Japanese

There are also machine-translated French and Italian editions available through the O’Reilly learning platform. These require an O’Reilly subscription and are available for online reading only.

In addition, an English audiobook is now available.

And there is more to come. A Chinese edition is due next month.

For readers in India, there is also a low-cost reprint edition available locally.

Why I Wrote the Book

Data fabric, data lakehouse, and data mesh have recently emerged as viable alternatives to the modern data warehouse. Each of these architectures offers real benefits, but they are also surrounded by a lot of hyperbole, confusion, and conflicting opinions.

That was one of the main reasons I wrote this book.

My goal was to provide a practical, vendor-neutral guide that helps data professionals understand the strengths, weaknesses, trade-offs, and ideal use cases for each architecture. Rather than promoting one architecture as the answer to every problem, the book helps readers understand when to use a modern data warehouse, data fabric, data lakehouse, data mesh, or some combination of these approaches.

What the Book Covers

In Deciphering Data Architectures, I examine common data architecture concepts, including how data warehouses have evolved to work with data lake capabilities. The book also explains what data lakehouses can help you achieve, how to separate data mesh hype from reality, and how to determine the most appropriate architecture for your specific needs.

With this book, you will:

• Gain a working understanding of several data architectures
• Learn the strengths and weaknesses of each approach
• Distinguish data architecture theory from reality
• Pick the best architecture for your use case
• Understand the differences between data warehouses and data lakes
• Learn common data architecture concepts to help you build better solutions
• Explore the historical evolution and characteristics of data architectures
• Learn the essentials of running an architecture design session, organizing teams, and improving project success

A Timeless, Product-Neutral Resource

One of the things I’m most proud of is that the book is free from product-specific discussions. While tools and technologies change quickly, the underlying architectural principles tend to last much longer.

That makes the book useful whether you are a data architect, data engineer, analytics leader, consultant, or technology executive trying to make sense of today’s increasingly crowded data architecture landscape.

The fact that the book is now available in so many languages is very meaningful to me. Data architecture challenges are global, and I’m excited that more readers around the world can now access the book in their preferred language.

If you have colleagues, customers, or friends who would prefer reading in Portuguese, Polish, German, Russian, Japanese, French, Italian, or soon Chinese, please feel free to share the appropriate edition with them.

Thanks to everyone who has read, reviewed, recommended, or shared the book. I truly appreciate the support.

For years, most data conversations have started with tables. We ask where the data lives, what columns are available, how the joins work, and whether the data is in a warehouse, lakehouse, semantic model, or some other system. That makes sense, because tables are how most of us have worked with data for decades. But tables are not how the business thinks.

A business thinks in terms of customers, products, orders, shipments, assets, flights, runways, employees, policies, and actions. The problem is not usually a lack of data. The problem is a lack of shared meaning. Organizations often have the same business concept represented multiple ways across teams and systems, creating what I would call semantic drift. Sales may define a customer one way. Finance may define it another way. Operations may have yet another version in a different system with different keys, names, and assumptions. That is exactly where Fabric Ontology becomes important. It is designed to close the gap between physical data structures and business meaning.

Fabric Ontology matters because AI makes this problem more visible. Humans can often work around inconsistent definitions through tribal knowledge, documentation, and meetings. AI agents cannot do that reliably. If the business meaning is not explicit, AI has to infer intent from schemas, naming conventions, and queries, which increases the risk of inconsistent or unreliable answers. That is why ontology is becoming such an important concept in modern data architecture.

What is an ontology in Microsoft Fabric?

An ontology in Microsoft Fabric is a business abstraction layer that defines core entities and relationships, and binds them to data sources so people, tools, and AI can reason over data in business terms. Microsoft describes ontology as a shared, machine-understandable vocabulary of your business and as a business context layer. It defines the core business concepts that exist in your organization and explains how those concepts relate to one another.

Instead of forcing every team to interpret raw tables on their own, an ontology creates a common business language. A Customer means the same thing across teams. A Product means the same thing across systems. An Order, Shipment, Asset, Flight, or Route is described consistently, even if the underlying data comes from many different places. That shared vocabulary is paired with data bindings, a graph representation, and a query surface so the concepts are not just documented, but actually connected to live data and usable across downstream experiences.

The easiest way to think about Fabric Ontology is that it adds business meaning on top of your data. It is not trying to replace your data warehouse, lakehouse, or semantic models. It is trying to help people, analytics tools, and AI agents understand what the data actually means. Ontology is part of Fabric IQ and is currently in preview, so it is an important area to understand, but also one where capabilities may continue to evolve.

What an ontology is not

It is just as important to understand what an ontology is not. A Fabric ontology is not a Power BI semantic model. It is not a reporting layer where you create DAX measures and build visuals. It is not a data warehouse, a lakehouse, or a place where you copy and store another version of the data.

This is probably the most common misunderstanding. Because Fabric Ontology can be generated from a Power BI semantic model, it is easy to assume it becomes another kind of semantic model. It does not. A semantic model is designed for reporting and analytics. It contains measures, calculations, relationships, hierarchies, and business logic optimized for Power BI reports and dashboards. An ontology serves a different purpose.

An ontology is a business meaning layer. It defines entities, properties, relationships, rules, and constraints, and then binds those definitions to real data sources in Fabric. In other words, it maps meaning to data without turning the ontology into another storage layer or reporting model. That distinction matters, because if you expect Ontology to behave like a Power BI model, you will be disappointed. If you understand it as a shared business vocabulary for reasoning, AI, and relationship exploration, it starts to make a lot more sense. Ontology provides the shared context layer, while semantic models remain their own representation for analysis and reporting.

How Fabric Ontology binds meaning to data

The binding step is where an ontology becomes useful instead of just being a nice conceptual diagram. Once you define an entity such as Customer, Product, Order, Flight, or Runway, you bind it to actual data sources in Fabric. Those sources can include lakehouse tables, warehouse tables, eventhouse data, event streams, geospatial data, or existing Power BI semantic models.

The binding maps columns to properties, connects identifiers to relationships, and turns raw data into typed business entities. A row in a table is no longer just a row in a table. It becomes an instance of something the business understands.

This is a subtle but important shift. In a traditional table-centric world, users often need to know which table to query, which columns to select, which joins to write, and which filters to apply. That works for technical users, but it does not scale well to every business user, and it definitely does not scale well to AI agents that need to reason across systems.

It also creates architectural flexibility. When physical schemas change, you can often update the binding layer instead of forcing every downstream consumer to relearn the underlying structures. That does not eliminate change, but it creates a cleaner separation between business meaning and physical implementation.

Why business concepts matter more than table names

One of the biggest benefits of an ontology is that it allows users to ask questions in business terms. Instead of thinking through a maze of tables and joins, a user can ask about customers, orders, shipments, flights, routes, delays, assets, or risks. The ontology gives Fabric the business context needed to interpret the question.

For example, a user should not have to know every table involved in flight operations to ask a meaningful question. They should be able to ask about delayed flights affected by poor runway conditions at a specific airport. Behind the scenes, that may involve flight data, runway data, weather data, airport data, geospatial data, and real-time event data. But the user should not have to think that way.

That is the real promise of Ontology. It lets the business interact with data in the language of the business. Not table names. Not cryptic column names. Not schema diagrams that only three people in the company understand. Business concepts.

How Ontology works with Graph in Microsoft Fabric

One of the more powerful parts of this story is how Ontology works with Graph in Microsoft Fabric. When Graph is enabled, entity instances become nodes and relationships become edges. That means your business concepts can be explored as a connected graph, not just as separate tables that require joins. Microsoft specifically describes ontology graph as a queryable instance graph built from data bindings and relationship definitions, where nodes are entity instances and edges are links between them.

A simple way to visualize this is: a Flight is a node, a Runway is a node, and “uses runway” is an edge. A Customer is a node, an Order is a node, and “places order” is an edge. Once the data is represented this way, relationship traversal becomes much more natural. Instead of hand-coding every join, you can navigate the connected business context directly.

This opens the door to visual exploration, relationship browsing, impact analysis, dependency analysis, pathfinding, and other graph-style operations. If a runway has poor conditions, you can explore what flights, terminals, ground service tasks, maintenance activities, or customer impacts may be connected to that issue.

This is where Fabric Ontology starts to feel very different from traditional analytics modeling. You are not just asking, “What happened?” You can start asking, “What is connected to this?” “What is affected by this?” “What might happen next?” That is a much richer way to understand the business.

An airline example

The airline example is a good way to make this real. You might start with an existing Power BI semantic model that already contains flights, airlines, bookings, airports, and routes. From there, you can generate an ontology where those tables become business entities, columns become properties, and relationships are preserved. Microsoft’s ontology generation documentation says that generating from a semantic model creates entity types from tables, static properties from columns, and relationship types from model relationships.

Then you can enrich that ontology by binding it to additional data sources, such as real-time runway condition data, weather data, turnaround events, geospatial data, and maintenance data. Through data binding, those source tables and streams are mapped to the ontology’s entities, properties, and relationships, so runway friction, visibility, contamination, weather conditions, and maintenance events become part of the same connected business model. Suddenly, you are not just looking at a report. You are building a connected model of how airline operations actually work.

Now imagine a runway at JFK has poor friction and visibility due to weather. With a graph-enabled ontology, the operations team could explore which flights are affected, which terminals may experience delays, which ground service tasks are at risk, and which customer impacts may follow. That is a much more operational view of the business than simply looking at a dashboard that says delays are increasing.

Ontology vs. Power BI semantic models

This is where it is important to separate Ontology from Power BI semantic models. Power BI semantic models remain essential for reporting and analytics. They are optimized for measures, calculations, aggregations, visuals, and interactive analysis. If you want to know revenue, margin, sales trends, customer churn, or on-time performance, a semantic model is still the right tool.

Ontologies focus on shared meaning, relationships, reasoning, and AI understanding. Power BI is very good at answering questions like, “How much revenue did we generate?” or “What was our on-time performance last month?” An ontology helps answer questions like, “What business concepts are involved, how are they related, and what does this situation actually mean?”

So, Ontology is not a replacement for semantic models. In fact, they work better together. A semantic model can be used to jumpstart an ontology, because it already contains useful structure such as tables, columns, relationships, and business-friendly names if the model has been well designed. But once the ontology is created, its purpose is different. The semantic model supports reporting. The ontology supports shared understanding.

What you cannot do with an ontology

Because Ontology is new and powerful, it is easy to overstate what it does. So let’s be very clear. You cannot build Power BI reports directly from an ontology. You cannot use it as a Power BI dataset. You cannot create DAX measures or calculated columns in it. You cannot treat it as a replacement for the semantic model that powers your reports.

So Fabric Ontology can provide the business meaning layer used by a Fabric Data Agent to answer questions about your data, but it is not used to build reports and dashboards. The purpose of ontology is concept modeling, data binding, graph navigation, and business-level querying—not replacing the analytical model used for BI visuals.

That is not a weakness. It is a boundary. Good architecture depends on understanding what each layer is designed to do. Power BI semantic models are for reporting, metrics, measures, and interactive analysis. Fabric Ontology is for shared business meaning, consistent terminology, relationship modeling, reasoning, and grounding AI experiences.

This is one of those areas where the “what it is not” may be just as valuable as the “what it is.” If a team adopts Ontology expecting it to replace their reporting model, they are using the wrong mental model. If they adopt it to reduce semantic drift, align business concepts, support graph exploration, and give AI agents a better business vocabulary, they are much closer to the intended value.

How ontologies are created

The creation process happens directly in the Microsoft Fabric experience. There are two main paths Microsoft documents today: generate an ontology from an existing semantic model, or build one directly from OneLake data. When generated from a semantic model, tables become entity types, columns become properties, and relationships become ontology relationships. The generation process also creates data bindings for supported scenarios, but Microsoft notes that some work still needs to be completed manually, such as reviewing keys, binding relationship types, and adding time series data where needed.

From there, the important work is refinement. You rename technical objects into business-friendly terms, turning names like dimproduct into Product or factsales into SaleEvent. This is where business and technical teams should collaborate, because the goal is not just to reflect the database structure. The goal is to reflect how the business talks, thinks, and operates.

After the conceptual model is refined, you bind the ontology to real data. That includes mapping entity keys, attributes, relationships, and time-based data to the underlying sources. For example, CustomerID may become the key for Customer, customer name and status may become properties, and the relationship between Customer and Order can be defined explicitly.

Why Ontology matters for AI agents

This is where the AI angle becomes especially interesting. Agents and copilots need more than data access. They need business context. Without that context, they may retrieve information, but they may not understand the meaning behind it.

Ontology gives agents a common vocabulary and a consistent set of relationships to reason over. A Fabric Data Agent can answer questions using business concepts instead of forcing users to know the table structure. Microsoft’s documentation explicitly positions ontology as a shared context layer that can be consumed by humans and AI agents for cross-domain reasoning and decision-ready actions.

This is one of the strongest arguments for Fabric Ontology: without an explicit semantic layer, AI has to infer meaning from raw schemas, naming conventions, and prompts. With ontology, the business meaning is modeled directly. That makes AI answers easier to ground, easier to govern, and easier to align with how the business actually defines customers, products, orders, assets, and events.

When Fabric Ontology is most valuable

Fabric Ontology is especially valuable when:

• the same business entity is defined differently across teams or systems
• you need cross-domain consistency and governance
• you want AI agents to reason over business concepts instead of raw tables
• you need graph-style exploration of connected business context
• you expect schemas and source systems to evolve over time but do not want every downstream consumer tightly coupled to those changes

In other words, ontology is most useful when reporting alone is not enough. If your main need is dashboards, a semantic model may be sufficient. If your need is shared business understanding across analytics, AI, and connected processes, ontology becomes far more compelling.

The agility benefit

The biggest benefit of Fabric Ontology may be agility. Physical schemas change. New data sources appear. Teams rename columns, move tables, adopt new systems, and create new models. If every report, query, application, and agent is tightly coupled to physical structures, those changes become painful.

Ontology creates an abstraction layer between business meaning and physical data. When a new source arrives or an existing schema changes, teams can often rebind the data to the ontology instead of rewriting every piece of downstream logic. That is not magic, but it is a much better operating model than scattering business meaning across hundreds of disconnected artifacts.

This is especially important in larger organizations where different domains may each have their own models, systems, and definitions. An ontology gives those domains a way to align around shared business concepts without forcing every system to look exactly the same underneath. That is a practical balance between standardization and flexibility.

The bottom line

Fabric Ontology helps move the conversation from “where is the data stored?” to “what does the business mean?” It defines the concepts, relationships, rules, and context that allow people and AI to work from the same shared understanding. That is a big deal, because most organizations do not suffer from a lack of data. They suffer from a lack of consistent meaning.

Semantic models remain the right tool for Power BI reporting and metrics. Ontologies provide the business meaning layer that helps unify data across systems, support graph exploration, and give agents a better foundation for reasoning. Together, they help organizations get closer to a world where users do not need to understand every table, join, and schema to ask good questions and get trusted answers.

In short, Fabric Ontology is about making data understandable in business terms. It does not replace your existing analytics investments. It gives them more context, more consistency, and more intelligence. And in a world where AI agents are going to become more involved in how organizations analyze, monitor, and act on data, that shared understanding may become one of the most important layers in the modern data architecture.

More info:

What is a semantic layer?

MCP tries to do the same thing for AI agents and software platforms. Instead of every AI tool needing its own custom integration into every system, the system can expose itself through an MCP server. Then an MCP-compatible client, such as GitHub Copilot, Claude, Cursor, or another agentic tool, can discover what that system can do and interact with it through a standard interface. In plain English, it gives AI agents a more consistent way to understand and operate external systems, rather than just talk about them.

That is where Fabric MCP becomes interesting. Microsoft Fabric already has a lot of capabilities across data engineering, data warehousing, data science, real-time analytics, Power BI, OneLake, governance, and more. But historically, if a developer or platform team wanted to automate something in Fabric, they had to use the UI, write code against REST APIs, script with the Fabric CLI, or stitch together multiple tools. That works, but it is still plumbing. And as every developer knows, plumbing is usually where the time goes (and occasionally where your weekend goes).

With Fabric MCP, AI assistants and agents can work with Fabric in a more natural and practical way. For example, a developer could ask an AI assistant to help write a Python script that reads data from a lakehouse, transforms it, and loads it into a warehouse. Instead of guessing from outdated training data, the assistant can use Fabric MCP to understand the current Fabric API specifications, examples, schemas, and best practices. That means better code, fewer hallucinations, and less time spent translating documentation into working implementation.

There are two Fabric MCP options, and they are designed for different scenarios. Fabric Local MCP, also called the Fabric Pro-Dev MCP server, runs locally on your machine and is generally available. Think of it as the developer-focused option. It helps AI assistants understand Fabric APIs, work with local files, perform OneLake operations, and support development workflows. This is useful when you are building, testing, generating code, uploading files, creating Fabric items, or using the Fabric CLI as part of a more automated workflow.

Fabric Remote MCP, also called the Fabric Core MCP server, is the cloud-hosted option and is currently in preview. This is aimed more at real operations inside your Fabric environment without requiring a local setup. An AI agent can connect to the cloud-hosted MCP endpoint, authenticate with Microsoft Entra ID, and operate within your actual Fabric permissions. That means an agent could help list workspaces, search for Fabric items, create or update items, manage permissions, or work with connections, depending on what capabilities are available and what you are authorized to do.

One question developers may ask is: Why use Fabric MCP if I can already use the Fabric CLI with an AI coding assistant, Skills, or even a custom agent? The answer is that these are complementary, not competing, approaches. The Fabric CLI is a powerful execution tool for developers and automation scripts, while Skills and custom agents can provide the instructions, best practices, and explainability needed to guide how those commands are used. MCP adds an agent-native interface that makes Fabric capabilities more discoverable, structured, and consistent across AI tools. In some cases, the MCP server may even use the CLI or APIs behind the scenes. So the design choice is not MCP or CLI. It is whether you want the agent to operate through a curated Fabric-aware tool surface, through a more flexible command-line interface guided by Skills or custom agent logic, or through both depending on the task.

The security model is a big part of the story. This is not “let the AI do anything it wants,” which would be exciting for about five minutes and terrifying immediately after that. Fabric MCP operations are tied to authentication, role-based access control, and audit logging. In other words, the agent should only be able to do what the signed-in user is allowed to do, and actions can be tracked. That matters because the future of agentic AI is not just agents answering questions. It is agents safely performing work.

The broader point is that Fabric MCP is another step toward making Fabric an AI-native data platform. Developers can build faster. Platform teams can automate more. Business teams may eventually interact with Fabric through natural language instead of always opening a portal and clicking through menus. And agents built in tools like Copilot Studio could become operational assistants that help create workspaces, manage access, prepare environments, or support repeatable project setup.

Here’s the bottom line: Fabric MCP is not just another developer feature. It is a new interface pattern for working with Fabric. The UI still matters. APIs still matter. The CLI still matters. But MCP gives AI agents a common, governed way to understand and operate Fabric. And if agentic AI becomes as important as everyone expects, this kind of standard connector may become as normal and expected as USB became for hardware. That is when things start to get really interesting.

More info:

Agentic Fabric: How MCP is turning your data platform into an AI-native operating system | Microsoft Fabric Blog | Microsoft Fabric

My opinion on this is pretty strong. GenAI is not a replacement for reports and dashboards, at least not if you care about consistency, repeatability, and trust. What it is, though, is a powerful new way to explore data, especially when you are not exactly sure what question to ask. That distinction matters a lot, because it changes how you design solutions, how you prepare your data, and maybe most importantly, how you train your users to think about the answers they get back.

I remember some of my early interactions with GenAI on enterprise data, back when people were first starting to get excited about putting a bot on top of an LLM and letting users ask questions in plain English. The demo experience was impressive. You could type a question, get back a nicely worded answer, and sometimes even a chart or summary that looked polished enough to drop into a meeting. For a moment, it felt like the future had arrived and reports were about to become old news. Then I did what I usually do when something looks a little too magical: I started pushing on it.

I asked the same question a few different ways. Then I asked it again later. Then I made the wording a little more vague, then more specific, then somewhere in between. What stood out to me was not that the system sometimes got things wrong. That part was not surprising. What stood out was how confident it sounded, even when the answer was off, incomplete, or just different from what it had said earlier. That was the moment where it became obvious to me that this was not the same thing as a report, no matter how often people wanted to compare the two.

A report or dashboard is deterministic. The logic is defined, the calculations are known, the filters are fixed, and two people looking at the same thing under the same conditions should get the same answer every time. That is the value. A well-built report is boring in the best possible way. It is predictable, dependable, and stable. When an executive is looking at a KPI, or finance is closing the books, or a team is measuring performance against a target, boring is good. In those cases, you do not want creativity. You want truth presented the same way every time.

GenAI does not work like that. When a user asks a question through a bot on top of an LLM, the system is generating a response, not simply retrieving a fixed result from a carefully designed visual. The wording of the prompt matters. The context matters. The grounding matters. The model itself matters. Even small phrasing changes can lead to different interpretations, different queries, and different answers. That means you can ask the same question on different days and not always get exactly the same response, which is fine for exploration but a real problem if the user assumes the answer is definitive.

That is why I keep coming back to a simple rule: if you need 100 percent accuracy, use a report or dashboard. I do not mean “close enough.” I mean truly dependable, auditable, repeatable accuracy. That is still the world of structured BI, curated semantic models, governed metrics, and known logic. I think some people want GenAI to leapfrog all of that, but that is not how it works today. The confident tone of an LLM can create the illusion of certainty, and that illusion is one of the biggest risks in this whole space.

At the same time, I do not want to sound like I am dismissing GenAI, because I am not. It is incredibly useful when used for the right purpose. Reports and dashboards are excellent when you know the questions in advance. They are built to answer recurring business questions quickly and consistently. But a bot becomes powerful when the user is still exploring, still learning, or still trying to figure out what to ask. In that sense, reports are great when you know the questions, and GenAI is great when you do not. That is the simplest way I know to explain the difference.

This is also why end users love bots so quickly. They do not have to learn where a metric sits on page three of a dashboard. They do not have to understand the full schema. They do not have to know which report was built by which team six months ago. They can just ask. That freedom is a huge advantage, especially in large organizations where data is spread across many systems and users often do not know where to begin. The problem, of course, is that the same freedom that makes GenAI feel easy also makes it dangerous when users do not know how to verify what comes back.

And that gets to another issue that people underestimate: many end users are not in a position to validate the answer. If a dashboard says revenue is down 4 percent, they can often trace the number back to a governed source, a defined metric, or a known report owner. If a bot says revenue is down 4 percent because of a certain product mix in a certain region, how does the average user know whether that is correct? They may not have the data literacy, the source access, or the business context to challenge it. So now the burden shifts from simply providing an answer to building a system that makes the answer more trustworthy.

This is where Microsoft Fabric, Copilot, and data agents enter the conversation in a serious way. If you want better answers from AI on data, you cannot just point an LLM at your environment and hope for the best. You have to make the data AI-ready (see Getting Your Data GenAI-Ready: The Next Stage of Data Maturity | James Serra’s Blog). That means the same old principles still apply, and in many ways they matter even more now: clean data, clear definitions, strong governance, good metadata, and business-friendly structure. The shiny chatbot experience sits on top, but underneath it is still a data foundation problem, and those foundation problems have not magically disappeared just because the interface is conversational.

In fact, using AI on data can create more work than traditional reporting. With reports, you usually prepare the data needed to answer known questions. With GenAI, users can ask far beyond what the reports were ever designed to cover. That means you may need to clean and organize data that never showed up in a dashboard before. You may need to clarify business terms that were previously handled informally. You may need to create examples, provide SQL patterns, and guide the model so it has a better chance of producing the right output. In other words, when you open the door to broader questioning, you also open the door to broader data preparation.

That is why making the bot return more accurate results becomes such a critical design goal. This is where hints, sample SQL, semantic modeling, and ontology become so important. If you want a Fabric data agent or Copilot experience to behave well, you have to help it understand the business. You cannot assume it will infer your definitions of customer, order, active account, pipeline, margin, or whatever else your organization uses every day. The more business context you can encode into the environment, the better your chances of getting useful answers back. Without that, the bot is often just guessing in a very polished voice (which is not nearly as comforting as it sounds).

There is also a human productivity angle here that reminds me of what happened when desktop computers became mainstream. People sometimes talk about technology as if it simply replaces effort, but that is not really how it works. Desktop computers did not turn an eight-hour workday into permanent free time. They accelerated the work. They compressed tasks. They raised expectations. Suddenly things that used to take all day could be done in a couple of hours, and instead of working less, people were expected to do more. GenAI feels similar to me. It is an accelerator, not a substitute for thinking.

You can see that in small ways already. You no longer need to write in perfect grammar to get started. You can brain dump a messy thought and let the model help clean it up. You can start with a rough question and improve the prompt instead of trying to craft the perfect request on the first try. That is useful, just like spell check is useful. But spell check never removed the need to know when a word is wrong, and GenAI does not remove the need to know when an answer does not make sense. It helps you move faster, but it does not remove your responsibility to think.

That is why user education matters so much. Organizations cannot just deploy Copilot or a chatbot on top of Fabric and assume users will naturally understand the limits. They need to be taught that LLM answers can be wrong. They need to understand that wording matters, context matters, and follow-up questions matter. They need to learn that prompt engineering is not some exotic technical trick, but really just the practice of asking clearer questions and refining them when the answer is weak. And they need to understand when to trust the system and when to go back to the governed report.

Looking ahead, I do think this space will improve. I would not be surprised at all if one of the next major advances is a set of agents specifically designed to verify answers, cross-check outputs, and explain confidence levels before the final response ever reaches the user. That would help address one of the biggest weaknesses of GenAI on enterprise data today. But even if that happens, I still do not think reports and dashboards go away. I think what happens instead is that each tool becomes more valuable in its proper role. Reports remain the system of record for known, trusted business questions, while GenAI becomes the system of exploration for everything around the edges.

So here is my practical advice. Use reports and dashboards when consistency and accuracy are non-negotiable. Use GenAI when flexibility, speed, and discovery matter more. Invest in the data foundation because the model is only as good as the context you give it. Build with Fabric and Copilot intentionally, not as a novelty, but as part of a broader data strategy. And train your users to think critically, because the biggest mistake you can make is assuming that a confident answer is the same thing as a correct one.

That is where I land on this. GenAI is absolutely changing how we interact with data, and I am excited about where it is going. But excitement should not replace discipline. The future is not “bots instead of dashboards.” The future is knowing when each one is the right tool, building both responsibly, and helping people understand the difference. That is where the real value is, and that is also where the real trust will come from.

More info:

When, and when not, to use LLMs in your data pipeline

Power BI Copilot, Data Agent Optimization & Performance

The OneLake catalog is Fabric’s centralized place to find and explore items, and to govern and secure the data you own. Over the past year, the OneLake catalog has seen a tremendous wave of new capabilities added across discovery, governance, and security—and the pace of innovation hasn’t slowed. Microsoft continues to expand it rapidly, with many more features expected as the catalog becomes the central experience for understanding and managing your Fabric data estate.

This blog is a practical walkthrough of the three tabs in the catalog: Explore (find and validate), Govern (see what’s missing and fix it), and Secure (audit and manage access). 

Setting the stage

Let’s use a realistic (generic) setup. Your company has domains like Finance and Sales. Each domain has Bronze, Silver, and Gold workspaces, plus at least one Sandbox workspace where “temporary” assets go to live forever. Domains matter because all users can see the domains defined in the tenant, and the catalog’s domain selector lets people scope what they’re browsing (and what admins are assessing) to a specific domain or subdomain. 

Explore

Here’s the bottom line: Explore is where analysts go to find data, evaluate it, and decide if they trust it before building anything on top of it.

The Explore tab gives you a single place to search and browse across your Fabric items. You get filters, domains, and an item details pane—all without losing your place. And more importantly, you get signals that help you decide if something is worth using: owner, last refresh, endorsements, and sensitivity labels.

It’s important to understand that the OneLake catalog Explore tab is primarily permission‑scoped. In general, it shows only the data assets you already have permission to access, meaning what you see is not the full picture of your organization’s data estate—it’s just your slice of it.

There is one important exception: semantic models that are explicitly configured as discoverable can appear in Explore even if you don’t yet have access to them, allowing you to manually request access through your organization’s standard approval process. Outside of these discoverable semantic models, other Fabric items that you don’t have permission to see are not visible. As a result, users may be unaware that similar data already exists elsewhere in the organization and may unintentionally recreate data in a new lakehouse simply because the existing data isn’t visible to them.

If you’ve used Microsoft Purview before, think of Explore as the in-product, day-to-day experience for discovery inside Fabric. It gives you what you need right where you are working—fast search, filtering, metadata, and limited lineage—all without leaving Fabric.

This is where the Microsoft Purview Unified Catalog comes in. Purview is designed to provide organization-wide visibility, ownership, and governed discovery—helping users understand what data already exists, who owns it, and how it should be reused. It plays a key role in preventing unnecessary duplication by making data discoverable even when you don’t yet have access to it.

You might be wondering how Explore compares to Microsoft Purview—and it’s a fair question. Explore gives you the core capabilities you need inside Fabric: basic lineage, search, filtering, metadata visibility, and access requests. It’s designed for speed and usability so you can get in, find what you need, and move on.

Purview goes quite a bit further. It offers deeper lineage across multiple systems, more advanced search and filtering across the entire data estate, richer metadata management (including the ability to curate and extend it), governance constructs like domains and data products at a broader level, and more comprehensive reporting on your data landscape.

Think of Purview as the “Catalog of Catalogs”.

So don’t think of this as one replacing the other. Think of it as layers. Explore helps you get your work done right now. Purview helps your organization understand and manage data at scale.

Now, if I were sitting next to you and you asked, “What should I actually do in here?”, I’d keep it simple:

• Filter by domain first, then workspace. This alone saves you from digging through sandbox chaos.
• Open item details and actually read the description (you’d be surprised how often this is skipped).
• Look for endorsements—certified or promoted items are your safest starting point.
• Check lineage if what you’re building matters downstream.

Govern

Let’s define what Govern is: it turns governance from a quarterly initiative into a daily backlog of fixes. The Govern tab provides insights plus recommended actions to improve governance posture. Fabric admins see tenant-wide insights based on tenant metadata (items, workspaces, capacities, domains). Data owners can focus on their own inventory using My items. 

One important point that often surprises people: you do not need Microsoft Purview to use the governance capabilities in the OneLake catalog. The governance features in the Govern tab work natively inside Fabric. You can manage domains, endorsements, ownership metadata, and many governance insights without deploying Purview at all.

However, if your organization is using Microsoft Purview together with Fabric, the experience becomes much richer. Purview extends what Fabric can already do by adding enterprise-wide capabilities like cross-platform data discovery, advanced classification, broader data loss prevention policies, and deeper compliance and auditing features. Fabric governance works on its own, but Purview expands the reach across your entire data estate.

Two practical details matter. First, admin insights are driven by Admin Monitoring Storage in the Admin Monitoring workspace and refresh daily (so expect some lag). Second, the data-owner report refreshes when owners open the Govern tab (with a manual refresh option). 

When you hit View more, you get expanded insights, including security insights that were previously available in the Microsoft Purview hub within Fabric. The expanded views cover: “Manage your data estate” (inventory, capacities/domains, feature usage), “Protect, secure & comply” (sensitivity label coverage and DLP evaluation coverage), and “Discover, trust, and reuse” (freshness, description/endorsement coverage, and sharing). You also get access to the “Item explorer” view, which lets you drill into the actual items behind the metrics—so instead of just seeing that something is missing (like labels or descriptions), you can immediately identify and take action on the specific items that need attention.

How I’d use this in the real world (without making it a second job): pick a domain, then pick one improvement loop. Start with sensitivity labels, move to descriptions, then endorsements. Do it domain by domain, not tenant-wide all at once. Domains are designed for distributed governance, with clear roles (Fabric admin, domain admin, domain contributor/workspace admin) and the ability to delegate certain settings down to domain admins. 

Pair Govern with operational evidence. If an insight points to stale or failing data, jump into the item’s Monitor history (from item details) or use the monitoring hub to review recent activity and error details. 

And don’t forget the “settings side” of governance. Certification and master data endorsement exist, but they’re controlled by tenant settings and reviewer groups. Item certification can be delegated so domain admins manage certification rules for their domain. Domains can also support delegated settings like a domain-level default sensitivity label (if your organization enables that feature), which is one of the easiest ways to make “born labeled” the default. 

Secure

Here’s the bottom line: Secure is where you answer “who can access what” with evidence. The Secure tab centralizes security management by showing workspace roles/permissions and OneLake security roles across items, and it supports auditing and role management from one place. 

Day-to-day, there are two views to know. “View users” shows each user, group, or application with roles across selected workspaces, with filters and search to verify access quickly. “View security roles” shows OneLake security roles across items and workspaces (role name, permission, location, data owner), and lets admins create, edit, delete, or duplicate roles. 

OneLake security is now generally available, and this is a big deal. It gives you data-level security directly in Fabric, where you can define roles that control access down to folders, tables, and even rows or columns. And the key advantage is consistency—you define security once in OneLake, and it is enforced across all Fabric experiences, including Power BI (Direct Lake and semantic models), SQL analytics endpoints and Warehouses, Spark notebooks and Data Engineering workloads, and Real-Time Intelligence (KQL databases and Eventhouse).

Now add policies, because that’s how security teams scale. Sensitivity labels can be applied to Fabric items (from the item header or in item settings). These policies are not created in Fabric—they are defined in Microsoft Purview and then enforced in Fabric. Protection policies can then use those labels to restrict access: allowed users/groups retain access while everyone else is blocked, and the catalog’s item Permissions tab can show who has access (including restrictions).

At this point, it helps to separate what you do in Fabric versus what you do in Purview. Inside Fabric, the Secure tab is your operational control center. This is where you assign roles, review access, apply labels, and manage OneLake security. It’s built for day-to-day access management and quick answers when someone asks, “who has access to this?”

Purview, on the other hand, extends this into enterprise-wide security and compliance. It gives you capabilities like centralized auditing across multiple systems, advanced data loss prevention policies, richer classification of sensitive data, and broader compliance reporting. Fabric handles the “how is access enforced right now,” while Purview helps answer “are we meeting our organization’s security and compliance requirements everywhere.”

DLP policies can detect sensitive data uploaded into OneLake-supported items and generate policy tips and alerts. And Fabric activities are available through Purview Audit, which is the evidence trail you want when questions get serious (and they always do). 

So think of it this way: Fabric gives you strong, built-in security that works immediately and consistently within your data platform. Purview builds on top of that foundation and gives you more advanced capabilities across your entire data estate. You don’t need Purview to secure your data in Fabric—but if you have it, you significantly expand what’s possible.

Bringing it all together

One of the most important things to understand about the OneLake catalog in Fabric is what it is—and what it isn’t. It’s a lightweight, in-product discovery experience designed to help analysts find and evaluate data they already have access to. It does that job well. But it is not a full enterprise data governance solution, and that distinction becomes clear when you compare it to Microsoft Purview.

You don’t need Microsoft Purview to get started. Fabric gives you a lot out of the box—enough to organize, discover, and secure your data in a very practical way. For many teams early on, that’s exactly what they need. But as your environment grows, and as governance becomes more than just “keeping things organized,” you start to need more.

Purview operates at an entirely different level. It provides organization-wide visibility into data assets—even those you don’t yet have access to—along with the ability to request access through built-in approval workflows that can automatically provision permissions. It also introduces a business glossary, allowing organizations to define common terms and map them to technical assets, creating a shared language between business and IT. On top of that, Purview adds structure through governance domains and data products, enabling clear ownership, stewardship, and accountability across the enterprise.

To make this more concrete, here are some of the key capabilities that exist in Purview but are missing or very limited in the OneLake catalog today:

• Business glossary and shared definitions – No native way in Fabric to define business terms and map them to data assets
• Access request workflows – No built-in way to request, approve, and track access to data you don’t already have
• Data quality framework – No support for defining rules, scoring data quality, or monitoring trends over time
• Organization-wide discovery – Fabric only shows data you already have access to, and only within Fabric. That means you can’t see assets outside of Fabric, and you also won’t see Fabric items you don’t have permission to access. As a result, users often lack visibility into what already exists across the organization, which can lead to missed reuse opportunities and unnecessary duplication of data.
• Governance domains and data products – No formal structure for organizing data ownership and accountability
• Automated scanning of external systems – Fabric catalog is limited to Fabric; Purview scans across hybrid and multi-cloud sources
• End-to-end lineage across platforms – Fabric lineage is mostly scoped within Fabric, not across the full data estate
• Rich metadata and classification – Limited extensibility compared to Purview’s custom metadata and classification capabilities
• Policy management and enforcement – No centralized governance policy engine in Fabric
• Audit and compliance reporting – Limited governance reporting compared to Purview’s enterprise capabilities
• 3rd-party integration – Many products have integrations into Purview (i.e. ER/Studio), which will need to be updated to integrate with OneLake catalog

The bottom line: the OneLake catalog helps you discover and trust data within your current permissions, while Purview helps your organization understand, govern, and manage all of its data. Fabric gets you started quickly—but Purview is what you bring in when governance needs to scale across the enterprise.

Here’s a simple way to think about the relationship between Fabric and Purview—this visual makes it click (graphic courtesy of Prashant Atri):

Wrap-up

Explore is where people discover and validate. Govern is where you find the trust gaps and fix them. Secure is where you prove and manage access. If you want a simple operating rhythm: analysts live in Explore, data owners spend a small weekly block in Govern, and admins/security teams check Govern and Secure to keep posture and access from drifting. 

If you want to go deeper on how Fabric and Purview fit into a broader enterprise strategy, Microsoft’s Cloud Adoption Framework provides guidance on building a unified data governance foundation across your entire data estate: Data governance and security baselines with Microsoft Purview.

More info:

Explore Fabric Security insights in the OneLake catalog – Govern tab | Microsoft Fabric Blog | Microsoft Fabric

OneLake catalog overview – Microsoft Fabric | Microsoft Learn

What’s New? – Microsoft Fabric | Microsoft Learn

OneLake catalog: The trusted catalog for organizations worldwide | Microsoft Fabric Blog | Microsoft Fabric

Generally Available (GA)

• OneLake security (GA soon) (more info)
  OneLake security introduces centralized, consistent access control across all Fabric engines (Spark, SQL, Power BI, etc.) using a single security model. This eliminates the need to manage permissions separately per engine and ensures data is secured once and enforced everywhere. It’s a foundational step toward true “write once, secure once” governance in Fabric.
• OneLake Catalog Govern tab (GA) (more info)
  The new Govern tab brings governance insights directly into the OneLake Catalog, including ownership, lineage, sensitivity labels, and policies. It helps users understand not just what data exists, but whether it’s trusted and compliant. This bridges the gap between discovery and governance without leaving Fabric.
• Mirroring: SAP and Oracle (GA) (more info)
  Mirroring now supports enterprise systems like SAP and Oracle, continuously replicating data into OneLake with minimal latency. This allows organizations to analyze operational data in near real-time without complex ETL pipelines. It’s a major step toward making OneLake the central analytics hub.
• Shortcut transformations (GA) (more info)
  Shortcut transformations let you apply transformations directly on data accessed via shortcuts without copying it into OneLake. This enables a true “virtual data” pattern where you can shape and prepare external data in place. It reduces duplication while still enabling analytics-ready datasets.
• Materialized Lake Views (GA) (more info)
  Materialized Lake Views provide precomputed, optimized views over lakehouse data for faster query performance. They automatically stay in sync with underlying data while improving performance for BI workloads. Think of them as bringing warehouse-like performance to lakehouse data.
• Graph in Fabric (GA) (more info)
  Graph capabilities enable modeling and querying relationships between entities (like customers, products, or networks) directly in Fabric. This opens the door for use cases like fraud detection, recommendation engines, and relationship analysis. It extends Fabric beyond tabular analytics into connected data scenarios.
• Maps in Fabric (GA) (more info)
  Native mapping capabilities allow you to visualize geospatial data directly within Fabric dashboards and real-time analytics. This makes it easier to analyze location-based trends, logistics, and operational data. It eliminates the need for external mapping tools in many scenarios.
• Fabric Data Agents (GA) (more info)
  Data Agents allow users to interact with their data using natural language, powered by AI grounded in Fabric data. They can answer questions, generate insights, and automate analysis across datasets. This brings conversational analytics directly into the platform.
• Direct Lake in OneLake (GA) (more info)
  Direct Lake enables Power BI to query data directly from OneLake without importing or duplicating it. This delivers near real-time performance with in-memory speed while maintaining a single copy of the data. It’s a key pillar of Fabric’s “one copy of data” vision.
• Workspace tabs (GA) (more info)
  Workspace tabs improve navigation by allowing users to organize and quickly switch between commonly used items. This enhances productivity, especially in large workspaces with many artifacts. It’s a simple but impactful UX improvement.
• SQL audit logs (GA) (more info)
  SQL audit logs provide detailed tracking of database activity for compliance and security monitoring. Organizations can now capture who accessed what data and when. This is critical for enterprise governance and regulatory requirements.
• Dataflow Gen2 preview-only steps (GA) (more info)
  Previously preview-only transformations in Dataflow Gen2 are now fully supported in production. This expands the range of data prep capabilities available for enterprise pipelines. It simplifies building robust, reusable data transformations.
• Dataflow Gen2 ADLS Gen2 and Lakehouse destinations (GA) (more info)
  Dataflows can now write directly to ADLS Gen2 and Fabric lakehouse files, expanding storage flexibility. This enables better integration with existing data lakes and hybrid architectures. It also supports more scalable and cost-efficient data pipelines.

Public Preview / Coming Soon

• End-to-End CI/CD upgrades (public preview) (more info)
  New Git integration enhancements bring deeper CI/CD support across Fabric items. Developers can version, deploy, and manage Fabric assets more consistently across environments. This makes Fabric much more enterprise-ready for DevOps practices.
• Capacity Events in Real-Time Hub (public preview) (more info)
  Capacity events provide real-time visibility into Fabric capacity usage and performance. Admins can monitor spikes, throttling, and system behavior as it happens. This helps proactively manage workloads and avoid performance issues.
• Capacity overage billing (public preview) (more info)
  Overage billing allows workloads to continue running even when capacity limits are exceeded, with pay-as-you-go billing. This prevents failures due to throttling while giving organizations flexibility. It’s especially useful for unpredictable or bursty workloads.
• Workspace-level surge protection (public preview) (more info)
  Surge protection now allows admins to control how individual workspaces consume capacity during spikes. This prevents one workspace from impacting others. It adds a new layer of workload isolation and governance.
• Mirroring: SharePoint Lists & Azure MySQL (public preview) (more info)
  Additional mirroring sources expand Fabric’s reach into operational systems like SharePoint and MySQL. This enables more data sources to flow into OneLake in near real-time. Support for Azure Monitor and Dremio is also on the roadmap.
• Extended mirroring capabilities (public preview) (more info)
  Enhancements to mirroring provide more flexibility in how data is replicated and managed. This includes options for performance tuning and selective replication. It makes mirroring more adaptable to enterprise needs.
• Shortcut to Excel in SharePoint (public preview) (more info)
  You can now create shortcuts directly to Excel files stored in SharePoint or OneDrive. Fabric automatically treats them as structured data for analytics. This turns everyday business files into analytics-ready data without ingestion.
• Databricks reads from OneLake (public preview) (more info)
  Databricks can now directly access data stored in OneLake, enabling interoperability between platforms. This reduces data duplication across ecosystems. It supports a more open and unified data architecture.
• Azure Data Factory & Azure Synapse pipelines migration assistant (public preview) (more info)
  This tool helps migrate existing Azure Data Factory and Synapse pipelines into Fabric. It automates much of the conversion process, reducing manual effort. This accelerates adoption of Fabric for existing customers. Note these migrations are kicked-off via a “Migrate to Fabric” button while inside a pipeline within Azure Data Factory or Synapse.
• Live connectivity in Migration Assistant for Fabric Data Warehouse (public preview) (more info)
  This feature lets you connect directly to your source system and migrate object metadata (schemas, tables, views, stored procedures, functions and security) into a new Fabric warehouse. This preview is designed to help you accelerate the migration and reduce upfront prep by eliminating the need to generate and upload a DACPAC for the metadata step. This live connectivity experience is supported for Azure Synapse Analytics Dedicated SQL Pool and SQL Server database, Azure SQL database, or Azure SQL MI used for analytics. (Note the Migration Assistant also can copy the Synapse dedicated pool or SQL database data to Fabric by creating a copy job. To migrate Synapse lake databases, notebooks, and other data engineering objects, go here. Also check out the Synapse to Fabric Migration Guide).
• Custom SQL Pools (public preview) (more info)
  Custom SQL pools allow more control over compute resources for SQL workloads in Fabric. This provides better performance tuning and workload isolation. It brings more flexibility similar to dedicated SQL pools in Synapse.
• Agents Skills for Fabric in GitHub Copilot CLI (public preview) (more info)
  Developers can use GitHub Copilot CLI to generate and manage Fabric assets using natural language. This includes building pipelines, models, and queries. It’s a big step toward AI-assisted development in Fabric.
• Planning in Fabric IQ (public preview) (more info)
  Planning in Fabric IQ (called Plan in Fabric IQ in the documentation) introduces forecasting and scenario modeling capabilities built on Fabric data. It allows organizations to plan budgets, simulate outcomes, and use AI to reason about future scenarios. It integrates with Fabric’s semantic layer and ontology. Reminds me of the discontinued product Microsoft Forecaster.
• SQL database in Fabric: Engine parity and enterprise readiness (public preview) (more info)
  Fabric SQL databases now offer much deeper parity with the Microsoft SQL Server engine, bringing familiar capabilities and performance to the platform. They are designed to be enterprise-ready by default, with built-in high availability, security, and scalability. This makes Fabric a viable destination for both new applications and modernized database workloads.
• SQL database in Fabric: Migration and database agents (public preview) (more info)
  New tooling makes it easier to adopt Fabric databases, including migration assistants for moving existing SQL Server workloads with minimal friction. Database Agents introduce AI-powered capabilities that can help automate tasks, optimize performance, and provide insights directly within the database experience. This lowers the barrier to modernization while improving day-to-day database operations.
• Database Hub in Fabric (early access) (more info)
  Fabric is expanding its role as the central access point for enterprise data with the Database Hub in Fabric, now available in early access. The Database Hub provides a unified database management experience that brings together databases across edge, cloud, and Fabric into a single, coherent view. Teams now have one place to explore, observe, govern, and optimize their entire database estate—including Azure SQL, Azure Cosmos DB, Azure Database for PostgreSQL, SQL Server (enabled by Azure Arc), Azure Database for MySQL, and Fabric Databases—without changing how each service is deployed. This is a big step toward treating Fabric as a complete database platform, not just an analytics layer. See video.
• Copilot for data engineering & data science (public preview) (more info)
  Copilot assists with building notebooks, writing code, and generating transformations in Fabric. It accelerates development for engineers and data scientists. This reduces the barrier to working with Spark and advanced analytics.
• Fabric Data Warehouse recovery (public preview) (more info)
  Recovery capabilities allow restoring data warehouse states after failures or data loss. This improves reliability and disaster recovery. It’s an important step for enterprise-grade resilience.
• Copilot for real-time dashboard visuals (public preview) (more info)
  Users can generate dashboard visuals using natural language directly in real-time analytics. This makes it easier to explore streaming data without manual configuration. It brings AI-driven BI into operational scenarios.
• Dataflow Gen2 Snowflake & Excel destinations (public preview) (more info)
  Dataflows can now write to Snowflake and Excel, expanding integration options. This supports multi-platform data strategies. It also enables easier sharing of curated data with business users.
• Dataflow Gen2 failure notifications (public preview) (more info)
  Email alerts notify users when dataflow refreshes fail. This improves monitoring and operational awareness. It helps teams quickly respond to pipeline issues.
• SSIS package activity in Fabric Data Factory (public preview) (more info)
  You can now run SSIS packages directly within Fabric pipelines. This helps organizations reuse existing investments while transitioning to Fabric. It simplifies hybrid migration scenarios.

Note the next FabCon conference is in Barcelona, Spain Sept 28-Oct 1 (more info). Be sure to book your ticket at the best possible price – the Super Early Bird Sale ends April 15th.

More info:

FabCon and SQLCon 2026: Unifying databases and Fabric on a single data platform

Empowering admins and developers with a Fabric platform ready for any project

Fabric March 2026 Feature Summary

Power BI March 2026 Feature Summary

FabCon and SQLCon 2026: What’s new in Microsoft OneLake

Database announcement blog

Fabric Platform announcement blog

Fabric Data Factory announcement blog

Fabric Analytics announcement blog

Real-Time Intelligence announcement blog

Fabric IQ announcement blog

Power BI announcement blog

Planning in Fabric IQ blog

Fabric AI announcement blog

Fabric ISV announcement blog

A wave of new Dataflow Gen2 capabilities at FabCon Atlanta 2026

Career risks? Rob Farley

Rob took an interesting angle on the idea of career risk. In his post, he reflects on how for much of his early career he actually avoided risk. After finishing university, he chose stability over uncertainty — turning down a PhD and opting for a steady consulting job instead. Even when he moved countries (Australia to the UK and later back again), he gravitated toward permanent roles because he had a young family and valued security. It wasn’t until more than a decade later that he took what he considers his biggest career risk: starting his own company in 2008. But what really stood out to me in Rob’s story is how he defines success. He isn’t trying to build a startup to sell or chase investors. Instead, he built a consulting business that reflects who he is — heavily involved in community work, volunteering time to help others in the data world, even when it doesn’t directly generate revenue. Some might call that “commercially naïve,” but Rob frames it differently: the real risk would be building a career that forces you to be someone you’re not.

T-SQL Tuesday #196 – What career risks have you taken? by Jamal Hansen

Jamal shared a perspective on career risk that I think many of us recognize. In his post, he reflects on how his career evolved through a series of smaller decisions rather than one big leap. Early on, he leaned into opportunities to learn programming and technology, gradually moving deeper into the data space. The risk wasn’t a dramatic career pivot but a willingness to keep exploring new skills and directions even when the path wasn’t perfectly defined. What stood out to me is that Jamal frames risk as a mindset — choosing curiosity and growth over staying comfortable. It’s a good reminder that many careers are shaped not by one bold move, but by a steady pattern of learning and adaptation.

T-SQL Tuesday #196: What Risks Have You Taken in Your Career? by Louis Davidson

Louis took a refreshingly honest approach to the topic: he openly admits he’s never really been a big risk-taker. In his post, he reflects on two moments where he did step outside his comfort zone. One was leaving a stable role in the late 1990s to join an education startup during the dot-com era—an experience that didn’t work out financially but taught him a lot about how companies succeed or fail. Years later, he took another leap by moving into a full-time writer/editor role at a software company, gaining valuable experience working with writers and the broader community. What stood out to me is Louis’s takeaway: even when risks don’t pay off the way you hoped, the learning still matters. Sometimes the value of a risk shows up years later.

T-SQL Tuesday #196: What Career Risks have you taken? by Pat Wright

Pat took a thoughtful angle on career risk by focusing on the kinds of opportunities that stretch you professionally. In his post, he talks about stepping into roles that involved organizing events, speaking publicly, and getting more involved in the SQL community. Those aren’t always the risks people think about when discussing careers, but they still require putting yourself out there and being willing to grow. What stood out to me is how he highlights the value of community involvement as a career investment. Sometimes the biggest risks aren’t changing jobs or companies — they’re raising your hand, sharing your knowledge, and becoming visible in the community. Over time, those choices can shape a career just as much as any job change.

T-SQL Tuesday #192: What career risks have you taken? by Mala Mahadevan 

Mala shared a story shaped by a simple belief: the work you do every day should actually fit who you are. In her post, she reflects on a career that has evolved through several transitions—starting as a COBOL programmer, moving to VB, then SQL Server DBA, later Database Engineer, and now Data Engineer, with plans to move toward AI ethics. Along the way she took risks that meant stepping away from roles where she was already comfortable, including leaving a long-time DBA position and relocating for a new type of engineering role that better matched her interests and reduced burnout. What stood out to me is her perspective that career choices aren’t just about salary or stability—they’re about protecting your long-term well-being and continuing to grow.

T-SQL Tuesday #196 – Two risky career decisions I made by Steve Hughes 

Steve shared two career decisions that ended up shaping his entire path. Early in his career, he took a risk by moving into consulting after building a warehouse management application using Access, Visual Basic, and barcode scanners—jumping into a world where he had to grow quickly and solve real problems for clients. Years later, he took a different kind of risk by stepping out of consulting to join a client company so he could spend more time with his family instead of constantly traveling. What stood out to me is that both decisions were about more than just career advancement—they were about building a life that balanced work and family. Looking back, Steve says it was absolutely worth it. Sometimes the right career risk is the one that protects what matters most.

T-SQL Tuesday #196: Career Risks by Andy Yun 

Andy shared a story about a career move that surprised even him: going into sales. After years working as a SQL Server developer and DBA—firmly in the “hardcore techie” camp—he received an unexpected message asking if he’d consider becoming a sales engineer at SentryOne. At first, he wasn’t even sure what that role meant, and like many technical folks, he had some pretty negative assumptions about sales. But he decided to give it a shot, largely because he respected the company and its community-focused culture. What stood out to me is how that leap challenged his own biases. Sometimes the risk isn’t changing technologies—it’s changing how you think about entire career paths. I also add his story is very similar to mine – going from a software developer to a pre-sales role at Microsoft. But I love the job as I am “teaching” every day and am partnering with my customers to help them successfully build solutions.

T-SQL Tuesday #196 – What career risks have you taken? by Chad Callihan

Chad took a perspective that many people experience but don’t always talk about: the risk of staying when companies go through acquisitions. In his post, he describes starting at a small company of about 100–150 employees, which was eventually acquired by Cerner and later by Oracle, turning his workplace into part of a massive organization. Each acquisition brought uncertainty—new leadership, new priorities, and the question of whether it still made sense to stay. What stood out to me is that Chad frames staying put as its own kind of risk. We often think the bold move is leaving a company, but sometimes the gamble is riding out the change and seeing where it leads. Careers don’t just change when we move—they also change when the company around us does

Risks? I’ve Taken a Few by Mike Walsh

Mike shared a story that feels very real to anyone whose career path didn’t follow a perfectly straight line. In his post, he reflects on several risks along the way—leaving a stable role to pursue consulting, navigating a difficult business partnership, and eventually building his own company, Straight Path. One moment that stood out was when he left a comfortable job to take a junior DBA role so he could grow faster, even though it meant upsetting a mentor who had supported him. Later, starting his consulting firm—and eventually hiring employees—raised the stakes even higher. What was interesting to me is how Mike frames risk as something that evolves. At first it’s about your own career, but once you build a business and people depend on you, the calculus changes completely.

T-SQL Tuesday #196: My Boldest Career Moves by Deepthi Goguri

Deepthi shared a deeply personal story about the biggest career risk she ever took: changing professions entirely. In her post, she explains that she originally trained and worked as a pharmacist, but eventually made the difficult decision to leave that field and move into computer technology. That meant starting over in a completely different industry, learning new skills, and stepping into a world that was unfamiliar and uncertain. What stood out to me is how she describes making the change even when it felt uncomfortable, because she believed it was the right move for her future. That kind of pivot takes real courage. Sometimes the biggest career risk isn’t changing jobs—it’s changing careers entirely. Much respect to her for writing an emotional blog – and admitting she is an introvert, which I am too

T-SQL Tuesday #196: Taking Risks by Steve Jones

Steve shared a story that captures what a real career risk feels like in the moment. In his post, he describes leaving a stable corporate role—where he was doing well and had been promoted—to work full-time on SQL Server Central, a side project he had been building with others. It meant taking a pay cut and walking away from the security of a traditional job, with real concerns about whether his skills would stagnate or if he could return to the workforce later. What stood out to me is how he describes it as a calculated risk that still felt scary at the time. Looking back, it worked out. But in the moment, it didn’t feel safe at all—and that’s usually how you know it’s a real risk.

Final thoughts

So there you are—some really great insights from across the community.

I’ll close with one more reflection from my own career. The biggest way risk has helped me over the years is pretty simple: changing jobs. Over the course of my career, I’ve worked for 26 companies and held about 40 roles. Part of that is because I get bored easily—especially when I’m not learning something new. When the learning stops, I start looking around.

Every move carried some risk. New company. New people. Sometimes a new technology or even a completely new direction. But those moves paid off in ways that went beyond just experience. The result has been a dramatic increase in my salary over time while still having fun in nearly every role. When I look back at my first job as a computer systems administrator making $5.50 an hour, it’s pretty amazing to see how far things have come.

And I have no doubt about this: if I had avoided risks and stayed in the same roles for long stretches, I would probably be making less than half of what I earn today. Let’s face it—money isn’t everything. But having more financial security absolutely helps when it comes to supporting your family and creating opportunities for them.

Of course, not every risk worked out. I’ve taken jobs that turned out to be bad fits, and I’ve also passed on opportunities that would have been incredibly lucrative. One that still stands out was a pre-IPO company I didn’t join—while a colleague who did take the job retired early. But those experiences taught me something valuable and helped me make better decisions the next time. And in the end, if I would have retired early, I would not have written my book Deciphering Data Architectures: Choosing Between a Modern Data Warehouse, Data Fabric, Data Lakehouse, and Data Mesh (See what I did there? Had to sneak that plug in somehow). 

The key lesson for me is that the goal isn’t to avoid failure. The goal is to learn from it and keep moving forward. I never stopped taking risks after those setbacks, and over time those risks paid off. It’s just something to keep in mind the next time you’re deciding whether to take that leap.

Why this choice matters in a Direct Lake world

Here’s the bottom line: once you move to a lakehouse-first pattern and Direct Lake becomes your default, you’re no longer just choosing where to “clean some columns.” You’re deciding where your team’s data logic lives, who owns it, how reusable it is, and how painful it will be six months from now when someone asks, “Why doesn’t this report match the data warehouse?” 

Direct Lake is designed to load data into memory directly from Delta tables in OneLake and then query it with the VertiPaq engine, giving you Import-like performance without copying the entire dataset into the model. A Direct Lake refresh is mostly metadata framing, not a full data reload, which keeps refresh overhead low compared to Import refreshes. 

And there’s a subtle but important architectural nudge in the official guidance: Direct Lake moves data preparation upstream into OneLake, using tools like dataflows, pipelines, Spark, and T-SQL, so the logic is reusable and centralized. 

That’s where the comparison gets interesting.

Two approaches, one common trap

Let’s define the two options as they exist today in Fabric, without the marketing fog.

Semantic Model Power Query (PQ) means you’re using Power Query editing inside the semantic model experience (web modeling). This is real Power Query: connect, transform, and load. But there’s a key limitation that directly affects Direct Lake: Power Query editing for semantic models is supported for Import storage mode tables, not for Direct Lake tables. In other words, you can’t “Transform data” on Direct Lake tables the way you can in Import.

Dataflow Gen2 is a separate artifact designed for low-code ingestion and transformation with Power Query Online, then loading the results into destinations like Lakehouse tables and Warehouse. It’s explicitly positioned for transformation and loading, and it includes scheduling, monitoring, and pipeline integration.

A simple diagram helps show why these feel similar in the editor, but behave very differently in real life:

Option A: Semantic Model PQ (Import shaping)
Source -> Power Query in semantic model -> Import into model -> Report
                                          (local to one model)

Option B: Lakehouse-first with Dataflow Gen2 + Direct Lake
Source -> Dataflow Gen2 (PQ) -> Lakehouse tables (Delta in OneLake) -> Direct Lake semantic model -> Reports
                                         (reusable layer)               (shared, durable)

If you’ve ever thought, “But they both use Power Query… aren’t they basically the same?” you’re not alone. They look alike. They do not behave alike.

Semantic Model PQ: great for last-mile shaping, risky as your data prep layer

When Semantic Model PQ is the right tool, it feels magical. You’re building a report, you find a messy column, you fix it, and you move on with your life. That speed matters, especially for BI developers and report authors.

As Direct Lake increasingly becomes the default choice, there are clear pros and cons.

Pros

Semantic Model PQ is fast to start and very close to the reporting experience. The semantic model editing experience in the service supports Power Query editing for Import models and lets you build the model and report quickly in the browser.

It also fits the “I can’t change upstream” scenario. The Direct Lake guidance even calls out that when the semantic model author can’t modify the source item managed by IT, adding Import tables and using Power Query in the model can be a practical workaround.

Cons

Scope and reuse are the first big problem. Semantic Model PQ logic lives inside one semantic model. That’s fine until you have three semantic models doing the same transformation three different ways (and nobody notices until you’re in a meeting).

Direct Lake is the second big problem. Power Query editing (Transform data) isn’t supported for Direct Lake tables. Direct Lake uses an Edit tables experience, where you select which Lakehouse/Warehouse tables the semantic model uses, not how to transform them.

So if you try to do “real” transformation work inside the semantic model, you tend to drift into Import mode tables. And now you’ve brought back the heavy part Direct Lake was trying to remove: full refresh cycles, capacity CPU and memory pressure during refresh, and duplicated data storage in the model. The Power BI data refresh guidance explicitly calls out the need to plan for extra memory during semantic model refresh to prevent refresh failures.

Important nuance: Composite models (Direct Lake + Import) are a valid and intentional design choice in Fabric. They work well when used deliberately — for example, keeping large fact tables in Direct Lake while using Import for small, highly flexible dimension tables that require Power Query shaping, calculated columns, or hierarchies. The real risk isn’t using Import tables; it’s drifting into them accidentally and re‑introducing refresh cost and data duplication without realizing it.

Scheduling and monitoring are also more limited compared to Dataflow Gen2. Yes, semantic models can be scheduled up to 48 times per day on Fabric capacity, but that’s still “dataset refresh scheduling,” not an ETL monitoring experience.

There’s also an honest ownership issue. When transformation logic lives inside the semantic model, it tends to be owned by the report team (or one heroic BI developer). That can work, but it often creates “shadow ETL,” where business-critical shaping happens in a place the data/platform team doesn’t naturally govern, test, or monitor.

One nuance worth knowing: Fabric does provide OneLake integration that can automatically write Import table data to Delta tables in OneLake (automatic OneLake integration for Import models). That’s useful, but it still doesn’t magically turn semantic model PQ into a governed, reusable engineering layer. The logic and lifecycle are still tied to the semantic model.

If you keep Semantic Model PQ focused on last-mile shaping, it stays your friend. If you let it become your data prep layer, it eventually becomes your weekend plan (and not in a fun way).

Dataflow Gen2: built for reuse and Direct Lake, with real operational trade-offs

If Semantic Model PQ is “fix it right where you see it,” Dataflow Gen2 is “build it once so everyone stops re-building it.”

Pros

Dataflow Gen2 is designed for ingesting and transforming data with a low-code interface, then loading it into destinations, including Fabric Lakehouse tables.

In a lakehouse-first pattern, this lines up perfectly with how Fabric Lakehouse works: tables are stored in Delta Lake format by default, which is the preferred table format for Fabric Lakehouse.

That means Dataflow Gen2 can land curated Delta tables in OneLake, and your semantic model can consume those tables via Direct Lake. This is exactly the “do prep upstream, analyze downstream” pattern Direct Lake is nudging you toward.

Operationally, Dataflow Gen2 has first-class monitoring. Refresh history and the monitoring hub provide run details (status, duration, trigger type), activity-level information, and even downloadable detailed logs from the mashup engine for troubleshooting. It also tracks capacity used for refresh, which is a big deal when you’re trying to manage Fabric cost and performance.

It also has a real CI/CD story. Dataflow Gen2 supports Git integration and deployment pipelines, and Microsoft provides solution architecture guidance for parameterization and stage-specific configuration.

Finally, Dataflow Gen2 is built to scale better than it looks. Under the hood, it runs on Fabric‑managed compute. Microsoft Fabric uses a combination of Spark‑based and SQL‑based execution paths depending on the source, transformations, and destination, and automatically creates managed staging Lakehouse and Warehouse items to optimize performance. Those staging items are managed by the platform and aren’t meant to be manually accessed or modified.

Cons

Dataflow Gen2 introduces another layer, and layers come with responsibilities. You now need to orchestrate refresh order (dataflow first, then downstream consumers). That’s manageable, but it’s real work. The reward is isolation: a semantic model refresh doesn’t have to also be an ingestion job, and failures can be investigated where they occur (in the dataflow run details).

There are also platform limits and throttling behavior to respect. For example, Fabric documents per-dataflow refresh limits per 24-hour window and notes that system-level throttling may reject bursty refresh patterns to protect service stability.

And then there’s the “invisible complexity” part: staging items exist, they can show up in some experiences, and Microsoft strongly advises you not to touch them because the data may not be consistent and changes can cause unexpected behavior. If you’ve ever wondered why a workspace suddenly has mysterious staging artifacts, it’s not you. It’s the platform doing platform things.

A final trade-off: Dataflow Gen2 is best when you treat its output schema as a contract. If downstream semantic models depend on stable columns and types, you need change management discipline. The tooling helps, but it can’t replace good habits.

The good news is this: those are the kinds of growing pains you want. They mean you’re building a reusable data layer, not just a one-off report.

Governance, lineage, CI/CD, and cost: the practical differences people feel

Here’s the part that usually convinces teams (or scares them, depending on the week).

Governance and ownership

Direct Lake guidance explicitly encourages upstream preparation to maximize reusability across the architecture. That’s naturally aligned with a data/platform team owning Dataflow Gen2, while BI teams focus on semantic modeling and measures.

Lineage

Fabric and Power BI both provide lineage views to help understand dependencies across workspace artifacts, including semantic models and dataflows. That visibility is much stronger when your transformations exist as distinct workspace items (like dataflows and Lakehouse tables), rather than being hidden inside a single semantic model.

There is a nuance: Correct lineage between semantic models and dataflows is guaranteed only when the connection is set up using the Get Data UI and the Dataflows connector, not when someone hand-writes a mashup query. This is one of those “it works until it doesn’t” details worth standardizing early.

CI/CD

Both semantic models and Dataflow Gen2 are supported items for Fabric Git integration (currently marked preview for some Power BI items).

But Dataflow Gen2 goes further with explicit CI/CD documentation, deployment pipeline automation guidance, and patterns for stage-specific configuration.

Semantic models do have strong ALM support through deployment pipelines, but there are gotchas: deployment pipelines move metadata, not data, and don’t copy things like refresh schedules or credentials. That matters in real deployments more than people expect.

Cost and capacity

Direct Lake reduces the heavy refresh cost because framing is low-cost compared to Import refresh that copies full data. Dataflow Gen2 shifts cost into the ingestion/transform layer (which is usually where you want it), and its monitoring surfaces capacity usage during refresh so you can manage that cost deliberately.

This is where the mentor advice kicks in: don’t optimize for “fewer artifacts.” Optimize for “fewer surprises.”

Summary table and a decision gut-check

Here’s a comparison table:

If you want one practical rule that won’t embarrass you later, it’s this:

If the transformation is meant to be shared, trusted, and reused, put it in Dataflow Gen2 and land it in Lakehouse tables, then use Direct Lake for the semantic model.

If the transformation is truly report-specific, small, and unlikely to be reused, Semantic Model PQ can be fine, but keep it small on purpose.

And if you’re unsure which camp it’s in, that’s your answer. Put it upstream. Your future self (and your on-call rotation) will thank you.