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
Incrementally migrate and re-migrate database objects with Migration Assistant for Fabric Warehouse (Preview)
Migrate database objects to Microsoft Fabric in phases without creating a new Warehouse for every run. Start with one business domain, add another when it is ready, or revisit an object after its source definition changes. You can also build on an existing Warehouse instead of replacing it. Incremental migration for Microsoft Fabric Data Warehouse (Preview) lets you move workloads in manageable phases while keeping control of the destination. Select the objects required for the current workload, add more objects in later runs, and resolve naming conflicts when an incoming object already exists. The process migrates object definitions; it does not continuously synchronize changed rows. You can start with an empty Warehouse, continue a previous migration, or use an existing Warehouse that was not created through migration. This flexibility lets teams preserve completed work while adding the next approved scope. It also supports deliberate consolidation into the Fabric destinations that match your architecture. Choose the objects that belong in each migration Enterprise migration plans often span several teams, applications, and business domains. Those groups do not always need to move together. Incremental migration lets you define the scope of each run. Instead of including every source object, select the objects needed for the workload you are moving. For example, start with the schemas, tables, and views required by one business domain. Review the translated definitions and validate the dependent workload before expanding the scope. In a later run, return to the same Warehouse and add the next approved set of objects. In the destination Warehouse, open the Migration tab and select Get more objects. Provide the source connection or upload a supported source input, and then select Choose more objects to migrate to define the next set. Figure: Use Get more objects to start another migration run from the destination Warehouse. Figure: Select source objects and review dependencies and naming conflicts before migration. Before you start the run, review the complete object list populated in the selection dialog. The list flags naming conflicts and adds direct dependencies for selected objects. Confirm that every included object is necessary for the workload you intend to migrate. Filter source objects to show all objects, objects with naming conflicts, or objects without naming conflicts. Identify objects whose names already exist in the destination through warning indicators. Review each selected object’s direct dependencies before you start the migration. Migration Assistant includes those dependencies by default, so the final scope can contain more objects than you initially selected. Review the source, destination, selected objects, and included dependencies in the summary. Confirm that every object belongs in the current scope and that naming conflicts have an owner. The Migration Assistant guide for connecting to a source system describes the workflow. Build on an empty or existing warehouse The destination does not have to come from an earlier migration or a specific migration mode. Choose the destination based on the workload, ownership model, security boundary, and naming plan. The following starting points are supported. An empty Warehouse: Begin with a destination you have prepared and migrate the first set of objects into it. A previously migrated Warehouse: Add more objects or revisit selected objects from an earlier run. A Warehouse that was not created through migration: Bring source objects into a Warehouse that already contains work created through other means. You do not need to create another Warehouse just because you are starting another migration run. Reusing a destination can reduce unnecessary duplication and keep related objects together. Confirm, however, that the shared destination fits the workload and data-isolation requirements. Re-migrate objects with control Migration work often requires revisiting an earlier decision. A source definition can change after the first run, or a translated object might need correction after validation. Re-migration lets you return to that object without treating the entire source as a new migration. When an incoming object's name already exists in the destination, Migration Assistant identifies a naming conflict. Objects without naming conflicts can be created immediately. Conflicting objects remain pending and are not created or replaced until you explicitly choose how to resolve each conflict. For each conflict, compare the SQL definitions side by side: the existing definition on the left and the incoming translated definition on the right. Review the full definition, not only the highlighted difference, because connected changes can affect downstream objects. Then choose the action that fits the object. Keep existing: Retain the destination's current definition and discard the incoming translated definition. Keep incoming: Replace the existing definition with the incoming translated definition, confirming the action when prompted. Rename incoming: Create the incoming object under a different name while retaining the existing object. Conflict handling makes re-migration an explicit decision. You can preserve work already completed in Fabric, accept a revised source definition, or keep both definitions under different names. Record the chosen action so that workload owners understand which definition is active. Figure: Compare existing and incoming definitions before resolving a naming conflict. Replacing an object changes its definition in the destination and may require you to reload data or revalidate dependent workloads. Before you replace a table, view, or procedure, identify the objects and processes that use it and plan the required follow-up work. For detailed behavior, refer to Resolve conflicts and fix objects. Consolidate your data estate Incremental migration lets you move selected objects from supported SQL Server databases, Azure Synapse Analytics dedicated SQL pools, or Teradata databases into one or more Fabric Warehouses. A separate destination Warehouse is not required for every source database or migration run. The destination design should still reflect workload ownership, security, naming, and data-isolation requirements. This approach supports several consolidation patterns. Choose a pattern only after confirming that the workloads can share the same operational and security boundaries. Common uses are listed below. Consolidate objects from multiple databases on the same source platform. Bring together selected objects from different supported source platforms. Expand the same Warehouse as additional databases and workloads are ready to migrate. As you add objects, conflict handling helps you manage names already present in the destination. Compare existing and incoming definitions, then keep the existing object, replace it with the incoming definition, or rename the incoming object. This decision determines which definition becomes part of the consolidated Warehouse. Consolidating destinations does not automatically reconcile definitions or combine table data. Review dependencies, naming conventions, permissions, ownership, and data-loading requirements before each run. These checks help the consolidated Warehouse reflect the intended architecture rather than an accidental collection of objects. Keep object migration and data loading distinct In this preview, incremental migration means selecting, adding, or revisiting database object definitions across separate migration runs. It covers object selection, translation, dependency handling, and definition conflicts, but it does not continuously synchronize changed rows. After migrating the required definitions and resolving conflicts, plan the associated data movement. Migration Assistant can integrate with a copy job in Data Factory for Microsoft Fabric to copy data into the destination. Treat that data movement as a separate activity with its own schedule, monitoring, and validation. Validate each selected workload before expanding the migration scope. Verify translated definitions, dependency completeness, conflict decisions, permissions, and the queries or reports that depend on the migrated objects. When replacing a table definition, include the required data reload and downstream validation in the plan. Keeping object migration and data loading distinct makes each run easier to review. The team can state which definitions move, which existing objects change, and what data work follows. That separation also makes failures easier to isolate and rerun. Next steps Reduce migration risk by starting with a small, representative workload: identify its boundary, choose the destination Warehouse, migrate the required objects, and validate the result before expanding the scope. For prerequisites and supported workflows, review the Migration Assistant for Fabric Data Warehouse overview, and then follow either the source-connection migration guide or the file-based migration guide.Simplify Teradata migrations with Fabric Migration Assistant (Preview)
Migrating an enterprise Teradata estate to Microsoft Fabric can require extensive manual work across database objects, SQL and BTEQ code, dependencies, and operational processes. Fabric Migration Assistant helps reduce that effort so teams can focus their review on the objects and workflows that need attention. Fabric Migration Assistant for Data Warehouse now supports Teradata sources in preview. It converts eligible Teradata metadata and code to Fabric-compatible T-SQL, deploys eligible destination definitions, and flags scripts that need review or remediation, reducing the manual effort required to prepare a migration. You can choose which objects to migrate, review the translated code, and focus remediation on exceptions instead of manually translating every eligible object. Migration Assistant does not move the associated data; you load data in the following step of the migration flow. Define a migration scope you can validate Reduce migration risk by starting with a representative set of interdependent objects from one workload or business process. Keeping the related tables, views, procedures, functions, and macros together lets you evaluate the translated result as a working unit. A focused scope makes it easier to distinguish among three outcomes: Translation: The source definition was converted to Fabric-compatible T-SQL. Deployment: The translated definition was created successfully in the destination warehouse. Validation: The migrated workload produces the expected behavior and results. Translate Teradata metadata into Fabric-compatible T-SQL Package your Teradata .sql and .bteq files into a ZIP archive, including the object definitions and dependencies needed for the selected scope. From the Fabric workspace, open Migrate and select Teradata (Preview) under Migrate to a warehouse. The guided experience lets you upload the archive, choose the objects in scope, and confirm the destination before migration begins. Migration Assistant translates and creates eligible definitions for: Tables Views Stored procedures SQL functions Macros, which translate into stored procedures After the run, review migrated objects to see their status and translation details. This review helps you identify datatype and SQL changes that require validation before you treat successful object creation as a completed migration. Use the file-based Migration Assistant guide for the upload, object-selection, and review workflow. Focus remediation where it's needed Teradata and Fabric Data Warehouse don't have a one-to-one mapping for every construct. Some definitions translate directly; others need a different implementation. Teradata macros translate into stored procedures, while volatile tables map to local temporary tables. Review the maintained Teradata SQL translation reference for object mappings, data types, BTEQ behavior, and constructs that need redesign. Migration Assistant groups scripts that could not be translated or deployed under Objects to fix. For each object, the source definition, translation comments, and error details help you determine whether the issue requires a syntax correction or a broader change to workload behavior. If Copilot is available and enabled in your environment, Fix query errors can suggest a correction. Treat the suggestion as a starting point: compare it with the source definition and error details, revise it as needed, and run the script to validate the result before creating the object. Before accepting a corrected object, confirm that it preserves the intended workload behavior by comparing parameters, joins, filters, and transaction boundaries with the source logic. Bring BTEQ business logic into Fabric workflows BTEQ scripts can combine SQL with control flow, session management, imports, exports, and operational logic. Migrating those scripts requires attention to the surrounding workflow, not just the SQL statements. Migration Assistant translated eligible SQL and supported BTEQ elements into stored procedures. Review the generated procedures, then rebuild imports, exports, orchestration, and external operations with the appropriate Fabric capabilities. Different parts of a BTEQ workload can use different Fabric capabilities: SQL and supported control flow: Review the translated stored procedure. Data imports and exports: Use the appropriate loading or export capability, including COPY INTO or pipeline copy activities. Scheduling, orchestration, and external operations: Recreate the required behavior through Fabric pipelines or other appropriate execution environments. Translation doesn't automatically reproduce the entire operational environment. Validate parameters, error paths, sequencing, and external dependencies alongside the translated SQL. The objective is to preserve the business behavior you need while choosing suitable Fabric implementations. Figure: Animated GIF —Migration Assistant for Teradata migration showcasing metadata translation flow. Choose how to move the data Metadata migration establishes the destination definitions in Microsoft Fabric Data Warehouse. Data movement loads the associated rows after the required table definitions are in place. Choose the method that fits each workload: Copy job: Use the guided transfer from Migration Assistant's Copy data step. Connect to Teradata, select tables, review mappings, and choose the copy mode. A full copy can establish the initial dataset; incremental copies are an option when the source configuration supports them. Staged files and COPY INTO: For large historical transfers, unload Teradata data to Azure Data Lake Storage Gen2 and load the staged files into Fabric Data Warehouse with COPY INTO. Fabric pipelines: Use pipelines when the migration needs multi-step orchestration, transformations, branching, or custom recovery logic. To learn more, refer to Migration methods for Teradata to Fabric Data Warehouse for data movement options and guidance on replacing Teradata loading utilities. Validate the migrated workload Run representative queries and compare the results with the Teradata workload. Validate row counts, aggregates, filters, joins, null handling, and the date and numeric behavior that affects the business process - not merely whether each object exists in the destination. Include both expected paths and failure paths in the test scope. For procedures and translated BTEQ logic, verify parameter handling, transaction boundaries, retry behavior, and the sequence of dependent operations. Next steps Use Plan a migration from Teradata to Fabric Data Warehouse to define the scope and validation approach. Review Translate Teradata SQL for Fabric Data Warehouse for object mappings and use Migration methods for Teradata to Fabric Data Warehouse to choose the data-movement method.
From mixed events to real-time action: Fabric Eventstreams Q3 2026
Coauthor: Arindam Chatterjee Fabric Eventstreams makes it easy to connect to streaming sources, transform the ingested events and route them to destinations across Microsoft Fabric. But building real-time systems also requires teams to understand the events in motion, enriching them with business context, detecting and responding to any issues on time, and securely managing their streams across environments. That broader experience is the story behind this quarter’s updates. Eventstreams is expanding beyond connectivity and data movement to provide more of the capabilities teams need to work with streaming data after it arrives, while it is still in motion. With these expanded capabilities, users can now: Connect to more managed sources and extend Eventstreams with custom connectors. Capture change feeds from more operational databases. Explore and process multiple event types in a single Eventstream. Enrich streaming events with contextual data before processing and routing. Monitor processing health, diagnose problems, and act faster. Deploy with workspace-scoped networking and reusable configuration. Connect managed and custom streaming sources Eventstream added generally available managed connectors for SAP Datasphere, Cribl, Solace PubSub+, and MQTT, extending native connectivity across enterprise applications, observability pipelines, event meshes, and IoT brokers. For these common scenarios, teams can use managed connectors instead of writing and hosting connector code. Managed connectors cover a growing range of common sources. But many organizations also need to connect proprietary applications, partner products, and internal platforms. Custom Stream Connector (Preview) lets organizations bring compatible Kafka Connect source connectors into Fabric when a native connector is unavailable. Teams can manage versions, publish connectors internally or through a partner, and make them discoverable in Real-Time hub. This approach extends managed Fabric pipelines to proprietary applications, partner products, and internal platforms while allowing independent software vendors to retain control of their code and licensing. What shipped: SAP Datasphere connector (Generally Available), Cribl connector (Generally Available), Solace PubSub+ connector (Generally Available), MQTT connector (Generally Available), Custom Stream Connector (Preview). Bring operational changes into the stream Orders, inventory updates, account changes, and application state already live in operational databases. Capturing those changes is only the first step. Teams must also operate connectors, recover from failures, handle schema changes, and scale the pipeline. This complex operational work makes many CDC-based solutions difficult to sustain. Two connectors reaching general availability this quarter move more of that burden into Eventstream. The Mirrored Database Change Feed connector consumes row-level inserts, updates, and deletes from change-feed-enabled mirrored databases. The MongoDB CDC connector supports MongoDB Atlas, cloud-hosted, and self-managed deployments. Both bring database changes into Eventstream's managed processing model, ready for the same DeltaFlow transformations available to other CDC sources. What shipped: Mirrored Database Change Feed connector (Generally Available), MongoDB CDC connector (Generally Available) Understand every event shape Streaming data rarely arrives in one consistent shape. A source may carry messages from multiple device types, application payloads may evolve, and teams may combine sources to improve utilization and reduce cost. Treating every payload as a union of every possible field makes exploration harder and creates long fragile transformations. Schema Registry and Event Schema Sets (Generally Available) provide reusable contracts for streaming data. Teams can define Avro schemas, group related schemas, retain earlier versions, compare changes, and discover schemas across Fabric workspaces. Schema-aware Eventstreams (Preview) lets one eventstream understand and process multiple event types. Events with registered schemas, along with change feeds from supported operational databases, are recognized automatically. For unschematized payloads, users can classify events with a field such as deviceType or entityType. A redesigned data preview makes it easier to inspect each event: Browse and inspect nested JSON structures View event headers and metadata along with the actual payload Download selected events What shipped: Schema Registry and Event Schema Sets (Generally Available), Schema-aware Eventstreams (Preview). Add business context in flight Live events often contain only a device ID, customer ID, or product code. Without the surrounding business context, downstream systems cannot make an informed decision until a separate batch process enriches the data once it reaches an analytical store. Reference Data with Delta Table (Preview) brings that enrichment into Eventstream. A live event can join with reference data in a Lakehouse or warehouse table, including shortcut-backed Delta tables. No-code INNER and LEFT OUTER joins cover common patterns, while the SQL experience supports more complex logic. The event gains business meaning before it is routed, not after. What shipped: Reference Data with Delta table (Preview) Detect issues and act faster A streaming pipeline can appear to be running even when a node falls behind, events arrive outside the expected time window, or a destination rejects processed values. A top-level running state is not enough to diagnose these conditions. This quarter adds a more complete operating loop around each Eventstream. Workspace Monitoring helps teams observe throughput, backlog, watermark delay, errors, and node health. Processing logs and editor validation help diagnose malformed input, query failures, type-conversion errors, event-time policy violations, recovery events, and destination-access problems. Teams can act by creating and managing Activator rules without leaving Eventstream, then optimize capacity by routing Capacity Operation Events through Eventstream for operation-level analysis, alerting, and governance. What shipped: Workspace Monitoring for Eventstream (Preview), Workspace Monitoring diagnostic-log support (Preview), Activator rule management in Eventstream (Generally Available), Capacity Operation Events source (Preview). Secure and deploy eventstreams consistently Enterprise streaming workloads often need private connectivity, environment-specific configuration, and explicit control over where data can flow. Workspace-level Private Link (Preview) for Eventstream lets administrators apply private inbound connectivity to selected Fabric workspaces instead of imposing the same network posture across the tenant. Variable Library support (Preview) keeps environment-specific connections, item references, parameters, and value sets separate from pipeline logic. Teams can carry one Eventstream across development, test, and production without embedding each environment's values in the definition. These capabilities build on existing support for private and on-premises sources, workspace identity, custom certificate authorities, mutual TLS, and outbound access protection. What shipped: Workspace-level Private Link for Eventstream (Preview), Variable Library support for Eventstream (Preview). What this quarter adds up to Together, these updates create a more complete path from incoming events to business action. Teams can understand mixed payloads, enrich events while they are moving, bring in operational changes, connect managed or custom sources, diagnose processing problems, and carry the same Eventstream safely across environments. This quarter also brings an early glimpse of how Eventstreams can connect streaming and batch data movement more closely. Copy Job support for Eventstreams (Preview) enables an Eventstream to be used as either a source or destination in the Copy Job experience, creating an initial bridge between the two. The experience starts in Copy Job today, but it points toward more connected data movement experiences across Fabric. Fabric Eventstreams is expanding beyond ingestion to help teams shape, enrich, monitor, and govern real-time data as it moves from source to business action. Resources Generally Available Schema Registry in Fabric Real-Time Intelligence Add Mirrored Database Change Feed source to an eventstream Add MongoDB CDC source to an eventstream Add an SAP Datasphere source to an eventstream Add Cribl source to an eventstream Add Solace PubSub+ as source to an eventstream MQTT Source in Fabric Eventstream Add a Fabric Activator Destination to an Eventstream Preview Schema-Aware Eventstreams Overview (Preview) Enrich Events with Reference Data in Fabric Eventstreams Add a custom stream connector to an eventstream Eventstream Workspace Monitoring Overview (preview) Fabric Capacity Operation Source in Fabric Eventstream Secure inbound connections with Tenant and Workspace Private Links Variable Library Integration with Eventstreams For the full release roundup, including items outside this post's scope, see the August 2026 Fabric Feature Summary and the September 2026 Fabric Feature Summary. Get started Start with the capability above that most closely matches what your team needs, then follow its documentation links to try the corresponding Eventstream feature(s) in your workspace. Found a gap, a bug, or a scenario these features do not cover? Share it through Fabric Ideas or directly with us on the Eventstream PM team. Your feedback helps shape what comes next.
More expressive graph analysis: GQL improvements in Microsoft Fabric Graph
Coauthors: Idris Motiwala, and Justin Fine January–August 2026 updates expand how users find, inspect, compose, and analyze connections. Organizations use graph data to understand how information moves between systems, how services depend on one another, how conversations develop, and how people or organizations relate. Graph Query Language (GQL) in Microsoft Fabric Graph helps users explore and analyze those connections with standardized query patterns. From January through August 2026, new GQL capabilities made it easier to control traversals, inspect paths, compose multistage queries, summarize connected data, and work with complex values. These improvements help analysts express more graph questions in a single query and give developers finer control over query behavior. The following sections explain where each capability is useful and show the associated syntax. Find and control paths Shortest paths with ANY SHORTEST When several paths connect two entities, many applications need one shortest path rather than every possible path. ANY SHORTEST makes that intent explicit. This is useful for dependency analysis, recommendations, network routing, and investigations where fewer intermediate steps are preferred. MATCH ANY SHORTEST ({id: 1})->{,2}(d) RETURN d.id AS dst Quantified edge patterns Quantified edge patterns repeat a complete relationship pattern and can apply conditions to intermediate nodes. In the following example, each repeated step requires the source person to use Chrome. This gives developers more control than repeating only an edge pattern. MATCH p=(a:Person {id: 987})((x)-[k:knows]->() WHERE x.browserUsed = 'Chrome'){2}(b:Person) FOR n IN NODES(p) WITH OFFSET off RETURN n.browserUsed ORDER BY a.id, b.id, off LIMIT 12 Complete path modes Path modes define whether a traversal can revisit nodes or edges. WALK permits repetition. TRAIL prevents repeated edges. SIMPLE prevents repeated interior nodes. ACYCLIC prevents any repeated node. DIFFERENT EDGES prevent one edge from satisfying more than one edge variable in the match. These choices help query results reflect the meaning of a route, hierarchy, or dependency chain. MATCH WALK (:Person {firstName: "Juliana"})-[:studyAt]->(:University)<-[:studyAt]-(p:Person) RETURN p.firstName AS name MATCH TRAIL (:Person {firstName: "Juliana"})-[:studyAt]->(:University)<-[:studyAt]-(p:Person) RETURN p.firstName AS name MATCH SIMPLE (x)->{2}(y) RETURN COUNT(*) AS path_count MATCH ACYCLIC (x:`node` {id: 1})->(y)->(z) RETURN x.id, y.id, z.id ORDER BY x.id, y.id, z.id MATCH DIFFERENT EDGES (p:Person {name: 'Keanu Reeves'})-[e:ACTED_IN]->(m:Movie) RETURN m.title AS movie Unbounded variable-length path patterns Variable-length paths previously required a maximum hop count. Unbounded quantifiers allow the graph structure to determine the traversal depth when no meaningful fixed limit exists. The example follows one or more relationships, while ACYCLIC prevents the traversal from visiting the same node twice. Unbounded refers to the path expression, not unlimited compute, so use selective starting points and test performance with representative graph density. MATCH ACYCLIC ()-[]->{1,}() RETURN COUNT(*) AS total Inspect paths and graph elements NODES, EDGES, and INNER_NODES These functions expose the contents of a matched path. NODES returns all nodes in the path, EDGES returns all relationships in the path, and INNER_NODES returns the intermediate nodes without the endpoints. Applications can use these results to explain lineage, dependencies, and investigative findings instead of returning only a destination. MATCH p=({id: 1})-[]->{0,4}(z) RETURN NODES(p) AS res_nodes, INNER_NODES(p) AS res_inner_nodes ORDER BY z.id ELEMENT_ID ELEMENT_ID returns the identity of a graph element. It is useful when an application must compare, track, or reference a specific node or edge independently of its business properties. MATCH (x) RETURN ELEMENT_ID(x) AS vid, x AS actual_id ORDER BY x.id LIMIT 5 SOURCE and DESTINATION SOURCE and DESTINATION identify the endpoints of an edge. This makes directional checks and edge-centric analysis easier, especially when a query starts from a relationship rather than a node. MATCH (x)-[e]->() RETURN x.id, SOURCE(e).id AS s ORDER BY e.src, e.dst LIMIT 10 MATCH ()-[e]->(x) RETURN false IN COLLECT_LIST(x = DESTINATION(e)) AS no Compose larger queries NEXT NEXT passes the output of one query stage into the next, allowing analysts to express a multistep question in a single query. For example, they can calculate a measure, filter the result, traverse another relationship, and summarize the final result without moving intermediate data into application code. MATCH (m:Message)-[:hasCreator]-(p:Person) RETURN p, AVG(m.length) AS avg_msg_length GROUP BY p NEXT FILTER avg_msg_length > 100u MATCH (p)-[:knows]->(:Person) RETURN avg_msg_length, COUNT(*) AS connections GROUP BY p, avg_msg_length EXISTS subqueries EXISTS answers a yes-no question about another graph pattern. It can filter rows or participate inside an aggregate without requiring the outer query to return the matching details. MATCH (x) WHERE EXISTS { MATCH (y) WHERE y.id = 5 RETURN y } RETURN x.id AS xid ORDER BY xid MATCH (x) RETURN COUNT(*) FILTER ( WHERE EXISTS { MATCH (x)-[]->(y) RETURN y } ) AS count_with_out CALL subqueries CALL runs a contained query for each current outer result. In the example, it calculates each node’s outgoing degree and returns that value with the node identifier, keeping the intermediate calculation contained within the query. MATCH (x) CALL { MATCH (x)-[e]->(y) RETURN COUNT(e) AS out_degree } RETURN x.id AS xid, out_degree ORDER BY xid OPTIONAL CALL OPTIONAL CALL preserves the outer row when the contained query has no match. This supports enrichment scenarios where related information is useful but not required. MATCH (x {id: 1}) OPTIONAL CALL { MATCH (y)-[]->(x) RETURN y.id AS yid } RETURN x.id AS xid, yid ORDER BY yid UNION DISTINCT UNION DISTINCT combines compatible result sets and removes duplicate rows. It complements UNION ALL, which preserves duplicates, so the query can choose the correct set behavior. MATCH () LIMIT 3 RETURN 42 AS x UNION MATCH () LIMIT 3 RETURN 100u AS x Summarize connected data Filtered and paged aggregates Filtered aggregates calculate a summary over a selected subset. Paging controls such as LIMIT can be applied within the aggregate, giving developers precise control over which values contribute to the result. MATCH (m:Movie) RETURN COUNT(*) FILTER (WHERE m.released < 1980 LIMIT 10) AS filtered_count Nested aggregations Nested aggregation supports layered questions, such as finding the minimum of averages calculated across groups or paths. This reduces the need to move intermediate results into application code. MATCH (a:`node`)-[e:`edge`]->{1,2}(b:`node`) RETURN a.id AS id, MIN(AVG(e.weight)) AS min_average GROUP BY id COLLECT_ONE, COLLECT_LIST, and COLLECT_ELEMENTS Collection functions retain values or graph elements for evaluation as a group. COLLECT_ONE selects one value, COLLECT_LIST builds a list, and COLLECT_ELEMENTS gathers graph elements. They are useful for path-level checks, ordered output, and analysis across repeated relationships. MATCH (p:`node` {id: 1})-[e]->{2}(p1:`node` {id: 1}) RETURN (COLLECT_ONE(e.weight) IN [e[0].weight, e[1].weight]) AS contained MATCH ()-[e]->{1,2}() RETURN COLLECT_LIST(ALL e.weight) AS w ORDER BY w LIMIT 20 MATCH ()-[a:ACTED_IN]->{0,4}() WHERE SIZE(COLLECT_ELEMENTS(DISTINCT a.roles)) > 4 RETURN TO_JSON_STRING(a.roles) AS r Work with values and text Dynamic nested data Support for dynamic nested data lets queries work with richer values that do not fit a flat property model. This is useful when graph entities contain structured application payloads, nested attributes, or evolving schemas. CAST CAST converts a value to a supported target type. Explicit conversion makes comparisons and calculations more predictable when source data contains different numeric types. RETURN CAST(42 AS DOUBLE) AS double_res, CAST(42 AS UINT) AS uint_res, CAST(42.5d AS INT) AS int_res RANGE RANGE creates a numeric sequence. A generated sequence can support iteration, testing, bucketing, and list-oriented calculations within a query. RETURN RANGE(0, 4) AS res POWER POWER performs exponent calculations. It extends the numeric expressions available for scoring, weighting, and mathematical transformations. RETURN POWER(-2, 3) AS res NORMALIZE and IS NORMALIZED Unicode text can have visually identical but technically different encodings. NORMALIZE converts text to a normalization form, while IS NORMALIZED checks its current form. This supports more consistent matching and grouping across multilingual data. RETURN NORMALIZE('cafe\u0301') AS normalized_text RETURN 'cafe\u0301' IS NFKD NORMALIZED AS is_normalized Regular-expression functions The MSFT.REGEXP functions match, count, locate, extract, and replace text patterns. They help prepare identifiers, names, codes, and descriptions before those values are compared or summarized. RETURN MSFT.REGEXP_LIKE('café', 'caf.') AS x RETURN MSFT.REGEXP_COUNT('abcabcabc', 'abc') AS n RETURN MSFT.REGEXP_INSTR('hello world', 'world') AS p RETURN MSFT.REGEXP_REPLACE('a1b2c3', '[0-9]', '#') AS s RETURN MSFT.REGEXP_SUBSTR('abc123def', '[0-9]+') AS s Design guidance Use the narrowest pattern that answers the question. Start from selective nodes, specify relationship and node labels, and apply filters early. Use bounded traversal when the business question has a natural maximum. When depth is unknown, combine an unbounded path with an appropriate path mode and test it against representative graph density. Return only the properties or path elements the application requires. Feature availability can vary by environment and release stage. Confirm the release stage and regional availability of each feature before publication. If availability differs by feature, identify the applicable release stage in each section. Next steps Start with a connected-data scenario such as lineage, dependency analysis, recommendations, investigations, or knowledge discovery. Identify the relationships the question must follow, choose the path mode and traversal depth that match the scenario, and then use composition and aggregation features to shape the result. Graph in Microsoft Fabric overview GQL language guide for graph in Microsoft Fabric GQL graph patterns GQL standard conformance for graph in Microsoft Fabric Optimize GQL query performance for graph in Microsoft FabricT-SQL language enhancements in Microsoft Fabric Data Warehouse (Preview)
Microsoft Fabric Data Warehouse is expanding its T-SQL capabilities with four language enhancements in preview. GROUP BY ALL, ORDER BY ALL, the QUALIFY clause, and the FROM ... SELECT query format help SQL developers and data professionals reduce repetitive code, simplify query maintenance, and make analytical logic easier to understand. What’s new Four T-SQL language enhancements are available in preview: GROUP BY ALL — automatically groups by every non-aggregate expression in the SELECT list, reducing duplication between SELECT and GROUP BY clauses. ORDER BY ALL — sorts results by each column in the SELECT list, using the same column order, so developers do not need to repeat every sort expression. QUALIFY — filters rows after window functions are evaluated, so common ranking and top-N patterns no longer require an additional subquery or common table expression. FROM ... SELECT — provides an alternative query format that begins with the data source and defines the selected columns later, allowing developers to write complex queries in a source-first sequence. These additions reduce repetitive code and make query intent easier to understand. They are especially valuable when queries include many grouping or sorting columns, when analytical results require filtering, or when a source-first structure makes complex logic easier to follow and maintain. Together, these enhancements make queries easier to adapt as requirements change. Developers can add or remove projected columns with less rework, filter analytical results without an extra query layer, and organize complex queries in the sequence that best matches how they reason about the data. New capabilities: Write shorter queries with less repeated code. Make grouping, ordering, and analytical filtering easier to understand. Reduce maintenance when projected columns change. Express source-first query logic in a clear, natural sequence. Use familiar T-SQL capabilities directly in Microsoft Fabric Data Warehouse. Conclusion These T-SQL language enhancements make everyday query development in Microsoft Fabric Data Warehouse more concise and expressive. Whether you are summarizing data, sorting wide result sets, filtering window-function results, or organizing complex query flows, the new syntax helps you focus on analytical intent instead of repetitive code. For syntax, supported options, and examples, refer to the documentation for QUALIFY, GROUP BY ALL, ORDER BY ALL, and FROM ... SELECT. As you evaluate these preview capabilities, share your scenarios and feedback with the Microsoft Fabric community on Reddit.New analytical functions in Microsoft Fabric Data Warehouse (Preview)
Microsoft Fabric Data Warehouse and the SQL analytics endpoint now support new analytical functions in preview. SQL developers and data professionals can calculate medians, quantiles, and percentiles with concise, maintainable T-SQL queries. What’s new in preview MEDIAN — returns the middle value in a dataset. QUANTILE — returns the value at a specified point in a distribution. APPROX_MEDIAN — estimates the median for large datasets. APPROX_QUANTILE — estimates a specified quantile for large datasets. PERCENTILE_CONT and PERCETILE_DISC — The existing PERCENTILE_CONT and PERCENTILE_DISC analytical functions now also support aggregate syntax, complementing their window forms for continuous and discrete percentile analysis. With these functions, you can calculate distribution metrics without writing multi-step workarounds. For example, you can compare a transaction with the median for its customer segment, identify quantile thresholds, summarize performance, and explore distributions across large datasets. The following query shows the four new functions and the enhanced aggregate syntax for PERCENTILE_CONT and PERCENTILE_DISC in a Fabric Data Warehouse T-SQL workload. distribution metrics in Fabric Data Warehouse. You can use each function as an aggregate to return one result for a dataset or group, or as a window function to add the analytical result to each row while preserving the result set. Why it matters These capabilities simplify common distribution analysis: Write shorter, easier-to-maintain analytical queries. Analyze data directly in the warehouse. Choose exact calculations when precision is the priority, or approximate calculations when you need faster results across large datasets. Use the same analytical patterns across Fabric Data Warehouse and the SQL analytics endpoint. Conclusion The new functions make it easier to perform common distribution analysis directly in Fabric Data Warehouse and the SQL analytics endpoint. You can choose exact calculations when precision is the priority or approximate calculations when faster results at scale are more important, then use aggregate or window syntax to fit the analysis. This reduces custom query logic and keeps statistical analysis close to the data. For syntax, supported options, and examples, refer to the Aggregate functions (Transact-SQL) documentation. As you evaluate the preview, share your scenarios and feedback in the Microsoft Fabric community on Reddit.
Advanced NL2SQL and advanced DAX generation in Fabric data agents (Generally Available)
Data agents in Microsoft Fabric let users ask questions about data in plain language. As a creator, you connect an agent to supported sources—including SQL databases, lakehouses, Power BI semantic models, and eventhouses—add the business context it needs, and share it with users across Fabric, Teams, Microsoft 365 Copilot, Copilot Studio, and Microsoft Foundry. The data agent can then respond like a domain expert that understands what your tables mean, how your metrics are defined, and which source can answer a question. The usefulness of a data agent ultimately depends on a simple question: can it translate what a user asks into the right query? That is harder than it sounds. Enterprise schemas are rarely intuitive. Several tables, columns, measures, or join paths may appear to answer the same question, so a query can be technically valid but still return the wrong result. Advanced NL2SQL and advanced DAX generation help address this problem by allowing the agent to explore the schema and data, validate assumptions, and refine its approach before generating a query. Both capabilities are available today, and we'll begin rolling the core improvements out to the standard runtime on November 2, with the rollout expected to complete by November 10. In this post, we'll look at how they work, what our internal benchmarks show, the new configurations available for shaping how the agent behaves, and what to consider as you re-test and evaluate your data agents. Why conversational analytics gets harder with enterprise data Turning a plain-language question into a correct query is a complicated problem, both for SQL and DAX, requiring the agent to resolve several challenges at once: Schemas are large. Enterprise sources can contain hundreds of tables, columns, and measures, and the names alone may not explain when or how they should be used. Business context exists outside the data. Definitions such as “revenue” or “active customer” often live in documentation, previous queries, or analysts’ knowledge rather than in the source schema. Filter values must match the way data is stored. Users describe concepts naturally, but those concepts must map to the values in the data. For example, a user may ask about “California” when the relevant column stores the value “CA.” Questions are ambiguous. More than one column, calculation, or join may appear to satisfy a request. Individually, each of these can be managed with enough hand-written guidance. The difficulty is that they compound: a single-pass generator has to resolve all of them at once — your schema, your definitions, your filter values — committing to an interpretation before it has any evidence that interpretation is right. When it guesses wrong, the query still runs, and the answer looks no different from a correct one. Advanced NL2SQL and advanced DAX generation are built around that problem. Rather than generating a single pass, the agent gathers evidence first. Advanced NL2SQL: the agent explores before it writes The shift is architectural. Instead of one-shot generation, the agent has sub-tools to explore schema, test joins, and look up real filter values before it writes SQL. Under the hood, you can inspect each step the agent took, and the assumptions and reasoning behind it. It operates in three modes, each backed by its own sub-tools: Mode What it does Example query following Finds a relevant example query and answers by making approved modifications, such as literal filter or parameter substitutions. Clarifying questions Determines it can’t answer reliably without more information and asks targeted clarifying questions before generating SQL. Data exploration When no example directly applies, learns from existing example queries to infer business logic, explores the data to validate assumptions, and iteratively refines its approach. What you get as a creator: Advanced NL2SQL explores the SQL source schema, tests joins, and looks up real filter values before generating SQL, helping it choose the appropriate tables, columns, relationships, and filters. Schema descriptions and topics that teach the agent what your data means, so you get better answers with fewer instructions. Better example-following and filter-value substitution for novel questions. Handles large schemas far better and runs faster end to end, with more reasoning detail for debugging. New configurations: schema descriptions and topics Two new configurations give the agent more of the context it needs. Both are available for SQL data sources on the preview runtime. Schema descriptions Schema descriptions attach business context to the objects in your data source — what a table holds, what a column represents, and how each should be used. The agent uses them to interpret large or ambiguous schemas and generate a more accurate query. They matter most where object names don’t carry meaning on their own, or where several tables and columns look interchangeable. Figure: Schema descriptions add business context to schema objects, helping the data agent interpret your data. Topics Topics help you give the agent detailed guidance without sending every instruction with every question. The agent searches your topic content and uses only the sections relevant to the current request. Use data source instructions for rules that must always apply, and use topics for deeper guidance that applies only to a specific subject. You can write topics in Markdown, import multiple files, and review the run steps to see which topics the agent selected. Figure: Topics organize subject-specific instructions in Markdown to guide the data agent’s query generation. Internal benchmark testing: Advanced NL2SQL on Preview Runtime vs NL2SQL on Standard Runtime Better reasoning matters only if it produces better answers without making users wait substantially longer. In an internal benchmark set evaluating answer quality and end-to-end latency, the preview runtime delivered the stronger outcome, answering more questions correctly than the standard runtime while reducing both median and tail latency. Smart-answer accuracy increased from 78.8% to 90.9%. Latency improved at the same time: P50: 28.4 seconds to 26.0 seconds P95: 46.8 seconds to 32.9 seconds Figure: Smart answer accuracy and end-to-end latency, standard runtime versus the Advanced NL2SQL preview, on an internal benchmark set. Accuracy rises 12.1 points to 90.9%, while P50 latency falls 8.3% and P95 falls 29.8%. *Performance results are based on Microsoft internal testing conducted in 2026 using an internal evaluation set comparing standard NL2SQL to the advanced NL2SQL preview in Microsoft Fabric. Actual results may vary depending on workload, data model, and configuration. The P95 result shows the largest latency improvement in this benchmark, with latency decreasing from 46.8 seconds to 32.9 seconds. This improvement is most relevant to the slower, more complex queries represented at the tail of the distribution. Advanced DAX generation: agentic reasoning over semantic models The agent calls tools, inspects results, and refines its approach to answer harder questions. Instance value indexing searches real column values, so filters match your data. And you get consistent results across Data Agent, Power BI, and M365 Copilot. For users, this means the agent is more likely to resolve filter terms to the values stored in the semantic model and return consistent answers across supported Microsoft experiences. Internal benchmark testing: Advanced DAX generation improves accuracy while cutting latency Our internal Advanced NL2DAX evaluation showed improvements in both answer accuracy and latency. Smart-answer accuracy increased from 89.15% to 91.86%. At the same time: P50 latency: 39.1 seconds to 20.4 seconds P95 latency: 97.5 seconds to 34.7 seconds This represents an approximately 48% reduction in P50 latency and a 64% reduction in P95 latency, along with a 2.7 percentage-point increase in smart-answer accuracy. *Performance results are based on Microsoft internal testing conducted in 2026 using an internal DAX generation evaluation set comparing the baseline to the advanced DAX generation preview in Microsoft Fabric. Actual results may vary depending on workload, semantic model, and configuration. Rolling out the runtime improvements We'll begin rolling the core Advanced NL2SQL and advanced DAX generation improvements out to the standard runtime on November 2, with the rollout expected to complete by November 10. As part of this rollout, the standard runtime will also move to GPT-5.6 Terra. As the rollout reaches your environment, data agents using the standard runtime will receive these improvements and the model upgrade by default, with no opt-in required. What is moving to the standard runtime: Advanced NL2SQL: improved example-query following, filter-value substitution, and data exploration. Advanced DAX generation: the agentic tool-calling loop and instance value indexing. Model upgrade: The standard runtime will move to GPT-5.6 Terra for orchestration and supported data agent capabilities. What stays in preview: Schema descriptions and topics for SQL sources. We believe these changes deliver significantly better results, based on improvements observed in our internal evaluations. However, results can vary by data source, model, instructions, examples, and workload. Creators can re-test and evaluate their agents on the standard runtime between November 2 and November 10 as the rollout reaches their environment, or try the changes now on the preview runtime. Moving from one-shot generation to an agent that explores data can change how existing instructions and examples are interpreted. We recommend re-testing: Run your existing question set against the standard runtime as the rollout reaches your environment between November 2 and November 10, or switch to the preview runtime to try the changes now. Rerun your evaluations with the Fabric data agent SDK and a ground-truth set. Compare the new results with your previous baseline, and use the visible reasoning steps to identify where the agent’s assumptions differ. Tune your example queries and instructions based on what the evaluation shows. The agent now explores your data and adapts examples through substitution, so guidance written to work around the previous behavior may no longer be needed. Re-testing and evaluating your agents will help you confirm the expected quality improvements for your own data and scenarios. Next steps If you build data agents in Microsoft Fabric, re-test your agents on the standard runtime as the rollout reaches your environment between November 2 and November 10, or try the changes now on the preview runtime. For more details: Fabric data agent runtime: Learn what the standard and preview runtimes each contain, how to switch between them, and what’s in the preview runtime today. SQL sources in Fabric data agent: Learn how NL2SQL and Advanced NL2SQL generate queries over Lakehouse, Data Warehouse, SQL Database and Mirrored Database sources, and which configurations each one can use. Semantic model best practices for data agent: Semantic model best practices for data agent: Learn about advanced DAX generation and how to prepare a semantic model so the agent can answer questions accurately.
My workspace governance improvements (Generally Available)
My workspace governance features, which give administrators governance controls over their users' personal My workspaces, are now generally available. As My workspaces continue to be used for business-critical content, organizations need governance capabilities that scale with their environment. These enhancements give administrators greater flexibility to access, manage, and recover content when needed, while enabling automation that reduces operational overhead and improves consistency across the tenant. These enhanced tenant administrator controls for My workspace are also available in government clouds. What's new Two new admin REST APIs make temporary admin access to a personal workspace fully programmable: Grant Admin Temporary Access: grants a Fabric administrator 24-hour access to a user's My workspace. Remove Admin Temporary Access: revokes that access before the 24-hour window ends. Both can be called by a Fabric administrator or by a service principal. The service principal identity must be enabled for Admin API access in your tenant settings. SPN support and these new APIs allow tenant administrators to automate management of tenant users’ My workspaces contents instead of doing it by hand in the Admin Portal. Reminder: Restoring orphaned My workspaces When a user is hard deleted in Microsoft Entra, their My workspace becomes orphaned and moves to a Deleted state, with contents retained for 30 days. During that window, you can restore it with the Restore Workspace API. Important: new workspace name is required when restoring a former My workspace, and you assign a new admin to own the recovered content. Try the Admin controls and new APIs and let us know what you think in the comment section.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.
