Data Agent fails to query Ontology
Hello, I’m experiencing an error when using the Data Agent in Microsoft Fabric to query my Ontology. Even when I ask very simple questions, the Data Agent fails every time with the following error: Failed to execute step (RAID: "GUID"). Error: Failed to generate NL2Ontology query with error "{"code":"InternalError","subCode":0,"message":"An internal error occurred.","timeStamp":"2026-04-20T13:00:42.7677176Z","httpStatusCode":500,"hresult":-2147467259,"details":[{"code":"RootActivityId","message":"GUID"},{"code":"Param1","message":"Failed to translate NL query to ontology query."}]}" This was working correctly until last week, but for the past four days it has consistently failed with the error above, without any changes on my side. The Data Agent works perfectly when querying: a Lakehouse (NL2SQL), and a Semantic Model (NL2DAX). The issue occurs only when the Ontology is used as the data source. Also I have "Support GROUP BY in GQL" inside the data agent's instructions. Could someone please help me understand what might have changed recently or how to troubleshoot this issue? Thank you in advance.
Ontology on top of Semantic Model
- Region: West Europe (confirm your exact region) Warehouse not available as a data binding source. When I open an Ontology entity (e.g. "Customer") and go to "Manage property bindings" -> "Add data binding", the only options shown are: - Lakehouse table - Eventhouse table or materialized view There is no option to bind directly to a Fabric Warehouse table, even though my semantic model (and the entities generated from it) are based entirely on Warehouse tables, as part of my gold layer. This leaves all properties stuck as "Unbound" and blocks relationship creation with the error: "One or more entity types are missing a non-timeseries binding." Question: Is native Warehouse binding on the roadmap for Ontology, and if so, what is the expected timeline (preview/GA)? Or how is it managed by others. If not I have to create a short cut to lake house from my warehouse, which was created/modeled from my lake house tables :). Doesn't look like a efficient architecture.Ontology: cannot add properties to relationship types
Hi all, I've been building a knowledge-graph project using Fabric's Graph and Ontology (preview), and ran into a limitation: Ontology currently lets you define properties on entity types, but not on relationship types. (I even tried adding edge properties directly on the underlying Graph of the Ontology, not just through the Ontology definition, but that didn't work either. But if I do it just on a Graph which is not tied to an Ontology, everything works.) I'd really like to keep using Ontology specifically, not just fall back to a plain Graph without Ontology. So I'm hoping to understand if this is fixable rather than being told to skip Ontology altogether. A few questions: 1. Is this a known/tracked limitation? 2. Is there a fix planned for it? 3. Is there a recommended way to model relationship properties in the meantime? I'm planning to talk about my project publicly, so I'd like to understand if this is expected to change soon or if I should plan around it. Thanks for any info you can share.
Unable to add Ontology as a Data Source in Fabric Data Agent (Japan West Region)
I am experiencing an issue where I cannot add an Ontology item as a data source to a Fabric Data Agent. Environment: Region: Japan West Capacity: F2 (Paid) Items: Ontology (preview), Fabric Data Agent Steps to reproduce: Create an Ontology item with entity types and data bindings (Lakehouse). Wait for Graph child artifact initialization to complete. Create a new Fabric Data Agent. Attempt to add the Ontology as a data source. Error message appears: "Couldn't add data source" What works: Adding a Lakehouse directly as a data source works without any issues. All required tenant settings are enabled (Ontology preview, Copilot and Azure OpenAI, cross-geo processing, etc.) Copilot capacity is configured correctly. What fails: Adding an Ontology item as a data source always fails. Error details retrieved from browser DevTools (Network tab): The POST request to the datasources endpoint returns HTTP 202 Accepted. Following the Location header returns the following error response: xmlCopy <TridentPublicApiErrorResponse> <errorCode>RequestFailed</errorCode> <message>Unable to process the request</message> <requestId>XXXX</requestId> <isRetriable>false</isRetriable> </TridentPublicApiErrorResponse> Suspected cause: The Fabric IQ Ontology and Data Agent integration may not be fully supported in the Japan West region at the backend level, as the API returns isRetriable: false, indicating this is not a transient error. Request: Please investigate whether the Ontology-to-Data-Agent integration is supported in the Japan West region, and advise on any workaround or expected timeline for support.Fabric Data Agent: “Query cancelled” on aggregations
Good evening, I’m trying to build a Data Agent for my organization, even though the feature is still in preview. Its source is an ontology. I’m currently working with only six tables, but they are very large. I’m having an issue when asking the Data Agent questions that require grouping and aggregation, such as COUNT or SUM. In those cases, I often get the following error: "Query cancelled by upstream caller Status Code: Cancelled" The agent suggests that this may be caused by the amount of resources required by the query, which seems plausible. I also tried using smaller tables in the ontology. This improved things somewhat, and some queries now work, but aggregations are still extremely slow and I still frequently receive the same error. Is this expected behavior with large ontologies and aggregation queries, or could there be some configuration or setting that needs to be changed? Is there anything I can do to improve the performance of GROUP BY, COUNT, and SUM queries over an ontology-backed Data Agent? EDIT: I also found the following error in one of the question's execution log: 'The request was canceled due to the configured HttpClient.Timeout of 300 seconds elapsing.'Microsoft Fabric Data Agent – HttpClient.Timeout after 300 seconds: where is it configured?
Hi everyone, this post is a follow-up to a previous discussion I opened about Fabric Data Agent queries being cancelled during aggregations: https://community.fabric.microsoft.com/t5/IQ/Fabric-Data-Agent-Query-cancelled-on-aggregations/td-p/5357096 After further testing, I believe I have isolated the issue more clearly, so I am opening a new post with a more specific title and description. The goal is also to make the issue easier to find for anyone searching for HttpClient.Timeout, 300 seconds, or Microsoft Fabric Data Agent timeout problems. The main issue is the following: Some Microsoft Fabric Data Agent requests fail after approximately 300 seconds because of HttpClient.Timeout. I am using a Fabric Data Agent with a Microsoft Fabric Ontology as its data source. The problem mainly appears on expensive queries, especially aggregations and queries involving larger portions of the ontology. However, further experiments suggest that this is not simply a query-performance or capacity issue. I have different Data Agents using the same underlying Ontology. One agent can execute queries for much longer than 5 minutes, in some cases close to 20 minutes. Another agent consistently fails after approximately 5 minutes with an HttpClient.Timeout. Fabric Capacity does not appear to be close to saturation when the timeout occurs. Individual entities can be queried correctly. This makes the fixed approximately 300-second behavior particularly confusing. The question I am now trying to answer is very specific: Which component in the Microsoft Fabric Data Agent architecture is enforcing this HttpClient.Timeout? For example, is the timeout defined in: the Data Agent orchestration layer, the MCP server associated with the published Data Agent, an internal Fabric service calling the ontology or graph engine, the client consuming the agent, or another intermediate HTTP layer? And, most importantly: Is this 300-second HttpClient.Timeout configurable anywhere? I have found other timeout-related settings in the surrounding architecture, but I have not found documentation identifying a setting that clearly corresponds to this specific timeout. There is also another important behavior that I would like to understand. If the published Data Agent is consumed programmatically, for example from a notebook or through its MCP endpoint, does the same 300-second HttpClient.Timeout still apply? Or does that use a different execution path with different timeout constraints? At this point I am specifically trying to identify the architectural source of the timeout rather than optimize the generated GQL query. The most useful clarification would therefore be: Where exactly is the 300-second HttpClient.Timeout enforced, and is there any supported way to configure it or use an execution path that does not have the same limit? This is related to my previous thread about query cancellation during aggregations, but the additional tests seem to narrow the issue down specifically to the HTTP timeout layer.RLS not working in Fabric Plan, but works in the Power BI report
Hi, I have a semantic model in a Premium Capacity Workspace in Fabric where I'm just starting practicing how to build a Plan in Fabric. I created roles and assigned to users - I'm using my developer account and assigning to the users provided there -. The user Alex Wilber has Viewer role in the Workspace, is a member of the role for NA for RLS, and still can see all regions in the Plan, eventhough cannot see them in the Power BI report, there the RLS works just fine. Thanks in advance for your help! Cheers, FernandoFabric Plan writeback where dates and values have NULL
Hello, I finished my first exercise with Fabric Plan with a Planning Sheet where I forcasted 2026 based on the historical data from previous year in the semantic model with fake data, actually the semantic model demo provided by Lumel, called "transaction-dataset". I created a Fabric SQL Database and the corresponding connections to writeback the final Forecast. I clicked the Writeback button, finished, then went to the SQL Database and found the new table with data from the Forecast except for Year, Quarter, Month and Value, they all have NULL. Am I missing any configuration? Any help is greatly appreciated. Thanks, Fernando
