Granular APIs for OneLake security (Preview)
Microsoft Fabric continues to expand the OneLake security surface with new granular REST API support for role management, giving developers and platform teams far more control over how security policies are created, retrieved, and managed programmatically. In addition to the existing batch role API, Fabric now offers discrete Create, Get, and Delete role APIs, making it easier to build incremental, automation-friendly security workflows that align with modern DevOps and governance practices. Previously, managing security roles through the API required submitting full role collections as a single batch. While this model works well for bulk operations, it can be cumbersome for applications that need to make targeted updates or respond dynamically to change. With the new granular APIs, clients can now interact with roles individually—retrieving a single role, updating or creating a role definition, or deleting a role—without needing to reason about the entire role set for an item. The new Get role API enables clients to fetch a specific security role by name, allowing tooling and services to inspect current policy state before taking action. This is especially useful for validation, auditing, and drift detection scenarios, where understanding the effective permissions of a single role is required without pulling the full configuration. For authoring and updates, the Create / Update role API allows callers to define or modify a role independently, including its decision rules and member assignments. Roles can express fine-grained permissions, such as scoped read access to specific tables or paths, and can include Microsoft Entra principals directly. This unlocks cleaner CI/CD pipelines, where individual security changes can be deployed, reviewed, and rolled back just like application code—without needing to reapply unrelated role definitions. The Delete role API completes the lifecycle by enabling safe and explicit removal of roles that are no longer needed. This makes it easier to keep security configurations clean over time, particularly in dynamic environments where workloads, users, and policies evolve continuously. Image of an API swagger document, listing the previous GET and PUT APIs alongside the new POST, GET, and DELETE APIs. Together, these APIs are designed for builders who need precision, composability, and automation: SaaS partners integrating Fabric security into their control planes, enterprises managing policy as code, and teams building internal tooling for governance at scale. The existing batch API remains available for bulk operations, while the new granular APIs offer a simpler and more flexible model for day‑to‑day role management. This update is part of our broader investment in making OneLake security open, interoperable, and developer‑first, ensuring that security in Fabric can integrate naturally with external systems, pipelines, and governance tools. As always, we’re excited to see how customers and partners use these new capabilities to build more secure and automated data platforms on Fabric. To learn more, refer to the OneLake security API reference.Simplifying secure data access with Delegated OneLake Shortcuts (Preview)
Introduction Data rarely stays in one place. As organizations standardize Microsoft Fabric and OneLake, the same datasets need to be reused across teams, domains, workspaces, and increasingly across tenant boundaries. The challenge is no longer moving data; it is sharing it securely, consistently, and at scale without creating copies, breaking governance, or forcing every consumer to be individually provisioned at the source. OneLake Shortcuts already solve a large part of this problem. A shortcut presents data where people need it while the data stays in its original location, enabling a true zero-copy approach to distribution. By default, OneLake Shortcuts use pass-through authentication: when a user reads a shortcut, Fabric accesses the target data using that signed-in user’s identity, and the data owner controls access directly on the target. Pass-through is the right model for many collaborative scenarios, but customers have consistently told us it does not fit every access pattern. Two points came up frequently: Access management does not scale. When a curated dataset must be served to thousands of downstream users across multiple teams, the data owner becomes responsible for granting and maintaining every individual user’s permission on the source, an operational bottleneck that grows with every new consumer. Cross-tenant sharing is harder than it should be. Multi-tenant organizations told us that they need to access data residing in OneLake across their own tenant. These are not edge cases. They are everyday realities for enterprises building governed, reusable data products on Fabric. The preview of Delegated OneLake Shortcuts — including delegated sharing both within a tenant and across tenants — gives data owners a simpler, governed way to distribute data without compromising on security. Introducing delegated OneLake Shortcuts Delegated OneLake Shortcuts add a second authentication option to the existing shortcut experience you already know. Instead of accessing the target data as each signed-in user, a delegated shortcut accesses the target through a configured connection identity. That identity can be an organizational account, a service principal. This identity is attached to the shortcut, so all access to the shortcut reaches the target as the delegated identity. Delegated authentication is entirely optional and complements the default experience. If a user does not choose delegated authentication when creating a shortcut, the shortcut continues to use pass-through authentication exactly as before. The default flow is unchanged; delegation is simply there when you need it. How it works A delegated shortcut behaves like other external shortcuts in Fabric. When you create one, you sp, and that connection is used to browse and read the target data. This brings a familiar, governed connection model to OneLake-to-OneLake sharing. Identity delegation - Downstream users access the data through the delegated identity rather than their own, so the data owner no longer must provision each individual consumer on the source item. Secure access enforcement with OneLake security - OneLake security roles can be configured on both the data producer and data consumer delegated Shortcuts. At the time of this writing, table level security and column-level security are supported for delegated shortcuts, on both the target (where you are creating the shortcut) and the shortcut source (where data resides). Delegated permissions management - A shortcut can delegate as a fixed identity that represents a business unit. The central data owner controls what that identity can see, while the business unit manages OneLake security for its own end users, all while still honoring the controls applied to the delegated identity. Cross-tenant sharing Delegated shortcuts also work across Microsoft Fabric tenants. A cross-tenant delegated shortcut lets you create a OneLake shortcut to data that lives in another organization’s Fabric tenant. You provide a connection path to the external OneLake data and authenticate with an identity from that tenant; downstream users then access the external data through the configured delegated identity, without each user needing individual cross-tenant permissions. This makes delegated shortcuts a natural fit for multi-tenant enterprises, for example, sharing curated data between an organization’s test and production tenants, or between a parent company and a subsidiary using the same zero-copy, intersection-based security model that applies within a tenant. Difference between External Data Sharing and delegated Shortcuts Microsoft Fabric has External Data Sharing, a feature that enables Fabric users to share data from their tenant with users in another Fabric tenant. External data sharing can be used when the consumer has no identity in the producer's tenant, such as sharing across organizational boundaries with an outside partner or customer. This is ideal when you must share with partners or when ISVs must share data with their customers and don’t want to have the consumer identity in their tenant. Cross-tenant delegated shortcuts are used when the data consumer has an identity, such as an organizational account or service principal, in the producer’s tenant. For example, an organization can share data between its own test and production tenants, with access flowing through the configured delegated identity. Use cases Delegated OneLake Shortcuts are designed for the moments when the default pass-through behavior does not match the access pattern you want for a data product. Common scenarios include: Departmental data sharing at scale - Represent each department with a delegated identity, scope what that identity can see, and let department owners manage access for their own users instead of routing every request through the central data owner. Cross-tenant and subsidiary sharing - Share curated data between tenants — such as test-to-production or parent-to-subsidiary — with no data copies and the same delegated security model. Getting started Open the target Fabric item, such as a Lakehouse, and select Get data > New table shortcut. In New shortcut, select Microsoft OneLake, then choose the source you want to shortcut to. For cross-tenant data, select Enter connection details and provide the external OneLake path. For Connection method, select Delegated identity, then Connect. Choose an existing connection or create a new one by providing the OneLake path, a recognizable connection name, and an authentication kind (organizational account or service principal). Sign in to complete authentication. Browse the source, select the folders or tables to include, then review and create the shortcut. To switch an existing shortcut between pass-through and delegated authentication, delete and recreate it with the desired method. For detailed steps, refer to the OneLake Shortcuts documentation. Conclusion and next steps OneLake shortcuts are a foundational building block for zero-copy data distribution across Microsoft Fabric. Delegated OneLake Shortcuts extend that foundation to the scenarios enterprises care about most: serving curated data to large audiences, delegating access management to the teams closest to the users, and sharing securely across tenant boundaries. Together, pass-through and delegated shortcuts let organizations choose the right balance of control, scale, and simplicity for each data product. Pass-through keeps source-managed authorization per person for collaborative engineering. Delegated mode turns a shortcut into part of a governed publishing architecture: central teams retain ownership of the source, consuming teams avoid copying data, and downstream audiences access a managed experience rather than raw-path access — without ever giving up the governance benefits of unifying data in OneLake. Share your feedback, use cases, and questions in the Microsoft Fabric Community. Your input directly shapes the roadmap.
FabCon and SQLCon Barcelona 2026: What’s new in Microsoft OneLake and its rapidly growing ecosystem
If you haven’t already, check out Arun Ulag’s hero blog “FabCon and SQLCon 2026 in Barcelona: Building the data foundation for Microsoft Copilot and Agents” for a complete look at all our FabCon and SQLCon announcements across both Fabric and our database offerings. Organizations are moving quickly to turn AI into meaningful business outcomes. But the value of AI still depends on the data behind it: whether teams can find the right data, access it securely, and use it across the tools and platforms where agents work. When data remains fragmented across clouds, business units, and technology stacks, every new AI initiative starts with the same costly work of moving, copying, and reconciling data. Microsoft OneLake provides a unified data foundation for Microsoft Fabric, helping organizations connect and govern data across their estate without creating more silos. Every Fabric user and customer is also a OneLake user and customer and at FabCon and SQLCon Barcelona 2026, I’m excited to share that we're expanding OneLake further to continue on our principal of providing customers an open, secure, and scalable foundation for connecting and sharing data and putting governed data to work across analytics and AI, Connect and share data across your distributed estate Data is increasingly distributed across clouds, applications, partners, and platforms. OneLake helps organizations work across that distributed estate without requiring every team to move and maintain another copy of the data. Share governed data and context with IQ sharing An organization’s unique IQ is its data, knowledge, and workflows. When copilots, agents, and applications can draw on this shared understanding of the business, they can deliver more consistent and relevant experiences. But that context needs to be governed and reusable so the same terminology, relationships, instructions, and domain knowledge can be applied across teams and applications. Today, we’re introducing IQ sharing in preview soon, a new capability that enables organizations to securely share governed data and business context across teams, business units, customers, partners, and ecosystems. This makes trusted organizational context portable and reusable, extending it beyond a single team or organization. At launch, IQ sharing supports data, metadata and context represented in files, including Markdown (.md) agent instructions and RDF (.rdf) ontologies. We plan to expand these capabilities with native support for Fabric IQ ontologies and Power BI semantic models, making it easier to securely share and reuse business context across AI experiences. EY, TomTom, S&P Global, Financial Fabric, and xMentium are already building integrations with IQ sharing, with more partners to come. TomTom, for example, is bringing its geospatial and transportation intelligence into Fabric through IQ sharing, with available data products discoverable through the OneLake catalog. "Trusted location data is a foundational ingredient for our customers' applications, AI solutions, and intelligent agents," said Leo Sei, Chief Product Officer, TomTom. "We're excited to be one of the first partners to onboard to IQ sharing and extend access to TomTom location data products across our customers' analytics and AI ecosystems. IQ share makes our data easy to discover, securely distribute, and centrally govern while preserving the control, context, and trust that are critical for delivering AI-ready data products." John Whittaker, VP of Cloud Marketplace at EY, sees similar potential for IQ sharing to make business context more portable and reusable: “In collaboration with Microsoft, IQ sharing is an important step toward making context reusable, governed, and portable, with the potential to bring trusted knowledge, methods, and domain insight to clients in new AI-enabled ways, helping people move faster, support stronger decision-making, and scale value with confidence.” Together, OneLake and IQ sharing provide an open foundation for distributing governed intelligence, helping organizations reuse trusted data and business context to power analytics, applications, copilots, and agents. Figure: Creating a new IQ sharing item to share governed data and business context. Connect and transform data across your entire estate We’re continuing to expand OneLake’s open data network across platforms, clouds, and business applications, giving organizations more ways to work with distributed data through a shared data foundation without having to move, duplicate, or maintain additional copies. Connect Salesforce Data 360 to OneLake with bidirectional integration OneLake and Salesforce Data 360 are coming together to give customers a simpler way to use their Salesforce data across Microsoft Fabric without moving or duplicating it. With OneLake shortcuts, Salesforce Data 360 data becomes part of the unified data estate, where teams can discover it in the OneLake catalog and use it across Fabric workloads, including SQL, notebooks, and Power BI. Customers can also use Salesforce data to build ontologies that provide rich business context to Fabric data agents, helping them reason over it alongside the rest of their enterprise data. Get started now. Figure: Connecting OneLake with Salesforce Data 360 through a OneLake shortcut. Because OneLake shortcuts access data directly from Salesforce storage, customers can work from a single copy of always-current data without building pipelines, paying for duplicate storage, or keeping copies in sync. Queries use Fabric compute without placing additional load on Salesforce instances, while Salesforce administrators remain in control of what data is shared. Salesforce controls and OneLake security provide governed access across Fabric, giving customers the flexibility to use their Salesforce data for analytics and AI while keeping it securely managed. Access versioned lakeFS data through OneLake shortcuts OneLake shortcuts now provide a complementary way to access versioned data managed in lakeFS from Microsoft Fabric. Customers can connect to the latest data from a lakeFS branch or reference a specific immutable commit, helping them create reproducible reports, experiments, and audits without building separate pipelines to copy and maintain snapshots of their data. Mirror Dynamics 365 Business Central data into OneLake We’re also extending this connected data foundation to Dynamics 365 Business Central. A new integration enables organizations to bring selected Business Central tables and company data directly into OneLake through mirroring. Built-in monitoring provides both overview and detailed logs, helping teams track integration health and troubleshoot issues. Read and write OneLake data from Azure Databricks For organizations working across data platforms, we’re strengthening interoperability with Azure Databricks through native storage in OneLake, now supported in production. This gives joint customers a more direct way to use OneLake data from Azure Databricks without copying it into another storage layer, helping teams preserve a consistent data foundation across platforms. Connect more external data to OneLake through open standards We’re continuing to extend the range of external data that organizations can make available through OneLake. Mirroring for Google BigQuery is now available, making it easier to work with Google Cloud data in Fabric for analytics and AI while reducing duplication and bespoke integrations. New Apache Iceberg-based catalog federation support for AWS Glue Data Catalog, Google Lakehouse runtime catalog, and CONNECT from AVEVA further expands the data organizations can discover and use through OneLake, bringing more of the distributed data estate within reach of Fabric. Operate and scale OneLake with greater flexibility An enterprise data foundation must be flexible to operate and powerful to use. Organizations need simpler ways to align costs with demand, monitor their data estate, and scale as analytics and AI workloads grow. On-demand billing brings more flexibility to OneLake compute In the coming weeks, we’re introducing on-demand billing for OneLake compute in preview, allowing customers to pay only for the OneLake compute they use. Previously, access to data in OneLake depended on a running Fabric capacity, which could be affected by pauses or throttling. With on-demand billing, OneLake compute can scale elastically when needed, helping minimize throttling during demand spikes. We’re also introducing Fabric zero-provisioned (F0), a new entry point to Fabric and OneLake that removes the need to provision compute before getting started. With on-demand billing enabled by default, organizations can immediately access Fabric services and pay only for the resources they use. Together, on-demand billing and Fabric zero-provisioned allow organizations to read and write data without maintaining dedicated capacity. The announcement builds on Microsoft’s broader vision of OneLake as a shared data foundation across platforms such as Fabric, Azure Databricks, and Snowflake. Recent interoperability enhancements allow organizations to store and access a single copy of data across these environments, reducing duplication and simplifying data architectures. By decoupling OneLake access from Fabric capacity, on-demand billing makes it easier for customers to adopt OneLake as their centralized enterprise data lake while continuing to use the compute engines that best fit their needs. This applies to AI workloads as well. Microsoft Foundry can seamlessly be used with OneLake on-demand billing as well. Put OneLake data to work across analytics, AI, and applications Connecting data is only the first step. Organizations also need to make governed data easy to discover and use across the tools, applications, and AI experiences where people and agents work. Discover and use governed data in Microsoft Foundry and Excel Data becomes more valuable when people can discover and use it from the tools where they already work. A new OneLake catalog integration in Excel, available through the modern Get Data experience, helps business users discover and analyze organizational data directly from Excel. By reducing the steps between discovery and analysis, the integration helps more users work with governed Fabric data through a familiar experience. We are also announcing deeper integration with Microsoft Foundry, our end-to-end platform for customizing, hosting, running, and managing AI solutions. With this integration, you can access the OneLake catalog in Foundry, making it easy to discover and build knowledge directly from OneLake data. Foundry users can explore their data estate including rich metadata, endorsements, sensitivity labels, and descriptions, and connect their OneLake items with a single selection to add data to Knowledge. Figure: Adding OneLake data as knowledge in Microsoft Foundry. Give agents, applications, and data engines secure access to OneLake tables The OneLake Table Read API (Preview), gives AI agents and applications secure, serverless access to Delta Lake and Apache Iceberg tables without requiring SQL. OneLake security automatically enforces table-, row-, and column-level access controls on every query, returning only authorized data. Built on open-source Apache Arrow, the API helps developers efficiently integrate governed enterprise data into AI agents and applications. We’re also expanding the ways external data engines can work with OneLake through open APIs. ClickHouse support for reading Apache Iceberg tables from OneLake using OneLake Table APIs is now generally available, enabling customers to query OneLake data directly without creating another copy. Support for writing Iceberg tables to OneLake using Table APIs and credential vending (Preview), allowing results produced in ClickHouse to become part of the shared OneLake data foundation and available across Fabric. In addition to working with OneLake data directly through Table APIs, customers can use the new ClickHouse workload in Microsoft Fabric when they want dedicated analytical compute. Now in public preview, the experience provisions a dedicated ClickHouse Cloud service on Azure and includes an embedded SQL console within Fabric. Teams can synchronize OneLake tables as accelerated, point-in-time copies for analysis in ClickHouse Cloud, while OneLake remains the source of truth. This gives developers a dedicated environment for responsive analytics, interactive applications, and AI agent experiences while keeping those workloads connected to their Fabric data. Teradata Autonomous Knowledge Platform is integrated OneLake Table APIs, enabling enterprise customers to run Teradata's high-performance enterprise AI directly on data stored in OneLake, without extract, transform, and load (ETL) pipelines, data duplication, or migration. Built on open Apache Iceberg standards, the integration allows Teradata users to query OneLake tables in place using standard Iceberg APIs, with cross-platform authentication and access controls handled natively. Enterprises with data in both environments can now join and analyze it without first consolidating it into a single system or rebuilding governance from scratch. LakeSail Cloud further expands the engines that can work with data in OneLake by bringing Rust-native Spark compatibility to Delta Lake and Apache Iceberg tables. With LakeSail, teams can use Spark SQL, DataFrame, and Python workloads to read and write OneLake tables without deploying separate data connectors or changing existing Spark code. This gives organizations another way to use the processing engines that fit their workloads while keeping data in the shared OneLake foundation. Build operational applications on OneLake Organizations increasingly need to turn governed data into applications and workflows that help people make decisions and take action. OneLake provides a shared foundation for these operational experiences, keeping applications and their data connected across Fabric. Last May, we introduced Fabric Apps to help developers build and deploy data and AI-powered applications on trusted, governed data in Microsoft Fabric. We’re now expanding Fabric Apps with support for OneLake sources alongside existing SQL databases. Developers can connect applications to Fabric warehouses, lakehouses, and Power BI semantic models while preserving existing permissions and trusted business logic. This brings applications closer to the data they rely on and reduces the need to move or duplicate data across systems. We’re also deepening the integration between Planning in Fabric (Preview) and OneLake. Now, planning data and writeback can be stored directly in OneLake, enabling teams to work across larger models and with more contributors while maintaining a responsive experience. These improvements increase planning performance and scale by up to 10x, while keeping planning outputs readily available for use across the broader Fabric ecosystem. Check out all the innovation coming to Planning in Fabric in my other blog, Planning in Microsoft Fabric: From insight to action. Discover, govern, and protect your data estate As data becomes available to more people, applications, and agents, governance and security become even more important. Organizations need a unified way to discover their data, manage access, and apply consistent protections wherever that data is used. Discover more of your data with deeper lineage in the OneLake catalog The OneLake catalog is becoming a richer, more granular place to discover and understand data across Fabric. Users can now go beyond finding Fabric items to explore individual tables and columns, view their details, and preview the underlying data directly in the catalog, making it easier to evaluate data before putting it to work. More granular search makes it easier to find that data across Fabric. The OneLake catalog search API now returns OneLake tables and semantic model tables alongside Fabric items in a single relevance-ranked result set. New Spark granular runtime lineage, coming soon, adds another layer of context, helping users understand how data is used and transformed across their data estate. Manage and govern your data estate in the OneLake catalog Discovery is only part of the equation. The OneLake catalog Govern experience brings centralized governance capabilities into the OneLake catalog, helping administrators manage their data across tenant, domain, capacity, and workspace scopes from a unified experience. Automatically generated signals and proactive recommendations help administrators understand their governance posture, identify areas that need attention, and take informed action. Figure: Reviewing data estate health and governance recommendations in the OneLake catalog. Governance also extends into developer workflows. Govern Skills for Fabric enable AI coding assistants such as GitHub Copilot to discover existing Fabric items and tables through the OneLake catalog. This supports a find-before-you-build approach, helping developers find and reuse governed data before creating new assets or writing code. Connect OneLake data with trusted context from Atlan Understanding data requires more than knowing where it lives. Teams also need the business context, lineage, and governance information that explain what data means and how it is used. We’re expanding our integration with Atlan, an industry-leading provider of data and AI governance that helps organizations discover, understand, and govern data across their enterprise. Atlan’s native Microsoft Fabric connector (Generally Available) and adds deeper lineage across semantic models and measures, Spark workloads through the new Fabric Platform Lineage APIs, and Dataflow Gen2. The integration also extends in the other direction with OneLake shortcuts, enabling teams to access Atlan context and Atlan lakehouses from within Fabric and query it using Fabric Spark and SQL capabilities. Together, these integrations bring OneLake data and the context surrounding it closer together, helping teams better understand and govern the data they use for analytics and AI. Apply more precise policies across Fabric Policies in Fabric (Preview) introduce precise, attribute-based controls that help organizations enforce governance requirements based on user and data attributes, rather than relying only on broad administrator settings. Policies support granular controls for key scenarios, with item creation and workspace security available at launch and external data sharing coming soon. Policies also come with a centralized policy management experience, along with monitoring and APIs that make it easier for administrators to manage and track policies across Fabric. CI/CD integration helps teams automate the policy lifecycle as their environments grow. For example, external data sharing policies will give administrators more flexibility over cross-tenant collaboration. Rather than simply turning external sharing on or off, organizations can apply more granular controls based on attributes such as users, workspaces, and recipients, helping teams collaborate externally while maintaining the controls needed for security, governance, and compliance. Strengthen data protection with OneLake security As access to data expands across users, applications, AI agents, and platforms, organizations need security controls that remain consistent wherever that data is used. New OneLake security capabilities make it easier to understand and manage access within OneLake, preserve existing protections as data moves across platforms, and control how OneLake connects to external sources. We’ve redesigned the View users in role experience for OneLake security, now generally available, to simplify permissions auditing and management. New views help administrators quickly understand who can access a specific table and what data an individual user can see. From the same experience, they can assign users to multiple roles or revoke access, making it easier to review and manage permissions as data usage grows. We’re also making it easier to maintain consistent protections for data used across platforms. Trust3.AI is introducing a capability that synchronizes row- and column-level policies between Databricks, Snowflake, and OneLake security. By mapping policies from these platforms to OneLake security rules, the integration helps organizations maintain consistent access controls for users, applications, and AI agents without manually recreating policies in each environment. Mirroring for Snowflake brings Snowflake data into OneLake and keeps it synchronized for use across Fabric. Until now, customers have had to recreate the security policies governing that data after it was mirrored. With Snowflake Security Roles Replication, now in public preview, organizations can replicate source-defined roles and permissions alongside their data and translate them into OneLake security. This carries important governance context with the data and reduces the need to manually rebuild access controls as organizations bring their Snowflake and Fabric data estates together. Finally, outbound access protection for OneLake shortcuts (Generally Available), giving Fabric administrators control over which external data sources and endpoints shortcuts in a workspace can connect to. These controls help reduce the risk of unintended or malicious data exfiltration while still allowing approved connections that support business needs. Expand what you can do through the Fabric partner ecosystem OneLake provides a shared data foundation that partners can build on to bring specialized capabilities directly into Microsoft Fabric. At FabCon and SQLCon Barcelona, we’re expanding the Fabric partner ecosystem with new workloads that give organizations more ways to analyze, manage, and act on the data in OneLake without leaving Fabric. Esri: bring location context to business analysis (Generally Available) Location can reveal patterns and relationships that are difficult to see in rows and columns alone. Esri’s ArcGIS Maps for Microsoft Fabric brings mapping and spatial analysis into Fabric, helping teams explore their business data geographically. Stream Layers add support for real-time information, while expanded Parquet and OneLake mapping makes more organizational data available for spatial analysis. Enhanced authoring, symbology, and sketching capabilities give analysts more flexibility to tailor maps to the questions they want to investigate. Learn more about ArcGIS Maps for Microsoft Fabric. Figure: Exploring spatial patterns with ArcGIS Maps for Microsoft Fabric. Telmai: Build confidence in the data behind every decision Reliable analytics and AI depend on knowing whether the underlying data is complete, current, and ready to use. Telmai Data Reliability for Microsoft Fabric, now generally available, continuously monitors critical OneLake tables for changes in data volume, schema, freshness, and completeness. Telmai uses context from the OneLake catalog to help teams focus their monitoring on critical data assets. AI-assisted incident correlation connects related issues across the data estate, while Ask Telmai provides a conversational way to investigate potential causes instead of reviewing isolated alerts one by one. Telmai can also make machine-readable trust signals available to Fabric data agents and other compatible AI clients, helping both people and AI-driven experiences account for data reliability when using OneLake data. Figure: Configuring Telmai monitors for critical OneLake tables in Fabric. Celonis: understand how work flows and where it can improve (Generally Available) Business processes rarely follow a simple path. Celonis Process Intelligence brings process visualizations and business context into Fabric, helping teams understand how work moves across their organization using the data they already have. Users can explore process flows, investigate inefficiencies and their root causes, and identify opportunities for improvement alongside the analytics they use to understand the rest of their business. Learn more about Celonis. Figure: Analyzing supply chain process flows and performance with Celonis in Fabric. Spectral Core: simplify database migration to Fabric (Generally Available) Spectral Core Fabric Migration brings data movement, SQL code translation, schema and object conversion, and validation into a guided Fabric experience. Teams can work through the steps involved in migrating databases with a clearer view of what is being moved and where additional attention is needed. Learn more about Spectral Core for Fabric. Figure: Monitoring database migration progress with Spectral Core Fabric Migration. Financial Fabric: bring capital markets data closer to analysis (Generally Available) Financial Fabric’s Capital Markets DataHub brings data from more than 200 data providers and 10,000 datasets into Fabric, helping investment, risk, and operations teams reduce the work required to source and access financial data. Ask DataHub provides conversational exploration, while Power BI Direct Lake analytics connects that data to familiar analysis experiences. Learn more about Financial Fabric. Figure: Discovering capital markets datasets in Financial Fabric DataHub. IntuigenceAI: turn industrial information into usable knowledge (Generally Available) IntuigenceAI helps energy and process manufacturing teams turn information spread across drawings, schematics, datasheets, and logs into a queryable knowledge graph. Its AI synthetic engineers provide a multilingual conversational experience for retrieving information and supporting engineering work, with data residing in the customer’s OneLake. Learn more about IntuigenceAI for Fabric. Figure: Using IntuigenceAI to retrieve engineering insights from industrial documents in Fabric. Metropolis: connect communications data with business outcomes (Preview) Metropolis VoiceLake normalizes supported communications data into a Fabric Lakehouse and provides ready-made Power BI reports and a semantic model for exploration. Organizations can combine communications records with other business data for analytics and AI, providing a broader view of service activity and operational performance. Learn more about Metropolis VoiceLake. Figure: Monitoring communications analytics and integrations with Metropolis VoiceLake. Figure: Exploring and validating data with natural-language analysis in Daivio. And there are many more. Together, these partner workloads extend the ways organizations can analyze, manage, and act on their data in Fabric. Customers can explore these experiences in the Fabric Workload Hub and choose the specialized capabilities that fit their business needs. Figure: Monitoring cloud and AI spending with Data-Driven AI CloudMonitor. Build on a more open, secure, and manageable data foundation These announcements advance a common goal: helping organizations make more of their data available for analytics and AI without creating more copies or giving up control. IQ sharing, shortcuts, mirroring, and deeper platform interoperability connect data across organizational and technology boundaries. The OneLake catalog, security, policies, and expanded partner integrations help teams discover, understand, govern, and put that data to work. And with more flexible billing and stronger monitoring, organizations can operate and scale their data foundation as their needs grow. Explore more Microsoft Fabric innovation Alongside these OneLake announcements, we are introducing several innovations across Fabric. For a broad overview of all these announcements, read Arun Ulag’s hero blog “FabCon and SQLCon 2026 in Barcelona: Building the data foundation for Microsoft Copilot and Agents.” If you want more details, check out the Fabric September 2026 Feature summary blog and the latest posts on the Fabric Updates channel, including my other blog: Planning in Microsoft Fabric: From insight to action.Copy job for SAP with ABAP Add-On in Microsoft Fabric (Preview)
SAP systems sit at the center of many enterprises’ core business operations, powering processes across finance, supply chain, manufacturing, procurement, and HR. That makes SAP data some of the most business-critical data in the enterprise. As organizations modernize their analytics and AI platforms, bringing SAP data together with the rest of the enterprise data estate has become increasingly important. But moving SAP data at enterprise scale has historically been difficult. SAP landscapes are complex, data volumes are large, and extraction architectures often require specialized frameworks, custom code, and additional operational layers. For many organizations, this creates friction between where their most important operational data lives and where they want to analyze, enrich, and activate it. We are delivering the next step of our SAP roadmap: Copy job for SAP with ABAP Add-On in Microsoft, this new capability complements offerings like: SAP Business Data Cloud Connect was announced in SAP and Microsoft accelerate business insights and AI innovation with SAP Business Data Cloud Connect for Microsoft Fabric and will be available over the coming months). It will enable bi-directional zero-copy sharing between SAP Business Data Cloud and Microsoft Fabric without the need for data movement. Mirroring via SAP Datasphere, a turnkey data replication capability providing scalable near real-time data movement from SAP sources into Fabric OneLake (Generally Available). To learn more, refer to the Fabric mirroring documentation. Now, organizations can extract large volumes of SAP data through Copy job, reduce the need for external extraction frameworks, and build a scalable path from initial ingestion to ongoing incremental updates. Copy job provides a configuration driven experience for moving data across clouds, applications and on-premises systems – designed to support high-scale, multi-cloud data movement for petabyte-scale ingestion scenarios. Copy job helps bring data into OneLake as part of a unified, governed foundation for analytics and AI. High-performance SAP extraction with Copy job and Microsoft ABAP add-on integration This new integration option enables scalable, high-throughput extraction from SAP systems, making it easier than ever to bring large volumes of SAP data into Microsoft Fabric for analytics, reporting, and AI. Figure: High-level architecture diagram of Copy job with ABAP Add-on. Broad data coverage across SAP Systems Extracting data from SAP systems at scale can be complex and resource intensive. This new capability simplifies the process while delivering high performance. The solution runs directly inside SAP using a Microsoft-provided ABAP Add-On. Data is extracted at the application layer and transferred efficiently through Copy Job in Fabric Data Factory. This removes the need for complex external extraction frameworks and reduces operational overhead. It supports a wide range of SAP data sources. You can extract from SAP tables, views, and ABAP CDS views, including semantically rich models used for analytics. The capability works across both SAP ECC and SAP S/4HANA, whether deployed on-premises or in the cloud. Providing consistent access to both raw operational data and business-ready data models. Flexible data delivery styles for real-world SAP scenarios Through the integration with Copy Job, the solution handles data movement at scale. The integration is designed for high throughput and efficient processing of large datasets. Parallel execution capabilities help accelerate ingestion and reduce data transfer times. The solution supports different loading strategies depending on your needs. You can perform full snapshots for initial ingestion or bulk replication scenarios. For ongoing updates, incremental loads can be configured using watermark-based extraction. This allows you to process only the data that has changed. Together, these capabilities make it easier to design efficient pipelines. You can start with a large initial load and then transition seamlessly to incremental updates, without changing the overall architecture. SAP data in OneLake, ready for analytics and AI After ingestion, SAP data is immediately available in Microsoft OneLake. From there, it can be used across the entire Fabric platform. You can build Power BI reports directly on SAP data and operational datasets. You can run large-scale analytics workloads or combine SAP data with non-SAP sources from across your organization creating a unified data foundation without silos. With all data in one place, it also becomes easier to enable AI-driven scenarios. Applications and data agents can access consistent, trusted business data to generate insights and drive automation. Get started For more information, refer to the ABAP Add-On for SAP data extraction with Copy Job in Microsoft Fabric documentation. You can start exploring this capability today to: Accelerate SAP data ingestion Simplify data extraction architectures Enable scalable analytics and AI scenarios Looking ahead Copy job for SAP with Microsoft ABAP Add-On is another step in our continued investment in SAP data integration for Microsoft Fabric. SAP is one of the most important enterprise data sources for our customers, and Data Factory in Fabric is designed to help organizations bring SAP and non-SAP data together through scalable, flexible data movement experiences. With Copy job, customers can move data across clouds, applications, and on-premises systems into OneLake. With the Microsoft provided ABAP Add-On, that same Copy job experience now extends more deeply into SAP, helping customers bring business-critical SAP data into Fabric for analytics, reporting, and AI. We will continue expanding SAP data integration capabilities across Microsoft Fabric so customers can simplify their data architectures, reduce silos, and build a unified, governed foundation for enterprise analytics and AI.
Lineage-aware AI with the Fabric item relations API (Preview)
With two new REST operations, you can retrieve the upstream and downstream relations of any Fabric item directly from your own code — the dependency graph behind the portal's lineage view, now available as a supported, programmable surface. Each response includes related items, the typed relation edges that connect them, and the workspaces those items belong to. Lineage has always answered two human questions: “where does this data come from?” and “what breaks if I change it?” This API lets your tools — and your AI agents — ask those same questions programmatically. What’s new Until now, item lineage in Fabric was something you explored visually in the portal. You opened an item, looked at its lineage view, and traced dependencies by eye. That’s great for people, but it’s difficult to automate. With this update, lineage becomes an API. After authenticating to Fabric, you can programmatically: Get the downstream relations of an item — everything that depends on it (its consumers and impact radius). Get the upstream relations of an item — everything it depends on (its sources). Read the typed relation edges between items (for example, Shortcut, PushData, Orchestration). Resolve related items across workspaces, using the workspace list returned alongside the graph. Feed lineage into impact analysis, documentation, data catalogs, CI/CD checks, and AI agents. Why this matters If you only work in the Fabric portal, the lineage view already serves you well. The impact of this update shows up once you need to automate or scale — when understanding dependencies becomes part of a workflow rather than a manual click-through. A few examples: Before you delete or reroute a dataset, you call the downstream API to see every report, semantic model, and pipeline that would be affected. You build an internal catalog or documentation site that shows each item’s sources and consumers, kept fresh automatically. You add a CI/CD check that fails a deployment if a change would break a downstream dependency. You are an ISV building on Fabric, and you want lineage to be part of your product experience — not a side trip into the portal. That’s what a public API is for: turning a visual experience into a building block you can automate and compose. Lineage is context for AI AI agents are only as good as the context they are given. When an agent answers a question about a table, a report, or a metric, it benefits enormously from knowing where that data came from and what depends on it. Lineage is exactly that context. With the relations API, an agent can traverse an item’s dependency graph as part of its reasoning. Ask “is it safe to change this table?” and the agent can call the downstream API, enumerate the affected items, and ground its answer in the real graph instead of guessing. Ask “where does this number come from?” and it can walk upstream to the source. In other words, lineage helps ground AI responses in the actual dependency graph rather than inferred relationships. This is the same pattern we see across Fabric’s AI story: take governance metadata your organization already maintains — like sensitivity labels — and share it with AI so agents understand your data the way your organization does. Lineage joins that toolkit. It gives agents dependency awareness: the ability to reason about cause, effect, and blast radius, not just content. How it works At a high level, the API exposes both sides of the dependency graph: what an item depends on and what depends on it. The API adds two GET operations under the platform surface. Because the API is in preview, every call currently requires beta=true as a query parameter. GET /v1/workspaces/{workspaceId}/items/{itemId}/relations/downstream?beta=true GET /v1/workspaces/{workspaceId}/items/{itemId}/relations/upstream?beta=true The caller needs read permission on the item. Both user and service principal identities are supported. Each response is a small graph made of three lists: items — every item in the returned graph, including the item you queried, so each relation endpoint can be resolved (id, type, display name, and the workspace they belong to). relations — the edges, each with a source item, the item it depends on, and a relation type. workspaces — the workspaces referenced by those items, so you can resolve names across workspace boundaries. A downstream response for a semantic model consumed by a report looks like this: { "items": [ { "id": "3546052c-...", "type": "Report", "displayName": "Q4 Sales Dashboard", "workspaceId": "cfafbeb1-..." }, { "id": "9b218778-...", "type": "SemanticModel", "displayName": "Sales Semantic Model", "workspaceId": "cfafbeb1-..." } ], "relations": [ { "itemId": "3546052c-...", "dependentOnItemId": "9b218778-...", "relationType": "Association" } ], "workspaces": [ { "id": "cfafbeb1-...", "displayName": "Finance Analytics Workspace" } ] } The relation types describe how two items are connected. The set is extensible, so new types can be added over time: Relation type What it means Association The item consumes the dependency item — for example, a report built on a semantic model. Shortcut The item references data through a OneLake shortcut to another item. PushData The item writes or pushes data into the dependency item. Orchestration The item runs or manages execution of the dependency item (for example, a pipeline). Datasource The item reads from the dependency item as a data source — for example, a notebook reading a lakehouse. CascadeDelete A parent–child relationship; deleting the parent deletes the dependent. WeakAssociation A soft dependency that is removed if the dependent item is deleted. HiddenInWorkspace A dependency on an item that isn't surfaced in the workspace list, such as a staging artifact. Getting started A great first step is to pick a familiar item and explore its downstream relations to understand its impact radius. The following is the shape of a first call using the Azure CLI for authentication: 1. Authenticate to Fabric and get a token. $token = az account get-access-token ` --resource "https://api.fabric.microsoft.com" ` --query accessToken -o tsv 2. Call the downstream relations API for an item. GET https://api.fabric.microsoft.com/v1/workspaces/{workspaceId} /items/{itemId}/relations/downstream?beta=true Authorization: Bearer $token 3. Read the relations array to list what depends on the item, then walk upstream from any related item to trace it back to its sources. From there, wire the results into whatever needs dependency awareness — an impact-analysis check, a catalog page, or an AI agent’s context. You can find the operations in the Fabric REST API reference under the platform items surface: Items - Get Downstream Relations (beta) - REST API (Core) | Microsoft Learn Items - Get Upstream Relations (beta) - REST API (Core) | Microsoft Learn Exposing item lineage as a programmable API is a foundational step. It turns the dependency graph into something your tools, pipelines, and agents can read and reason over. We look forward to seeing what you build with it. Note: This API is in preview and provided for evaluation and development purposes. It may change based on feedback and is not recommended for production use.Mirroring for Google BigQuery in Microsoft Fabric (Generally Available)
Mirroring for Google BigQuery in Microsoft Fabric is now generally available. For organizations running critical workloads on BigQuery, this means a simpler, faster, and lower-cost path to bringing your data into the rest of your analytics estate — with production support, an enterprise SLA, and no pipelines to build or maintain.
Fabric July 2026 Feature Summary
Welcome to the July 2026 Fabric update! This month brings new capabilities across the Fabric experience, from improved deployment and governance experiences to expanded Spark, Eventstream, and Real-Time Intelligence functionality. Whether you're building data pipelines, managing analytics workloads, or monitoring real-time operations, these updates help you work more efficiently and get more value from your data. _______________________________ Events and Announcements Get Fabric certified for FREE This is your chance to take the DP-600 (Fabric Analytics Engineer) or DP-700 (Fabric Data Engineer) certification exams for free. As part of Data Days, we have over 100 live sessions, more than 5 contests and challenges, and dozens of study groups and learning opportunities. And free Fabric exam vouchers. Available now through August 10, 2026. Request your voucher. Join us for FABCON and SQLCON in Barcelona, September 28 – October 1, 2026 Explore what’s possible with Microsoft Fabric and get up to speed on the latest in SQL, analytics, and AI. From 130 sessions and 4 keynotes to workshops, the expo, community spaces, and the Power BI DataViz World Championships, this is where the data community comes together. Learn directly from Microsoft and community experts shaping the future of Fabric and SQL. Register now and save €200 with code FABCMTY200. Fabric Platform Fabric-CICD tool v1.2.0 – new bulk publish mode (Preview) The June release of the fabric-cicd Python library, v1.2.0 introduces bulk publish mode. It lets fabric-cicd publish multiple items in a single API call using the Fabric bulk import API instead of publishing each item individually through a separate API call. This can make deployments more efficient. Why this matters Because dependencies are managed by the API during publication, bpublishinglish reduces the rigidity of item-type-based staging and better supports cross-item dependencies when logical ID references are used. It can reduce the number of item-specific parameter values you need to configure. For unsupported scenarios, fabric-cicd automatically falls back to the standard publishing flow, so you can try bulk publishing without manually switching deployment paths. To learn more, refer to fabric-cicd bulk option documentation and the v1.2.0 release notes. Change Git branch with at least the contributor role (Preview) Fabric Git integration now let’s any workspace member with at least the Contributor role switch the workspace's connected Git branch. Previously, this action required the workspace Admin role, which forced developers to either be over-permissioned or wait on an admin every time they moved between branches. Why this matters Developers no longer need Admin rights to switch branches. Removes a key blocker in the branch-out to existing workspace flow. Keeps developers as Contributors, aligned with least privilege governance. Fewer hand-offs to admins mean faster time to code. You can find this new capability under the Git integration settings. To learn more about Fabric Git integration new setting, refer to the Allow Contributors and Members to switch branches documentation. We refreshed the Fabric CI/CD documentation this month to make it easier to get started and to follow best practices: New CI/CD intro page — a reworked Introduction to CI/CD in Microsoft Fabric that walks through the platform layer by layer with a new enterprise reference architecture. New best practices guide — Understand the best practices for Fabric CI/CD brings together practical guidance for structuring workspaces, branching, and promoting content safely across environments. Auto-bind for Git integration — new guidance on cross-workspace dependency binding, covering how item dependencies automatically rebind when you branch out or update from Git, and which dependency types are supported. Actionable recommended actions for data owners in the OneLake catalog The Govern tab in the OneLake catalog gives data owners a health view of their data estate, along with recommended actions to improve it, such as increasing sensitivity label coverage, removing items that are no longer in use, handle failed refresh, and more. Until now, these recommendations have told data owners what to improve, but not which items were affected, leaving them to track the relevant entities down manually before they could act. That gap turned a clear recommendation into a manual investigation, and the action often stalled before it started. This release closes that gap. When you open a recommended action, you now see the specific items behind the recommendation, with everything you need to act on them in one place, and a direct path to open item details and resolve the issue at the source. Selecting a recommended action now opens a dedicated view that includes: A breakdown of the affected items — a visual summary of how many of your items are impacted. Why it matters — a short explanation of the governance impact. How to fix it — clear, step-by-step instructions for resolving the recommendation. Newly added A complete list of affected items — displayed in a table with key details, including Name, Last Refreshed, Owner, Location, Endorsement, and Sensitivity, making it easy to review and prioritize actions. Filter and search — narrow the list by keyword or filters to focus on the items you want to handle first. Open item details — jump straight to any affected item to make the change, instead of searching for it across your workspaces. The same enriched experience applies across the recommended actions in OneLake catalog Govern, helping you act on each one without leaving the catalog: Increase Sensitivity label coverage — find and label items that create potential security risks while unlabeled. Remove unused items — review items that weren't accessed or refreshed recently to keep your estate organized and reduce costs. Investigate items that failed to refresh — see which items failed to refresh so your data stays current and reliable. Add descriptions to your endorsed items — surface endorsed items without a description so people can better understand and use them. Apply relevant tags to your items — make items more discoverable by tagging the ones that are missing tags. Why it matters Governance only improves when recommendations turn into action. By bringing the affected items and a direct way to reach them into every recommended action, OneLake catalog Govern removes the guesswork from following through. Data owners can move from understanding a recommendation to resolving it in just a few steps, keeping their data estate secure, organized, discoverable, and trustworthy with far less effort. Learn more about the OneLake catalog Govern tab recommended actions. Data Engineering Microsoft Fabric Runtime 2.0 (Preview) Based on feedback received directly from our customers and partners, we have upgraded Fabric Runtime 2.0 to the latest and compatible stack: Apache Spark 4.1 Delta Lake 4.2 Python 3.13 These upgrades bring access to the newest enhancements, performance improvements, and ecosystem innovations, while also providing a longer support window for enterprise customers to build large-scale analytics and AI workloads on Fabric. With Runtime 2.0, customers can take advantage of: Latest Spark and Delta Lake capabilities. Improved compatibility across the modern data ecosystem. Better developer productivity and runtime performance. Future-ready platform investments aligned with long-term supportability. Learn more about Fabric Runtime 2.0. Fabric Runtime Release Channels (Preview) Fabric Runtime Release Channels provide a structured and transparent way for customers to test upcoming runtime changes before they become the default. This feature helps organizations validate their production workloads early with these new changes in early access, avoid unexpected disruptions, and gain better control over Spark runtime upgrades. Instead of receiving silent updates that might break your production workloads, you can opt in to an early access release channel, test your workloads in a development or staging environment, and confirm compatibility before the update becomes default. How release channels work Each Spark runtime has at least two public release channels: Default channel — This production-grade channel runs the default version of the runtime. All users automatically use this channel unless they opt in to early access. Early access channel — This production-grade channel includes upcoming updates and library changes that are scheduled to become the next default channel. You can opt in to test your workloads against upcoming changes. Once the designated validation window ends, the early access release channel automatically gets promoted to become the new default, and a fresh early access channel is introduced with another set of new changes — continuing the cycle. This model gives you a predictable testing window before changes become default for everyone. Why release channels matter Spark runtime updates can include library upgrades, security patches, dependency changes, or even operating system upgrades. While all updates pass internal quality checks before release, those checks can't capture all customer-specific variations and use cases. Early access channels let you identify potential issues early and work with Microsoft by creating a support ticket to address them before updates affect your production environment. Benefit Description ✔ Predictable updates Customers know exactly when a new runtime becomes available and have time to validate against it. ✔ Reduced risk Testing workloads on early access ensures compatibility before changes reach production. ✔ Better visibility Customers can easily tell which runtime version they're running, reference release notes, and verify upgrade timing. ✔ Improved quality and security You receive well-tested builds with security patches applied faster, giving you confidence in runtime stability. Learn more about Fabric Runtime Release Channels: Fabric Runtime Release Channels. Spark Diagnostic Emitter: Spark 4.1 Runtime Support and New Log Ingestion API The Fabric Apache Spark Diagnostic Emitter is now supported on the Fabric Runtime with Apache Spark 4.1. Customers can collect driver logs, executor logs, Spark event logs, and metrics from workloads running on the latest runtime and route them to Azure Event Hubs, Azure Blob Storage, or Azure Log Analytics — using the same spark.synapse.diagnostic.emitter.* configuration model, so existing emitter setups carry forward as customers upgrade. The emitter also now supports the Azure Monitor Log Ingestion API for sending diagnostics to Log Analytics, available on both Spark 3.5 and Spark 4.1 runtimes. The new AzureLogIngestion emitter type replaces the legacy HTTP Data Collector API path, providing a structured ingestion model with DCR/DCE-based authentication, schema definition, and routing into custom Log Analytics tables. Customers currently on the legacy AzureLogAnalytics type are encouraged to migrate — migration involves creating Data Collection Rule and Data Collection Endpoint resources and updating the Spark properties in the Fabric Environment. To learn more, refer to the Collect logs and metrics with Azure Log Analytics for migration guidance and Spark Diagnostic Emitter documentation. The Fabric Spark Operations Skill — AI-Assisted Spark Diagnostics, Open Source (Preview) The Fabric Spark Operations Skill (spark-operations-cli) is now available in the open-source Skills for Fabric library on GitHub (microsoft/skills-for-fabric). The skill brings AI-assisted, read-only diagnostics to Spark workloads in Fabric — troubleshoot failed notebooks and Spark jobs, stuck Livy sessions, and performance bottlenecks (OOM, shuffle, skew) in plain English from GitHub Copilot CLI, Claude Code, VS Code, Cursor, or other compatible AI tools. It returns severity-ranked findings with root cause analysis and fix recommendations, and includes an automated diagnostic workflow spanning job triage, log mining, Spark Advisor findings, and mitigations. Setup takes minutes: install the skill, run az login, and ask, "Why did my notebook fail last night?" Get started with Skills for Fabric in GitHub. Faster Python UDFs, Scala UDFs, and complex data types in the native execution engine (Generally Available) The native execution engine in Microsoft Fabric, which is generally available, now accelerates Python user-defined functions (UDFs), Scala UDFs, and complex data types such as arrays, maps, and structs. You get faster Spark processing for expressive code without changing your existing notebooks or jobs. Python UDFs have historically carried serialization overhead as data moves between the JVM and Python worker processes. The native execution engine optimizes that data path and keeps vectorized processing intact, so scalar and Pandas (vectorized) UDFs run faster automatically. Scala UDFs and queries that work with nested, complex data types benefit from the same native acceleration. Why this matters Faster UDF execution with no code changes. Vectorized Pandas UDFs see the largest gains. Complex types (arrays, maps, structs) run natively. Existing notebooks and jobs benefit automatically. To use Efficient Scaledown, enable the native execution engine on your Fabric Spark pool or environment. Existing Python and Scala UDFs and queries over complex types are accelerated without any code changes. To learn more, refer to the Python UDFs, Scala UDFs, and complex data types in the native execution engine documentation. Efficient Scaledown with the remote shuffle manager (Preview) Efficient Scaledown decouples Spark shuffle data from executor lifetime in Microsoft Fabric. Instead of pinning shuffle output to local executor disks, Fabric Spark routes large shuffles to Azure Blob Storage and migrates blocks off executors before they're released. Clusters scale down faster, compute costs drop, and jobs become more resilient — with no changes to your queries, notebooks, or pipelines. The feature combines four cooperating capabilities: the Remote Shuffle Manager writes and reads shuffle data to Azure Blob Storage; Shuffle Migration moves blocks off an executor before decommissioning instead of dropping them; a Decision Layer routes small shuffles to local disk and large shuffles to remote storage per stage; and AQE Shuffle Write lets Adaptive Query Execution shape partitioning the first time. Why this matters Clusters scale down faster after demand drops. Lower compute cost from quicker executor release. More resilient jobs with fewer stage retries. No changes to queries, notebooks, or pipelines. To use it, enable the native execution engine and run on Runtime 1.3 (Apache Spark 3.5) or later; autoscale is recommended. Remote Shuffle Manager spark.conf.set("spark.remote.shuffle.enabled", "true") Decision Layer — per-stage routing of local vs. remote shuffle spark.conf.set("spark.sql.rsm.decisionlayer.enabled.level", "stage") AQE participates in shuffle write spark.conf.set("spark.sql.adaptive.shuffleWrite.enabled", "true") Shuffle Migration on executor decommission spark.conf.set("spark.storage.decommission.shuffleBlocks.enabled", "true") spark.conf.set("spark.storage.decommission.shuffleBlocks.cleanup", "true") spark.conf.set("spark.storage.decommission.shuffleBlocks.migrateToFallbackStorage", "true") spark.conf.set("spark.storage.decommission.fallbackStorage.cleanUp", "true") To learn more, refer to the Efficient Scaledown and remote shuffle manager in Microsoft Fabric documentation. Customer-managed key encryption for Spark shuffle data on disk (Generally Available) Microsoft Fabric Spark now generally supports customer-managed keys for Spark jobs through a disk encryption set. Shuffle data written to cluster disks during a Spark job is encrypted with a key you supply and control, giving you ownership of the encryption material that protects intermediate data at rest. With a disk encryption set configured, the cluster disks that hold Spark shuffle data are encrypted using your customer-managed key rather than a platform-managed key. You manage the key lifecycle — including rotation and access — in your own key vault, so encryption of intermediate Spark data follows your organization's key management policies. Why this matters You control the key protecting shuffle data. Intermediate Spark data on disk is encrypted at rest. Key lifecycle and rotation stay in your control. Encryption aligns with your key management policies. To use it, configure a disk encryption set backed by your customer-managed key and associate it with your Fabric Spark configuration. Spark jobs then encrypt shuffle data on cluster disks with your key. To learn more, refer to the Customer-managed key encryption for Fabric Spark documentation. Query your data instantly with the Lakehouse Query Explorer (Generally Available) The Lakehouse Query Explorer is a new, fully integrated query editor built directly into the Lakehouse experience in Microsoft Fabric. You can now write and run Spark SQL queries right where your data lives — no need to switch to a SQL endpoint or spin up a notebook for quick exploration. Whether you’re validating datasets, iterating logic, or exploring patterns, Query Explorer keeps you in flow. orer with the new integrated Query Explorer. Key capabilities Fast, lightweight Spark execution powered by the Lakehouse Livy endpoint. IntelliSense + rich editing experience for faster query authoring. Query across schemas and lakehouses in a single tab. Built-in results grid + inline charts to explore results instantly. Multiple dynamic tabs to analyze different slices of data side-by-side. From quick lookups to multi-table exploration, Query Explorer makes working with Lakehouse data faster and more intuitive—right from the explorer. Learn more and get started with the Lakehouse Query Explorer documentation. Analytics and Insights for Materialized lake views (Generally Available) Analytics and Insights bring continuous refresh intelligence to your lakehouse — two new tabs beside Recent run(s) that shift you from reacting to individual failures to staying ahead of performance drift, rising costs, and silent inefficiencies across your entire materialized lake view estate. The Recent run(s) page tells you what happened in a single execution, including which views succeeded, which failed, and how long the job took. That's valuable when something breaks, but it doesn't answer the questions that matter most for day-to-day operations. Are my durations stable or slowly climbing? Is a new error class appearing and spreading across views? Are my schedules still aligned with how often upstream data actually lands? Am I paying for full refreshes on views that could run incrementally? These are the questions that separate a well-tuned deployment from one that quietly accumulates cost and risk until something finally breaks loudly enough to notice. The Recent run(s) page answers all of them. The Analytics tab transforms your run history into trend lines, distributions, and comparisons you can read at a glance: duration trajectories, success-rate shifts, error-class frequency over time. The Insights tab goes further by watching those same patterns the way a seasoned reliability engineer would, recognizing the signatures behind slow, failing, or wasteful runs, and providing a prioritized list of worthwhile changes. Each recommendation names the affected view, explains why it's flagged, and estimates the payoff in runtime savings, so you can act in seconds rather than investigate for hours. Together, they move refresh management from a reactive, break-fix posture to a proactive, continuously improving one — keeping your materialized lake views fast, healthy, and cost-efficient as your estate grows. To learn more, refer to analytics charts, insight categories in Materialized Lake Views. Introducing Event-Driven Refresh for Materialized Lake Views (Preview) Event-driven refresh brings responsive refresh intelligence to your lakehouse — a new scheduling mode alongside time-based schedules that shifts you from refreshing on the clock to refreshing the moment your data is ready, so your materialized lake views reflect reality instead of an arbitrary calendar. Time-based schedules tell your views when to run: every hour, every morning, every night. That's dependable when upstream data lands like clockwork, but it doesn't answer the questions that matter most for day-to-day operations. Did the ingestion pipeline that feeds this view finish before I refreshed it? Am I recomputing gold-layer views on a fixed cadence while the source data only changes twice a day? Am I paying for refreshes that run before new data has even arrived — or worse, serving stale results because the next scheduled slot is still hours away? These are the questions that separate a refresh strategy tuned to your data from one that quietly burns compute on empty runs and lags the moments that matter. Event-driven refresh answers all of them. You bind a view or a lineage sub-chain to the events that should drive it, and we support two types of events: OneLake events — all file and folder events are supported, so a refresh can fire the moment data lands in OneLake (file or folder creation, update, and more). Job events — Pipeline and Notebook events are supported, so a refresh can fire when the ingestion job that feeds your views completes. The moment an event fires, Fabric resolves the dependency chain and refreshes exactly the views that depend on it. Each trigger names the source event, scopes precisely to the affected lineage, and can react to success or failure, so a stalled upstream job never silently cascades into stale downstream reports. Together with multi-schedule support, event-driven refresh moves refresh management from a fixed-clock, guess-the-cadence posture to a responsive, data-driven one — keeping your materialized lake views fresh the instant new data arrives, and idle when it hasn't, as your estate grows. Learn more and get started with the Schedule a Materialized Lake View Refresh documentation. Data Science AI functions: new models, no package dependency, better usage stats (Generally Available) Fabric AI Functions now use gpt-5-mini as the default model, with “low” reasoning enabled. This powers AI Functions across pandas, PySpark, Data Warehouse, and Dataflows Gen2. For more sophisticated transformations, users may configure gpt-5.1 or tune the reasoning_effort parameter for additional compute and higher-quality results. The gpt-4.1 model has been retired. Pipelines pinned to gpt-4.1 have migrated to gpt-5.1, and those pinned to gpt-4.1-mini migrated to gpt-5-mini. We’ve also simplified PySpark AI Function chaining. The PySpark .ai interface now stays bound to the result schema, so chains like summarize → classify no longer require intermediate DataFrames. In addition, PySpark now supports df.ai.stats for detailed token usage after any AI function call, including reasoning token breakdowns. For pandas, AI Functions no longer require the openai-python package. Capacity-limited rows are surfaced as CapacityExceededResult, enabling clean retries via aifunc.split_results. To learn more, refer to the AI Functions documentation. Data Warehouse Lakehouse table health check (Generally Available) Lakehouse Table Health Check gives you a simple, T-SQL–based way to validate whether your Lakehouse tables are optimized for the SQL analytics endpoint. A single stored procedure surfaces common layout issues, such as small files and fragmentation, offering the insights you need to determine if your tables need to be optimized. You can integrate health checks into pipelines and operational workflows, enabling proactive, at-scale optimization instead of reactive troubleshooting. -- Run a health check on a Lakehouse table from the SQL analytics endpoint EXEC sp_get_table_health_metrics 'dbo.FactSales'; aluate table health. To learn more about sp_get_table_health_metrics and how to integrate it into your Pipelines to optimize your table only if anomalies are detected, refer to sys.sp_get_table_health_metrics (Transact-SQL). Scalar User‑Defined Functions - Procedural computation for analytical SQL (Preview) Scalar User-Defined Functions now support procedural computation — including loops, multiple return paths, and rich IF/THEN/ELSE branching — running natively within the warehouse engine. Computation-based Scalar UDFs are designed for analytical query shapes, integrating naturally with CTEs, GROUP BY, HAVING, and ORDER BY, and executing efficiently at data warehouse scale. Defining business rules once, in SQL, and reuse them across queries, reports, and pipelines. To learn more, refer to the Create Function documentation. Usage-based resource estimations (Generally Available) The Query Optimizer uses learned resource estimation to correct underestimation in T-SQL query plans. It saves actual cardinalities from past executions and automatically adjusts row count estimates in subsequent runs. With this release, the optimizer will also begin correcting overestimations — closing the loop in accurate cardinalities, leading to more efficient resource requests and improved concurrency. Real-Time Intelligence Improved tile error experience in Real-Time Dashboard (Generally Available) We improved the way tile errors appear in Real-Time Dashboards to make them clearer, calmer, and easier to act on. Instead of showing a disruptive red error state, tiles now use a neutral grey error state with a short category header, such as Syntax error, Semantic error, Data source issue, Network error, or Something went wrong. Users can select Details directly from the tile to open a popover with the full engine error message, shown exactly as received. This keeps the dashboard readable while still making the technical details easy to access, copy, and share when needed. This update helps users understand what went wrong faster, while ensuring that one failed tile does not block or visually overwhelm the rest of the dashboard. To learn more, refer to the Troubleshoot Real-Time Dashboard Tile Errors documentation. Folders in Eventhouse tree (Generally Available) Folder support in the Eventhouse tree is now available through the UI. Previously, folders could only be created and managed via code. With this update, you can now organize your Eventhouse directly from the tree, making it easier to manage assets at scale. You can group tables, shortcuts, materialized views, functions, and data streams into a structured hierarchy, improving navigation and reducing clutter. Key capabilities Create, rename, and delete folders from the UI. Organize assets into folders. Move items via the context menu (⋯ → Move to). Create folders inline while moving items. This allows for a simplified and more intuitive way of managing growing Eventhouses. To learn more, refer to the Manage and monitor a KQL database table documentation. Eventstream connector private network support (Generally Available) Data is a critical asset for organizations, and access to real-time data is increasingly essential. However, many high-value data sources reside in private network environments — cloud virtual networks or on-premises infrastructure — particularly in highly regulated industries such as banking, finance, and telecommunications, where strict security and compliance requirements are mandatory. Eventstream's private network support establishes a secure, managed bridge using your Azure virtual network and VNet injection, allowing Eventstream streaming connectors to run inside your virtual network and reach private sources without opening them to the public internet. Whether your data sources reside in on-premises networks, private networks on third-party cloud services, or private networks on Azure, you can connect the bridge Azure virtual network to your source's private network using suitable connectivity options — such as VPN or ExpressRoute for on-premises environments, and private endpoints or network peering for Azure-based sources — enabling Eventstream connectors to securely ingest real-time data from these protected environments into Fabric. The solution leverages a new concept — Streaming virtual network data gateways — which abstracts the bridge Azure virtual network and subnet resource within Fabric. By creating a connector with a streaming virtual network data gateway associating it with your connection, the Eventstream connector is provisioned within your virtual network, ensuring secure communication with your private data sources. Once real-time data from your private network source is securely brought into Fabric Eventstream, you can fully leverage the comprehensive analytics tools in Fabric Real-Time Intelligence to power your real-time scenarios with enterprise-grade security. To learn more about configuration and advanced scenarios, refer to the Eventstream private network streaming guide. Azure Event Hubs source in Eventstream now supports workspace identity authentication (Preview) Currently, when configuring an Azure Event Hubs source in Eventstream, the only supported authentication method is Shared Access Key — a connection string containing static credentials. While simple to set up, shared access keys present several security risks in production environments: they have unlimited lifetime unless manually rotated, provide no per-user or per-application identity, and if accidentally leaked through source code, configuration files, or third-party sharing, grant full access to anyone who obtains them. Revoking a compromised key requires regeneration, which disrupts all services depending on it — with no straightforward way to audit which clients used the key. To address these challenges, we're introducing Workspace Identity as a new authentication option for the Azure Event Hubs source connector (Extended features) in Eventstream (Preview). A Fabric workspace identity is an automatically managed service principal associated with your workspace. Fabric manages the credentials entirely — there are no secrets to store, rotate, or risk leaking. It integrates with Microsoft Entra ID, providing identity-based access with full audit trails, fine-grained role-based access control, and automatic credential lifecycle management. To use workspace identity authentication with your Azure Event Hubs source in Eventstream: Navigate to your workspace settings and create a workspace identity on the Workspace identity tab. In your Azure Event Hub namespace, assign the appropriate role (e.g., Azure Event Hubs Data Receiver) to the workspace identity's service principal. When adding an Azure Event Hubs source in Eventstream, select Workspace Identity as the authentication method — no connection string or key is needed. Eventstream will automatically obtain tokens using the workspace identity to securely connect to your Event Hub, eliminating credential management overhead while strengthening your security posture. To learn more about the configuration, refer to the Azure Event Hubs source extended connector configuration documentation. Custom CA and mTLS support in Eventstream streaming connectors (Generally Available) Fabric Eventstream under Real-Time Intelligence provides various streaming connectors, enabling the integration of real-time data from popular sources into Fabric. When the Eventstream connector client establishes a connection with sources, it is required to implement TLS or mTLS encryption to fulfil the necessary security standards. Many organizations use certificates issued by private or internal Certificate Authorities or require mutual TLS (mTLS) authentication where both the client and server verify each other's identity before transmitting data. Without custom CA and mTLS support, Eventstream connectors cannot connect to these secured source systems. The Custom CA and mTLS support feature, is now generally available for MQTT, Apache Kafka, AWS MSK, and Confluent Cloud for Apache Kafka source connectors. Customers can specify their custom CA and client certificates managed in their own Azure Key Vault when configuring their source in Eventstream. Once specified, Eventstream connector will fetch the certificates from the customer's Azure Key Vault and use them to establish a mutually authenticated, encrypted connection — enabling secure, compliant real-time data ingestion across all supported streaming sources. To learn more about the configuration, refer to the Eventstream sources overview page and choose the corresponding source. Introducing the Oracle CDC connector for Eventstream (Preview) Eventstream now introduces the Oracle Database Change Data Capture (CDC) connector, enabling you to stream database change events directly from any Oracle Database — whether running in the cloud or on-premises — into Eventstream for real-time processing and analytics. Many organizations run important operational workloads on Oracle Database and need to react to changes as they happen. With the Oracle CDC connector, you can continuously capture change events from Oracle Database and bring them into Fabric without building custom polling applications or managing separate integration services. With the Oracle CDC connector, you can: Capture and stream databases changes from Oracle Database into Fabric in real time. Connect to Oracle databases running either on-premises or in the cloud. Process incoming change events using Eventstream transformations. Route processed change events to supported destinations such as Eventhouse, Lakehouse, Activator, or custom endpoints. This capability helps you build real-time analytics and event-driven applications from Oracle data. For example, you can route transaction changes to an Eventhouse Kusto table for operational analysis, send selected events to Activator for alerting, or combine Oracle change events with other streaming sources in the same eventstream. To learn more about Eventstream Oracle CDC connector, refer to Add Oracle Database CDC source to an eventstream (preview). Eventhouse update policies now support referencing accelerated shortcuts in update policies (Generally Available) Eventhouse update policies now support accelerated shortcuts in update policy queries, enabling ingestion-time enrichment scenarios. Use this for dimension lookups, such as enriching ingested fact events with customer, device, or product attributes stored in OneLake shortcut data. The shortcut-backed external table must have Query Acceleration Policy enabled, and Hot must cover all data. For update policy scenarios, set: .alter external table DimCustomer policy query_acceleration '{"IsEnabled":true,"Hot":"36500.00:00:00"}' Then join to it from the update policy query: .alter table EnrichedEvents policy update '[{ "IsEnabled":true, "Source":"RawEvents", "Query":"RawEvents | lookup kind=leftouter (external_table(''DimCustomer'')) on CustomerId","IsTransactional":true, "PropagateIngestionProperties":false }]' Processing uses the authorization context captured in the system-populated OwnerPrincipalDetails property: the user who creates or alters the update policy must have access to the shortcut data. This enables ingestion-time enrichment with governed shortcut data without separate orchestration. Shortcut Tables in Eventhouse Now Automatically Synchronize Schema Changes To help maintain consistency between source data and shortcut tables, the default schema synchronization behavior for Eventhouse shortcut tables is changing. Previously, schema changes made to the source table were not automatically propagated to the shortcut table unless schema synchronization was explicitly enabled. As a result, source and shortcut schemas could diverge over time. With this update, all new and existing shortcut tables in Eventhouse automatically synchronize schema changes from their source table by default, including: Adding new columns Changing column data types Renaming columns Deleting columns Automatic schema synchronization helps ensure that shortcut tables remain aligned with the source schema, preserving the latest business context and reducing manual maintenance. Customers who prefer to disable automatic schema synchronization can continue to control this behavior using the existing KQL management command: .create-or-alter external table ExternalTable kind=delta ( h@'https://storageaccount.blob.core.windows.net/container1;secretKey' ) with (AutoUpdateSchema=false) Note: Because schema changes are now automatically propagated, queries, dashboards, and downstream workloads may require updates if they reference columns that are renamed, removed, or otherwise modified in the source table. Investigator Insights in Operations Agent (Preview) When an anomaly is detected, understanding what caused it is often the hardest part. Investigator insights are designed to make that easier by analyzing the surrounding data and surfacing relevant context. When the operations agent detects that a rule has been met, there is an option to run an investigation in the background to identify correlated signals and patterns. Instead of manually digging through telemetry, you get a guided view into what changed, what stood out, and what may have contributed to the issue. This helps you move more quickly from detection to understanding. You can access these insights directly from Teams. Open the agent’s message and select Investigate further to generate a detailed analysis. The investigation provides a structured view of what happened: Investigation scope shows which tables were analyzed, whether from a single source or across related datasets. Key observations highlight the most important findings, including actual values, deviations from baseline, and notable trends or outliers. Pattern analysis surfaces meaningful changes around the time of the anomaly, such as dimensions with significant shifts, and clearly call out when no strong patterns are identified. Together, these insights help you quickly understand not just that something went wrong, but why it happened. To learn more, refer to the Operations Agent Actions documentation. Anomaly Detector Configurations Pane As you build on top of your data, it is often just as important to understand what already exists as it is to create something new. This update makes it easier to discover and build existing anomaly detection configurations. You can now view all anomaly detection configurations that have already been created for a given data source in one place. This lightweight experience gives you quick visibility into how anomaly detection is currently set up, helping you avoid duplicate work and better understand how others are using the data. From this view, you can explore existing configurations or create a new one if your use case is not yet covered. This makes it simple to extend existing setups or start fresh when needed, all without leaving the context of your data source. By making configurations easier to discover and reuse, this experience helps streamline workflows and ensures you can move quickly from exploration to action. To learn more, refer to the Anomaly Detection in Real-Time Intelligence documentation. Ingestion time stamp in Anomaly Detector (Preview) Working with anomaly detection often assumes your data already includes a clean, reliable timestamp. With this update, you can now use the system-generated ingestion time as the timestamp for anomaly detection. This means that even if your dataset does not include a dedicated timestamp column, you can still run analysis without needing to modify or preprocess your data. This is especially helpful for scenarios where events are ingested in real time or where timestamps are missing, inconsistent, or not trustworthy. Instead of blocking data preparation, you can rely on ingestion time to move forward with detection and start identifying meaningful patterns right away. By reducing setup requirements and removing a common dependency on source data quality, this capability makes it easier to apply anomaly detection across a wider range of use cases. To learn more, refer to the Anomaly Detection in Real-Time Intelligence documentation. Configuring Anomaly Detection without a Group by Column (Preview) With this update, Anomaly Detection now supports scenarios where you choose not to use a group by column. This provides an additional configuration option for datasets that already represent a single stream of data, allowing you to apply anomaly detection directly to the metric without first identifying a grouping dimension. This added flexibility helps the configuration experience better align with how your data is structured. Whether you are monitoring a single device, tracking a specific service, or analyzing a focused dataset, you can now create anomaly detectors without requiring a group-by column. At the same time, grouping remains available for scenarios where you want to monitor and compare multiple entities within the same dataset. To learn more, refer to the Anomaly Detection in Real-Time Intelligence documentation. Introducing Fabric Maps Tilesets: High-Performance Visualization for Large Geospatial Datasets (Generally Available) Have location-based data sitting in OneLake but no simple way to see it come alive on a map? With Fabric Maps Tilesets, you can now turn that data into fast, interactive map experiences directly inside Microsoft Fabric. The Tileset Builder lets you create map-ready PMTiles from OneLake data without custom code, manual exports, or separate geospatial infrastructure making it easier for teams to explore large geospatial datasets, uncover patterns, and bring location intelligence into the analytics workflows they already use. Organizations can rely on Microsoft Fabric to manage operational data, analytics workflows, and business reporting. When that data includes locations, routes, assets, boundaries, or events with a location context, teams need a simple way to visualize it on a map. Traditionally, this required separate geospatial pipelines, custom polling services, or manual exports. Leveraging a Fabric Map removes complexity by allowing organizations to create and refresh map-ready tilesets from data already stored in OneLake. Try creating your own Tileset using the following steps: Connect to a lakehouse and select source files Configure tileset metadata Configure layer settings Tileset schedule (Preview) Review and create tileset What is a Tileset? Tilesets are map-optimized representations of geospatial data. Instead of trying to load a large geospatial data file all at once, data is divided into small tiles that are loaded and rendered as needed while users zoom and pan across the map. This makes tilesets especially useful for large datasets, such as infrastructure networks, delivery routes, asset locations, service areas, or operational events. Fabric Maps Tileset Builder Capabilities Build map-ready tilesets directly from OneLake data. Visualize large geospatial datasets with high performance. Enable smooth, interactive map experiences at scale. Keep map content synchronized with source data. Eliminate manual exports and external geospatial processing workflows. Integrate native geospatial visualization into existing Fabric data workflows. Common scenarios Tilesets help teams turn large location-based datasets into fast, interactive map experiences. Utility and energy companies can visualize nationwide power line grid systems as a single dataset to monitor field assets and service coverage. Supply chain and logistics teams can explore daily routes, regional boundaries, and operational areas. Retailers can analyze store territories, expansion opportunities, and new developments. Because the data stays connected to Fabric, these map experiences become part of the broader analytics workflow — not a separate geospatial process. To get started, refer to How to create tilesets. Cross-domain intelligence with Azure Monitor data in Microsoft Fabric (Preview) Have you ever detected an issue in your systems but struggled to understand what it meant for the business? As systems grow more complex, this gap becomes harder to bridge. Incidents no longer affect just systems; they affect customers, revenue, and operations in real time. Azure Monitor Logs mirroring into Microsoft Fabric helps close that gap. In just a few steps, telemetry from Log Analytics workspaces becomes available in OneLake alongside business and operational data — without duplication and with near real-time availability. This creates the foundation for Cross-domain insights and actions: Bring observability, operational, and business data together in Eventhouse for real-time analysis. The same unified data can be used by Real-Time Dashboards for investigation and by operations agents to recommend and drive actions informed by both business and observability context. For example, an operations team can identify that a check-in kiosk outage is impacting high-value customers and act before customer impact grows. Advanced Fabric analytics Apply tools like Spark and Power BI for long-term analysis, machine learning, and a wide range of analytical scenarios. For example, an operations team can create a Power BI report showing trends in customer impact and cost, helping management make informed decisions on resource allocation and understand the true cost of application failures. Together, these capabilities help organizations move from isolated technical signals to business-aware insights, decisions, and actions. To learn more, refer to Cross-domain intelligence with Azure Monitor data in Microsoft Fabric (Preview). Until next month That's a wrap for the July 2026 Microsoft Fabric Monthly Update. As always, we'll continue sharing new capabilities, enhancements, and improvements across Microsoft Fabric in future monthly updates. Thank you for being part of the Fabric community!
New OneLake security improvements for Microsoft Fabric
Security should be consistent, intuitive, and close to the data. With OneLake security in Microsoft Fabric, organizations can define access controls once at the data layer and apply them across supported Fabric experiences. In this blog post, we’ll walk through the latest summer updates to improve your data security so you can fully relax at the pool, knowing your data is kept safe. Eventhouse (Preview) and Graph Database integration (Generally Available) OneLake security now applies consistent security to even more engines with the inclusion of Eventhouse and Graph Database! Use a single copy of data with any Fabric engine, giving you the freedom to choose the right engine for your query needs. Easily query streaming and real-time data using Eventhouse. Or explore your data as nodes and edges with the power of Fabric Graph. Either way, OneLake security follows your data to every query engine in Fabric. A simplified column-level security experience The new column-level security (CLS) experience makes it easier for data owners to grant access to only the columns users need. The updated experience removes the need to manage separate CLS rules and instead displays permissions directly alongside each column. Columns can be searched, filtered, and edited in bulk to quickly manage access. Faster performance in the OneLake catalog secure tab We have improved the performance of the Secure tab in the OneLake catalog, making it faster to review roles, update permissions, and validate access configurations. These improvements are especially valuable in environments with large numbers of secured items and roles. What’s new OneLake security APIs Granular APIs for OneLake security have reached their next milestone, making all five OneLake security APIs generally available. Use the bulk update APIs to manage huge role changes at once, or leverage the granular APIs to create a single new role with ease. Get started with the OneLake security APIs. OneLake security rollout With OneLake security’s rollout complete, reaching general availability. Now, the opt-in experience available in preview has been removed. All existing and new OneLake items are enabled with OneLake security. Get started These enhancements are part of our ongoing investment in making OneLake the best place to build secure, governed analytics experiences. We’ve got many exciting things planned, so be sure to keep tabs on what’s happening on our roadmap. We look forward to your feedback as you adopt these improvements and continue building secure, scalable analytics solutions with OneLake and Microsoft Fabric. Learn more Get started with OneLake security OneLake security data access modelFabric Data Warehouse best practices for medallion architectures
Part three of a series on medallion architecture with Fabric Data Warehouse. Good medallion architecture is mostly operational discipline. In part one of this series, we chose the pattern, and in part two, we filled in the Bronze, Silver, and Gold layers. Now comes the part that usually determines whether the architecture holds up in production: the operating rules. Many medallion architectures look great on paper but become difficult to maintain as data volumes, business requirements, and consumers grow. A medallion pipeline is easy to explain and easy to demo. It is more challenging to keep clean over time. The challenges usually start small: row-by-row loads, report-specific logic in the wrong place, transformations that cannot be safely rerun, or Gold tables that slowly become another staging layer. Why this matters Most medallion problems are not caused by the names Bronze, Silver, and Gold. They happen because the pipeline stops behaving like a pipeline. Bronze starts cleaning. Silver starts serving dashboards. Gold starts compensating for upstream data quality. Before long, nobody knows where a rule belongs, and every change feels risky. The goal of best practices is not to add ceremony. The goal is to make the pipeline predictable: predictable loads, repeatable transformations, trusted outputs, and clear places to look when something breaks. Best practice 1: Batch the writes Fabric DW is built for set-based work. Treat ingestion and transformations as batches, not as a stream of tiny row-by-row operations. In Bronze, that usually means using COPY INTO, Fabric Pipelines, or other bulk-loading patterns to land data in raw tables. If you are loading from files, aim for fewer well-sized files instead of many tiny ones. When practical, files in the 100 MB to 1 GB range are a healthier starting point than a long tail of small files. In Silver and Gold, the same idea applies: prefer set-based T-SQL transformations, CTAS, INSERT...SELECT, and MERGE patterns over procedural row-at-a-time logic. Do this well Load Bronze in batches, and avoid trickle inserts when the source can be staged first. Add ingestion metadata, such as source file name and load timestamp, so every batch is traceable. Keep operational logging lightweight. If you need very high-write audit events, do not turn the warehouse into a single-row logging engine. Let Bronze preserve the batch; let Silver decide what is valid. Rule of thumb: if a load pattern creates a large number of tiny writes, fix the load pattern before tuning the query. Best practice 2: Make Silver rerunnable Silver is where the pipeline earns trust. That means Silver transformations need to be repeatable, testable, and safe to rerun. If an upstream source reloads, or a cleansing rule changes, you should know how to rebuild the affected Silver tables without guessing which reports need to be patched. This is where idempotent design matters: a transformation should produce the same result when run again against the same inputs. In Fabric DW, use CTAS when you want to materialize a clean table from a query, INSERT...SELECT for controlled incremental loads, and MERGE when late-arriving or changed data needs to update existing Silver rows. Do this well Design transformations so they can run again without duplicating or corrupting data. Use staging tables when the logic is complex. A few clear steps are easier to operate than one unreadable query. Put quality gates in Silver: required fields, valid formats, duplicate handling, and reason codes for rejected records. Choose precise data types and lengths. Silver is the right place to turn loose source data into reliable analytical data. Rule of thumb: if a report needs to clean the data again, Silver did not finish its job. Best practice 3: Shape Gold for consumption Gold is not just “the final table.” Gold is the business-facing serving layer. It should be modeled around how people ask questions, not around how the source systems store data. For some workloads, that means a star schema with fact and dimension tables. For others, it means a data mart, a wide reporting table, or a pre-aggregated summary. The pattern matters less than the principle: Gold should make the common analytical path simple, fast, and trustworthy. This is also where you should be careful not to let Gold become a junk drawer. If Gold is full of one-off fixes, report-specific exceptions, and raw technical fields, the layer is doing too much. Do this well Model the grain explicitly. A fact table without a clear grain becomes hard to explain and harder to debug. Pre-aggregate where the business repeatedly asks the same question. Hide technical fields that helped the pipeline but do not help the consumer. Keep Gold dependent on Silver by default. Direct Gold-to-Bronze dependencies should be rare and deliberate. Rule of thumb: Gold should answer the business question quickly without making the report author rediscover the pipeline. Best practice 4: Use Fabric DW defaults, but do not fight the engine Fabric DW gives you a SQL warehouse over Delta data in OneLake. That means you get transactional behavior, optimized storage patterns, and a managed engine that handles many physical decisions for you. The practical advice: do not bring every habit from traditional data warehousing with you. You do not need to micromanage distribution or indexing the same way you would in older platforms. Focus first on healthy data layout, set-based transformations, good table design, and predictable query patterns. At the same time, do not ignore the basics. Query performance still benefits from clean data types, useful statistics, well-shaped Gold tables, and avoiding unnecessary scans. Do this well Keep V-Order and platform optimizations on unless you have a measured reason to change them. Use the performance guidance for Fabric Data Warehouse before inventing custom tuning patterns. Check query behavior when a Gold table becomes critical to many reports. Treat advanced exceptions as exceptions. Most teams should start with the defaults and tune only when evidence says to tune. Rule of thumb: tune from evidence, not from habit. Best practice 5: Monitor by layer A medallion pipeline should be observable at each layer. If a dashboard is wrong or slow, you should be able to tell whether the issue started in Bronze ingestion, Silver transformation, or Gold serving. In Fabric DW, use Query Insights and the warehouse monitoring views to understand query behavior, expensive operations, and refresh patterns. Pair that with pipeline-level monitoring so you can see not only whether a job failed, but where the failure happened. Measure the pipeline in terms the team can act on: Bronze load duration, Silver transformation duration, rejected-record counts, Gold refresh duration, and Gold query performance. Do this well Track load and refresh duration by layer. Log the number of records received, accepted, rejected, and published. Watch critical Gold queries after refresh, especially the ones that feed executive dashboards or widely used semantic models. Keep operational alerts tied to business impact. A failed Gold refresh matters differently from a delayed Bronze load. Rule of thumb: if you cannot tell which layer failed, your monitoring is not layer-aware enough. Before moving a medallion pipeline into production, use the following checklist to verify that each layer is operating as intended. The best-practice checklist Area Bronze Silver Gold Write pattern Batch ingest with metadata Set-based transformations Scheduled refreshes Quality rule Preserve what arrived Validate, conform, and flag Expose trusted fields only Performance focus Avoid tiny writes Keep logic rerunnable Shape for common queries Takeaway Part two of this series was about one job per layer. Part three is about operating each job like it matters. Batch the writes. Make Silver rerunnable. Shape Gold for consumption. Use Fabric DW’s managed engine instead of fighting it. Monitor the pipeline by layer so failures are easy to locate and fixes happen in the right place. If you follow those rules, your medallion architecture becomes less fragile over time, not more. This post is part of our Medallion Architecture on Fabric Data Warehouse series: Choosing your medallion pattern in Fabric Data Warehouse Building the Bronze → Silver → Gold layers Fabric DW best practices for medallion architectures Securing and governing your layers Performance tuning your medallion pipeline Ready to go deeper? Explore the Microsoft Fabric Data Warehouse performance guidelines and ingestion guidance, then stay tuned for Part four of this series, where we’ll cover securing and governing your layers.Workspace Outbound Access Protection (OAP) for Operations Agent and Fabric Maps (Preview)
Co-authors: Andre Terceros and Bodhisatva Gautam Workspace Outbound Access Protection (OAP) in Microsoft Fabric helps WS admins secure outbound connections from workspace items to external resources. Administrators can control outbound access by blocking unwanted connections by default and allowing only approved connections through configured rules. As organizations adopt AI-powered operations at scale, governance and security remain at critical requirements. With this preview release, Microsoft Fabric introduces Outbound Access Protection (OAP) for Operations Agent and Fabric Maps, enabling workspace administrators to control the outbound actions an agent can perform. OAP for Operations Agent When OAP is enabled, Operations Agent continues to perform core functions including reasoning, recommendation generation, rule evaluation, and telemetry collection. However, outbound actions are governed by the workspace's configured access policies. Administrators gain greater visibility through in-product notifications, Teams messaging experiences, and the Operations Agent Activity Log, making it easier to identify and troubleshoot blocked actions. Figure: Outbound Access Protection helps workspace administrators govern outbound Operations Agent actions while providing clear visibility when actions are blocked. What's new with Operations Agent and OAP? With Outbound Access Protection support for Operations Agent, workspace administrators gain more control over how agent-initiated actions interact with external services and resources. The following updates improve governance, visibility, and operational oversight while helping organizations continue to automate with confidence. Govern outbound agent actions through workspace-level OAP policies. Control whether Operations Agent can send Teams notifications based on allowed connections. Prevent unauthorized cross-workspace actions when OAP policies restrict outbound access. Receive clear visibility when actions are blocked through in-product notifications and Teams messaging experiences. Monitor agent activity and OAP-related outcomes through the Operations Agent Activity Log. Figure: Activity Log Operations Details show the steps the agent completed and each action’s status, including when an action is blocked. OAP for Maps Fabric Maps can connect to a variety of data sources, including Lakehouse across Fabric workspaces, Kusto databases (KQL), Ontologies as well as external geospatial services such as Web Map Services (WMS), Web Map Tile Services (WMTS), and Web Feature Services (WFS). Workspace Outbound Access Protection helps organizations maintain security and compliance by governing outbound connections and requiring explicit approval before a map can access external resources. With OAP enabled, Fabric Maps follows a "default deny" model, ensuring only approved destinations can be accessed. How it Works When Workspace Outbound Access Protection is enabled on a workspace, Fabric Maps evaluates outbound connectivity at multiple stages: Save and Load Operations Whenever a map is created, updated, or loaded, Fabric evaluates all referenced data sources against the workspace policy. If a data source isn't permitted: References are blocked Disallowed sources are redacted when the map is opened Attempts to save unsupported references are rejected Runtime Data Access Map visuals continuously retrieve data such as: Map tiles Geospatial features Query results Before each outbound request is executed, Fabric validates the destination against the workspace's outbound access protection policy. External Service Validation External geospatial services such as WMS, WMTS, and WFS are validated through Data Movement and Transformation Services (DMTS). DMTS acts as a policy enforcement layer and ensures only explicitly approved external endpoints can be reached. Supported Connection Scenarios Lakehouse Lakehouse connectivity receives the most flexibility under the current release. Lakehouse within the same workspace are always allowed. Lakehouse in other workspaces can be allowed using Data Connection Rules. Administrators maintain granular control over cross-workspace access. External Geospatial Services Organizations can securely connect to approved WMS, WMTS, and WFS services. By using Data Connection Rules with the Geospatial Web Services connection type, administrators can create an allow list of approved endpoints. This enables scenarios such as: Accessing enterprise GIS systems Consuming approved mapping services Integrating with external geospatial data providers Kusto Databases and Ontologies Connections to Kusto databases and Ontologies within the same workspace continue to function normally. Cross-workspace connectivity for these sources is currently blocked when OAP is enabled. Future releases will introduce additional policy controls for these connection types. Configuring Fabric Maps with Workspace OAP Enabling protection is straightforward: Enable Workspace Outbound Access Protection for the workspace. Create Data Connection Rules that define approved destinations. Add approved external geospatial services using the Fabric connection experience. Configure Geospatial Web Services rules to authorize required endpoints. Once configured, Fabric Maps can access only the approved destinations specified by policy. Security by Design Workspace OAP for Fabric Maps follows several key security principles: Explicit Allow Lists: Only approved destinations can be reached. All other outbound connectivity is automatically blocked. Consistent Enforcement: Policies are applied during authoring, loading, and runtime execution, ensuring continuous protection throughout the lifecycle of a map. Fail-Closed Protection: If policy validation services become unavailable, Fabric denies cross-workspace connections by default. This fail-closed behavior helps prevent unintended data exposure during service disruptions. What’s next? We are actively working to expand OAP support for additional experiences and plan to add support for Power BI Semantic Models and Reports soon in GA soon. Your feedback is essential! Let us know how we can make Fabric even more secure and flexible for your workloads by sharing your feedback at Fabric Ideas – Microsoft Fabric Community Learn more Workspace outbound access protection overview Outbound Access Protection for Operations Agent (Preview) Workspace Outbound Access Protection for Fabric Maps
