Retiring the Fabric data agent custom tool in Microsoft Foundry: move to Fabric IQ
In March 2025, we announced that agents in Microsoft Foundry could use Fabric data agents to answer questions about data in Microsoft Fabric. In the earlier integration, you connected to a data agent by adding it as a custom tool. For details, refer to Consume a data agent in Microsoft Foundry. What’s changing We are deprecating the earlier custom-connection integration. Starting 11/6/2026, that integration will no longer be supported. If your Foundry agents use a Fabric data agent as a custom tool, you must migrate them before that date. The replacement integration (Preview) uses the Fabric IQ (OneLake Catalog) tool, which makes your data available to agents and applications. In the Foundry portal, you can use this tool to add a published Fabric data agent to a Foundry agent. For configuration steps, refer to Consume Fabric data agent from Microsoft Foundry via Fabric IQ. Capabilities with the new integration The replacement integration changes how you find and connect Fabric data agents: Select accessible published data agents from the catalog. In the Foundry portal, the OneLake Catalog shows the published data agents available to you by name, so the connection workflow does not require you to enter a workspace ID or an artifact ID. Connect more than one data agent. A Foundry agent can call multiple data agents, such as separate agents for sales data and customer support data. The earlier custom-connection integration only supported one Fabric data agent. Connect through a Model Context Protocol (MCP) endpoint. MCP is an open standard for how an agent calls a tool. Each selected Fabric data agent is presented to the Foundry agent as a tool through a MCP endpoint. Coming soon, when a data agent answers a question, its response will also include the query it used to generate the answer. What you need to do If any of your Foundry agents use a Fabric data agent as a custom tool, complete the following steps before 11/6/2026: In Microsoft Fabric, make sure to publish your Fabric data agent with a rich and detailed description. Open the agent in the Microsoft Foundry portal. In the Tools section, add the Fabric IQ (OneLake Catalog) tool, and then select your data agent from the catalog. Update the Foundry agent's instructions. Name each data agent and describe the types of questions it should handle. Remove the earlier custom tool and then save the Foundry agent. Test the Foundry agent with representative questions for each connected data agent. If you connect data agents in code, update your implementation to use the Fabric IQ tool. For samples in Python, C#, and JavaScript, refer to Connect agents to Microsoft Fabric with Fabric IQ. Guides to migrate from Fabric Data Agent to Fabric IQ tool Option 1: Migrate in Foundry Portal Navigate to Foundry Portal and open the Tools Catalog, select “Fabric IQ (OneLake Catalog)”. . In the OneLake catalog, filter by “Data agent” type. Select any data agent you want to use, and you are ready to go. Provide instructions to your Foundry agent about how to use Fabric data agent. . Option 2: Migrate in SDK/Rest API After you publish the Fabric data agent, open its Settings and go to the Model Context Protocol tab. This tab shows: Data agent MCP server name MCP server URL (copy this value; you can use in every client) Data agent MCP tool name MCP server tool description Once you get the data agent MCP server URL, proceed with the following steps: Step 1: Get an access token az account get-access-token --resource https://management.azure.com --query accessToken -o tsv Step 2: Create a Foundry connection to the Fabric data agent A connection stores the Fabric data agent endpoint and how to sign in to it. Your agent uses this connection to reach Fabric. Replace each value in angle brackets, then run the request: curl --request PUT \ --url 'https://management.azure.com/subscriptions/<azure-subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.CognitiveServices/accounts/<foundry-account-name>/projects/<foundry-project-name>/connections/<connection-name>?api-version=2025-04-01-preview' \ --header 'Authorization: Bearer <access-token-from-step-1>' \ --header 'Content-Type: application/json' \ --data '{ "type": "Microsoft.MachineLearningServices/workspaces/connections", "properties": { "authType": "UserEntraToken", "group": "AzureAI", "category": "RemoteTool", "target": "<fabric-data-agent-mcp-endpoint>", "audience": "https://api.fabric.microsoft.com/.default", "isSharedToAll": true, "sharedUserList": [], "UseCustomConnector": false, "Credentials": { "ClientId": "fake" }, "metadata": { "ApiType": "Azure" } } }' Main field capabilities: Field Value What it means authType UserEntraToken The agent calls Fabric as the signed in user, with that user's Microsoft Entra token. category RemoteTool The connection points to a remote tool, in this case an MCP endpoint. target Your MCP endpoint The address of your Fabric data agent. audience https://api.fabric.microsoft.com/.default The token is issued for the Fabric API. isSharedToAll true Every user in the Foundry project can use the connection. Credentials.ClientId fake Keep this value as shown. The response includes an id field. This is the full resource ID of the connection. Save it for step 4. It looks like this: /subscriptions/<azure-subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.CognitiveServices/accounts/<foundry-account-name>/projects/<foundry-project-name>/connections/<connection-name> Step 3: Install the Python packages pip install "azure-ai-projects>=2.2.0" azure-identity Step 4: Set the environment variables Variable Where to find it FOUNDRY_PROJECT_ENDPOINT The Overview page of your Foundry project. FOUNDRY_MODEL_NAME The deployment name of your model in your Foundry project. FABRIC_IQ_PROJECT_CONNECTION_ID The full connection resource ID from step 2. Use the full ID, not only the connection name. export FOUNDRY_PROJECT_ENDPOINT="<your-project-endpoint>" export FOUNDRY_MODEL_NAME="<your-model-deployment-name>" export FABRIC_IQ_PROJECT_CONNECTION_ID="<your-connection-resource-id>" Step 5: Create an agent that uses the Fabric IQ tool and ask it a question This script creates a prompt agent with the Fabric IQ tool, sends it one question, prints the answer, and then deletes the agent. import os from azure.identity import DefaultAzureCredential from azure.ai.projects import AIProjectClient from azure.ai.projects.models import PromptAgentDefinition, FabricIQPreviewTool endpoint = os.environ["FOUNDRY_PROJECT_ENDPOINT"] with ( # Signs in with your Azure command line interface account (from az login). DefaultAzureCredential() as credential, AIProjectClient(endpoint=endpoint, credential=credential) as project_client, project_client.get_openai_client() as openai_client, ): # 1. Define the Fabric IQ tool. It uses the connection you created in step 2. fabric_iq_tool = FabricIQPreviewTool( project_connection_id=os.environ["FABRIC_IQ_PROJECT_CONNECTION_ID"], require_approval="never", # The agent calls the tool without asking you first. ) # 2. Create the agent with your model, its instructions, and the Fabric IQ tool. agent = project_client.agents.create_version( agent_name="MyAgent", definition=PromptAgentDefinition( model=os.environ["FOUNDRY_MODEL_NAME"], instructions="Use the available Fabric IQ tools to answer questions and perform tasks.", tools=[fabric_iq_tool], ), ) print(f"Agent created (id: {agent.id}, name: {agent.name}, version: {agent.version})") # 3. Ask the agent a question. Change this to a question about your own data. user_input = "Which customers placed orders above $10,000 last quarter?" response = openai_client.responses.create( input=user_input, extra_body={"agent_reference": {"name": agent.name, "type": "agent_reference"}}, ) print(f"Agent response: {response.output_text}") # 4. Delete this agent version so unused versions don't build up in your project. project_client.agents.delete_version(agent_name=agent.name, agent_version=agent.version) print("Agent deleted") Finally, run the script. python fabric_iq_agent.py Learn more and share feedback We recommend that you move to Fabric IQ as soon as you can. We look forward to improving this integration, and we’d like to hear your feedback. Join the community discussion to share feedback and report issues. For more information, see these articles: Consume Fabric data agent from Microsoft Foundry via Fabric IQ Connect agents to Microsoft Fabric with Fabric IQ
Fabric Policies: Granular governance at scale (Preview)
As Microsoft Fabric grows across teams, workspaces, and capacities, governance becomes harder to manage with broad tenant-wide switches alone because governance models are not one-size-fits-all. Fabric Policies provide granular controls that can fit your governance model by defining what actions are allowed, to whom and where. The result is governance that scales with your Fabric estate. Teams keep the flexibility they need to work; capacity admins can protect the resources they manage, and central administrators gain consistent controls and visibility across the organization. Fabric Policies help organizations: Match controls to organizational boundaries - Apply organization-wide rules at tenant scope and resource-specific rules at capacity scope. Protect sensitive actions without slowing routine work - Keep approved self-service available while restricting higher-risk actions to the right users and context. Apply consistent guardrails at scale - Manage policies centrally through Policy Sets, Policies Center, auditing, and public APIs. What you can govern Fabric Policies currently provide controls for item creation, external data sharing (coming soon), and selected security-sensitive workspace settings. Control item creation by capacity Capacity admins can set a policy for any Fabric item type in workspaces assigned to their capacity (Power BI item creation is not yet enforced). An admin can allow the Data Engineering security group to create Dataflow Gen2 items in selected data platform workspaces and the AI Builders security group to create Data agent items in selected AI workspaces. Matching requests proceed; requests that do not match a complete Allow rule are blocked. This control supports a gradual Fabric rollout. Organizations can make specific item types available to approved teams and workspaces as their governance requirements are met, rather than enabling every item type everywhere at once. Item creation requires both controls to allow the request: the applicable Fabric item creation setting and the active Item creation policy. Figure: Advanced Item creation policy with separate Allow rules for Dataflow Gen2 and Data agent. Protect security-sensitive workspace settings Fabric admins can protect selected settings without removing broader workspace administration capabilities. An admin can allow the Central IT team to edit Outbound access protection, Inbound access protection, and Apply customer-managed keys (CMK) in sensitive workspaces. Other workspace admins can continue to edit the rest of the settings. The policy refines what existing workspace admins can change; it does not grant the Workspace Admin role. Govern external data sharing (Coming Soon) Fabric admins can support partner collaboration while controlling who can share, which workspaces the data comes from, its sensitivity label, and the recipient email domain. An admin can allow the Finance security group to share items labeled Confidential from Finance workspaces with recipients at CALDOVA.com. Sharing proceeds only when all configured conditions match; other requests are blocked. External sharing can be allowed by either the existing External data sharing tenant setting or a matching and active policy rule. How Policies work On Policy Set creation, an administrative scope is selected, such as the tenant or a capacity. This defines the available policy types and the administrator role required to activate the Policy Set for that scope. For each policy, administrators choose Allow all, Block all, or Advanced. Advanced policies use an allow-based model: All conditions within a rule must match. A match on any complete rule allows the action. If no rule matches, the action is blocked. Once the Policy Set is activated, Fabric evaluates its policies whenever a governed action occurs within that scope. Only one Policy Set can be active for a tenant or an individual capacity. Activating a replacement changes which definitions govern that scope. Existing access requirements remain in effect. Policies do not grant Fabric roles, workspace access, or item permissions. A user must first have the access required for the action; the policy then adds a governance decision for that action and context. Fabric Policies are available in preview for supported Fabric capacities and workspaces. Standard Fabric capacity and workspace requirements apply. Get started with Fabric Policies In Admin portal > Tenant settings, enable Policies (Preview). In a Fabric-capacity-backed workspace, create a Policy Set and choose Tenant or Capacity scope. Configure a policy with Allow all, Block all, or Advanced Allow rules, then review the users, actions, and workspaces covered. Activate the Policy Set as an administrator of the target scope. For capacity scope, select a capacity you administer. Review the related Fabric setting and policy together, then verify the active result in OneLake Catalog > Policies Center. For repeatable deployment across environments or capacities, use Fabric REST APIs to automate Policy Set and policy management at scale. API operations and activation remain subject to the required item permissions and administrator role. Policies best practices and management Design Advanced policies around every allowed scenario. List every user, item type, and workspace combination that must continue to work. Because Advanced policies are allow-based, a request is blocked when no complete rule matches. Align capacity policies with capacity ownership. Item creation policies govern workspaces assigned to the selected capacity. Each capacity can have its own active Policy Set, giving capacity admins control within their resource boundary. Review policy coverage whenever workspaces move between capacities. Use a dedicated management workspace. A Policy Set can be hosted in one supported Fabric-capacity-backed workspace and activated for a different capacity. A dedicated workspace can simplify access, ownership, and lifecycle management across multiple capacities. Separate editing from activation. People with Read, or the workspace Viewer role, can view a Policy Set. People with Read and Write, or a workspace Contributor, Member, or Admin role, can edit it. Activation still requires the administrator role for the target scope: Fabric admin for tenant scope or capacity admin for capacity scope. Validate before broad rollout. Start with representative users and workspaces and review each allowed scenario. Monitor and refine. Use Policies Center to review active policies and the Microsoft 365 Audit Log to follow Policy Set and rule lifecycle operations. Conclusion As Microsoft Fabric adoption scales across teams, workspaces, and capacities, governance must scale with it. Fabric Policies provide the flexibility to apply the right controls in the right contexts while maintaining a consistent governance model across the organization. By combining centralized oversight with granular policy enforcement, organizations can confidently expand their Fabric footprint without sacrificing security or control. Learn more about policies.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.
A new look and new capabilities in the Capacity Metrics App (Preview)
As announced at FabCon 2026 in Barcelona, we're releasing meaningful enhancements to the Capacity Metrics app in preview, designed to accelerate time to insight. This includes new and enhanced visuals and metrics across the health, compute, and storage pages—alongside improved navigation and a refreshed user interface design. A new item details page builds on the existing item history page, providing key insights for individual items running on the capacity. The aim is to support key user journeys, including: Identifying issues as they happen. Reviewing issues that have occurred over the last two weeks. Identifying risks before they result in throttling. Improved experiences An admin can now land on the health page and quickly identify capacities most in need of review. New metrics introduce easily understandable concepts like percentage of time spent in throttling, which can be compared across capacities and time periods. zation, and various types of throttling – providing the capacity admin a view across capacities to help them keep operations smooth. Once a capacity is identified for further review, the new compute page provides rich detail on the health state of the capacity and the biggest items impacting the capacity for the selected period. Key new visuals include: An updated utilization graph which expresses capacity unit (CU) consumption in CU seconds rather than a percentage, making it easy to see if your capacity has been scaled up or down, while also showing the current throttling state through conditional formatting. A new heat map visual that shows the capacities most utilized/overutilized state for each hour, making it easy to spot daily or hourly patterns. A new CU consumption table, which shows the item impacting the time window being reviewed (to a granularity of 1 hour). The visual shows smoothed CU consumption, meaning this truly reflects the highest impact items for the time being reviewed. on, all within a specified date range. Once an item is identified as a possible cause of high utilization, or if the user just wants to see additional detail on the item, the new item details page provides a 14-day history. The page has been designed from the ground up to give detailed insights which were previously unavailable. One key visual is the new CU utilization chart which shows the impact the selected item had on the overall capacity. Given the new experiences include changes to the existing metrics, it is being released as a preview alongside the existing app generally available experience, allowing time for you to adapt to the new app while still having access to the existing version. When you install the new version of the app, you will see the new preview as an additional option alongside the existing generally available versions of the reports. Getting started To support adoption of the new experience, explore the following resources for each new page: Existing Fabric Capacity Metrics app users will be notified when an update is available. Select Get it from the notification to update your current installation or install the latest version in a new workspace. Alternatively, you can install the app directly from the Microsoft Marketplace. Technical documentation with embedded video guidance: Health page Compute page Storage page Item details page User journey documentation, which explains how the app can be used in different situations. We're excited to put these new capabilities into your hands and look forward to your feedback as we continue evolving the Capacity Metrics experience to help you better understand, manage, and optimize your Fabric capacities.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.OneLake data access roles APIs announcement
Following the release of OneLake data access roles in public preview, the OneLake team is excited to announce the availability of APIs for managing data access roles. These APIs can be used to programmatically manage granular data access for your lakehouses. Manage all aspects of role management such as creating new roles, editing existing ones, or changing memberships in a programmatic way. Check out the API reference to learn more. Let’s look at an example of adding a new role using the APIs. The dataAccessRoles API gets and sets the role definitions for a lakehouse in bulk. To start, we want to fetch the existing role definitions for our lakehouse. The API follows the structure of: https://api.fabric.microsoft.com/v1/workspaces/{workspace_id}/items/{item_id}/dataAccessRoles Where {workspace_id} is the ID of your workspace, and {item_id} is the ID of the lakehouse you are defining permissions for. Once updated the final call looks like: GET https://api.fabric.microsoft.com/v1/workspaces/355b7f70-d3ce-4b1a-8630-5adf8b8df355/items/d753e987-5645-45b6-9f01-b248a367fabd/dataAccessRoles After calling this API we get the role definition below: { "value": [ { "name": "DefaultReader", "id": "dfb20430-869a-4ace-a442-b633f43f90af", "kind": "Policy", "decisionRules": [ { "effect": "Permit", "permission": [ { "attributeName": "Path", "attributeValueIncludedIn": [ "*" ] }, { "attributeName": "Action", "attributeValueIncludedIn": [ "Read" ] } ] } ], "members": { "microsoftEntraMembers": [], "fabricItemMembers": [ { "sourcePath": "355b7f70-d3ce-4b1a-8630-5adf8b8df355/d753e987-5645-45b6-9f01-b248a367fabd", "itemAccess": [ "ReadAll" ] } ] } } ] } We can then add a new role called MarketingReader that grants users access to only the marketing table in my lakehouse. First, let’s copy the role definition for the existing role and then make the required updates. We want the new role to be called MarketingReader, so we make that change to the name property for the new role. Next, we only want to grant access to the marketing table, so we replace the * (which gives root level access) with the path to our table. This array can take multiple string values if you want to grant access to multiple tables from a single role. Lastly, we want to configure the members for this new role. The defaultReader role uses dynamic role membership through the fabricItemMembers block of code. Instead, we want to give a Microsoft Entra group access to this role. To do this, we remove the fabricItemMembers block, and add a new user object to the microsoftEntraMembers array. All that’s needed is to provide the tenantId and objectId for the user or group. You can look up this information using the Microsoft Graph APIs. With our changes complete, we now have the finalized code below. { "value": [ { "name": "DefaultReader", "id": "dfb20430-869a-4ace-a442-b633f43f90af", "kind": "Policy", "decisionRules": [ { "effect": "Permit", "permission": [ { "attributeName": "Path", "attributeValueIncludedIn": [ "*" ] }, { "attributeName": "Action", "attributeValueIncludedIn": [ "Read" ] } ] } ], "members": { "microsoftEntraMembers": [], "fabricItemMembers": [ { "sourcePath": "355b7f70-d3ce-4b1a-8630-5adf8b8df355/d753e987-5645-45b6-9f01-b248a367fabd", "itemAccess": [ "ReadAll" ] } ] } }, { "name": "MarketingReader", "kind": "Policy", "decisionRules": [ { "effect": "Permit", "permission": [ { "attributeName": "Path", "attributeValueIncludedIn": [ "/Tables/marketing" ] }, { "attributeName": "Action", "attributeValueIncludedIn": [ "Read" ] } ] } ], "members": { "microsoftEntraMembers": [ { "tenantId": "fef5ca5f-150b-4270-9c4b-55e103545490", "objectId": "c3ddc490-8b9f-47c5-a6d9-a686ce64b424" } ], "fabricItemMembers": [] } } ] } We can then PUT the payload back to our lakehouse, updating the existing role definitions to match the ones specified in the API call. PUT https://api.fabric.microsoft.com/v1/workspaces/355b7f70-d3ce-4b1a-8630-5adf8b8df355/items/d753e987-5645-45b6-9f01-b248a367fabd/dataAccessRoles We have now updated our role definitions and our marketing users can start accessing the marketing table in the lakehouse. Check out the links below for more information on OneLake data access roles and thanks for reading! OneLake data access roles API reference. Get started with OneLake data access roles (preview). Best practices for OneLake security.
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.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!
Introducing ownership takeover for Fabric items
Today, when an item owner leaves the company, their credentials expire, or they lose access, many Fabric items cease to function. For example, Lakehouses and their SQL Endpoints become inoperative, pipelines fail to execute due to user access errors. In these situations, enabling another user to assume ownership would ensure business continuity. We are pleased to announce that Fabric users with the right permissions can now take ownership of Fabric items. How does this work? Fabric users who have read and write permissions on Fabric items (i.e., admin, member, contributors in a workspace) can take ownership of a Fabric item. To take ownership of a Fabric item, please follow these steps: Navigate to your Fabric workspace and locate the item which needs ownership change. Access the item's settings. In the About tab, select Take over. This initiates the background process of updating the item's owner to the user attempting to take ownership. A message bar will indicate whether the takeover operation succeeded or failed. If a connection used by the item stops functioning after the takeover, users can edit the connection within the item. The existing Take over feature for Power BI items will continue to work, while this new feature is being introduced for other Fabric items. Furthermore, ownership change is currently not supported for Mirrored Database items. Learn more about this feature and known limitations: Take ownership of Fabric items | Microsoft Fabric. What's next? The current feature allows users to take Fabric item ownership via the UI. In the future, we plan to add support for taking ownership of Fabric items via APIs. If you have any suggestions for further enhancements to this feature, please share your ideas on Microsoft Fabric Ideas.Get ready for table discovery in OneLake Catalog search (Preview)
In late September, OneLake Catalog will begin surfacing tables as searchable objects in Microsoft Fabric. This change expands which table metadata users can discover based on their existing item permissions, so administrators may want to review the related tenant setting before rollout. To give organizations time to prepare, the controlling tenant setting is already available in the Fabric admin portal. Administrators can review and configure this setting before table search becomes available. Tables are the first object, an entity contained inside a Microsoft Fabric item, that OneLake Catalog will return as a standalone search result. Bringing objects into search makes the catalog more useful for everyday discovery because they are often where analysis, reporting, and development work begins. Find tables directly Finding the right data often starts below the item level. You may know a table name, its purpose, or only the name of a column it contains, but not which item contains it. Table discovery will let you search directly for tables in semantic models, lakehouses, and mirrored databases without first locating and opening the parent item. We plan to support tables from more Microsoft Fabric item types, along with additional object types, as OneLake Catalog expands beyond item-level discovery. Each matching table will appear as its own result rather than as metadata attached to the parent item. Columns will not appear as standalone results, but you can still find the relevant table when a column name is your only starting point. Table discovery will be available in Fabric’s global search UI and programmatically through the OneLake Catalog Search API. You will be able to search by table name or description or use an exact column-name match to find its containing table, without knowing the workspace or parent item in advance. You can also access search through the Fabric Core remote MCP server, Fabric local MCP server, or the search skill from the Fabric Skills library. These options bring the same permission-aware discovery to applications, AI agents, GitHub Copilot, and other compatible AI coding tools. Understand how permissions affect table visibility Before table search becomes available, administrators should understand how existing permissions affect what users can discover. This change does not grant access to additional data, but it may allow users to discover metadata for tables contained within items they can already access. You can discover a table only if you have Read control-plane permission or higher on its parent item. You do not need Read All or Read Data permission to find a table in search. Data-plane permissions, including OneLake security, do not change whether a table appears in catalog search. The relevant workload still enforces its data-access permissions when you open, query, or otherwise use the table. Catalog discoverability and data access remain separate decisions. Tables in semantic models protected by object-level security are excluded from search. Object-level security can protect table and column names as well as their metadata, so OneLake Catalog currently does not surface tables from those models. Control object discovery with a tenant setting Before table search rolls out, Fabric administrators should review the Users can find objects in search tenant setting. This setting controls whether users can discover contained objects such as tables through Global Search and the Search API. The setting is enabled by default, allowing users to find supported objects when they have access to the parent item. When it is disabled, search results are limited to top-level Fabric items, such as lakehouses and reports. Disabling the setting does not change access to the underlying items or data; it changes whether contained objects appear in search. Additional search improvements Apart from table discovery, this release also introduces several improvements in search for Microsoft Fabric items. Get richer item results New filters and expanded metadata make item results more precise and useful. You can: Return and filter item results by endorsement status, workspace ID, and sensitivity label ID. Find dataflows and dashboards in search results. Identify reports and dashboards included in a workspace app and retrieve the relevant app context. This context helps you distinguish between similar items, apply governance signals, and choose the right result without making additional requests. These improvements provide more ways to narrow large result sets and enough context to understand where an item belongs before you open it. Refine searches with new operators New query operators give you more control over how search interprets your terms: Use quotation marks (" ") to search for an exact phrase. Use an asterisk (*) as a wildcard for multiple characters. Use a question mark (?) as a wildcard for a single character. Use double ampersands (&&) to return only results that contain all specified terms. These operators help you narrow results when names are similar or when you know only part of a name. Prepare for rollout Tables are the starting point for discovery below the Fabric item level. The same catalog model can support more object types over time while preserving parent context, permission trimming, and a consistent way to search. For now, table search addresses a common need: finding the table you want from its name, description, or an exact column-name match without already knowing where it lives. Table search will begin rolling out late September. Before rollout, administrators should review the tenant setting, and developers can prepare the search experiences they plan to offer: Review the Users can find objects in search tenant setting in the Fabric admin portal and decide whether object discovery should be enabled for your organization. Explore the OneLake Catalog Search API if you build data portals, governance tools, or other discovery experiences. Connect an AI development tool through a Fabric MCP server or install the search skill from the Fabric Skills library to prepare agentic discovery workflows.
