Using Data Agents for NL to KQL/GQL generation
Hi Team, I have a graph model and an eventhouse attached to a data agent and only want it to generate the correct KQL/GQL queries based on my natural language question, grounded in the schema object descriptions and example queries I've given for these sources. Is there a way I can get the data agent to emit just the query but not execute it? My use-case in NL to Code generation rather than execution and summarization. I tried fine tuning the agent instructions a bit, but I couldn't get the data agent to stop after the nl2code tool call, it ends up also executing the query every time. Kindly assist if someone has an idea. PS - I'm aware that Fabric has a real-time intelligence API for NL to KQL generation, but that is insufficient for us because we wanted both GQL and KQL support. Additionally, the RTI API only grounds itself in few-shot examples, unlike the data agent which has an advanced level of grounding using the schema object descriptions, etc. Therefore, I was more curious if this can be done using the data agent itself.
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.
Fabric Data Agent chat error: “The natural language query could not be processed” (Ontology source)
Hi all, I’m having a persistent issue with Fabric Data Agent when using an Ontology as the data source. In the chat, even very simple natural language questions fail with: “The request is invalid. The natural language query could not be processed. Please rephrase your query and try again.” RAID examples: db24d651-d4f8-4dd9-8fcb-bab105ee68eb, bfb8cd2a-676a-40a0-9c91-f36ca250ff07. What I already validated: Ontology and graph are created correctly. Relationships exist and are active. Manual graph queries execute successfully. The issue happens in chat NL queries (NL-to-GQL translation), even with minimal prompts. I recreated the Data Agent from scratch, same behavior. So this looks like a chat/NL parser issue rather than a data or graph execution issue. Has anyone found a reliable workaround, or is this a known service-side issue in preview? Any guidance from Microsoft team would be very helpful. Thanks!Build Business-Aware AI Agents
AI is only as good as the context it receives. Join Ahmed Salih and Aala Omer Taha for an in-person session exploring how Microsoft is enabling Business-Aware AI Agents through Microsoft IQ Platform, Fabric IQ, Data Agents, Semantic Models, Ontologies, Dataverse, Business Skills, and Copilot Studio. Learn how organizations can move from simply storing and analyzing data to building agents that understand business context, reason over trusted business knowledge, and help users take action. Store → See → Understand → Act Date: June 13, 2026 Time: 2:00 PM – 5:00 PM Venue: Espaces - Mohi Al Din, Dokki, Giza Seats are limited, so register early and join us on this exciting journey into the future of Business-Aware AI. Registration: Cairo In-Person Session Registration Copilot-Fabric IQ: Build Business-Aware AI AgentA Typo when collapsed left pane in the Graph (Korean)
Hi Team, When I collapsed left-hand components pane in the Graph, I noticed the title was displayed upside down. That should be rotated as follows: Do you have any other thoughts? I will submit a support ticket to support engineer team. https://learn.microsoft.com/en-us/power-bi/support/create-support-ticket Korean English Thanks, HongLet Fabric Data Agent ontology inherit RLS from Semantic Model roles instead of OneLake Security
I'm building a Fabric Data Agent with an ontology on top of a Lakehouse (Customer 360 style model — dimension and fact tables). I also have a Power BI semantic model over the same data with a DAX RLS role already defined (e.g., restricting a "Germany" role to rows for that region). I expected the ontology/Data Agent to honor that semantic model role when a user with the role queries it. Instead, I found that the ontology queries the Lakehouse directly via a graph engine (GQL), and semantic model DAX RLS only applies within the scope of that semantic model — it has no effect on the ontology path. The only way to get row-level filtering enforced there is OneLake Security (data access roles), which requires defining access — including RLS predicates — separately, per table/folder, in the "Manage OneLake security" experience. The problem: This means the same business rule ("this role sees only Germany rows") has to be defined and maintained twice, in two different places, using two different mechanisms: Once as a DAX RLS role in the semantic model (for Power BI reports) Once as OneLake Security data access roles, configured per table, for the ontology/Data Agent path For a model with many related tables (dimensions + facts), this means recreating the same predicate across every table individually in OneLake Security, rather than defining the rule once at the role level and having it apply consistently across all related tables — the way a single semantic model role does. What I'd like to see: I'd prefer that semantic model roles (and their RLS/CLS definitions) can be inherited by, or reused in, the ontology — so one role definition governs both the semantic model and the Data Agent/ontology layer, instead of maintaining a parallel, per-table configuration in OneLake Security. Today it feels like there's no single source of truth for "who sees what" when a Lakehouse is consumed through multiple paths (Power BI vs. Data Agent). Questions for the community/product team: Is there a supported way today to have the ontology consume a semantic model as its data source (rather than Lakehouse tables directly), so DAX RLS is respected end-to-end? Is unifying RLS definition across semantic model and OneLake Security on the roadmap, or is the expectation that these stay as two independently maintained layers? If OneLake Security is meant to be the single enforcement layer going forward, is there a way to define a role once and have it apply across a set of related tables (dimensions + facts) rather than configuring RLS per table? Any guidance — or confirmation this is a known gap — would be appreciated. My Goal is to achieve RLS for Data Agents without having to define rules for each Table which what the Role DAX in Semantic Model offer .A Typo regarding Edge in the graph model (Korean)
Hi Team, When I tried to create a graph model, I noticed a typo about Edge in the left pane: “가장자리”. In the top toolbar, it is displayed as “에지”(Edge). So, that should be “에지”. I will submit a support ticket to support engineer team. https://learn.microsoft.com/en-us/power-bi/support/create-support-ticket Korean English Thanks, Hong
Data Agent gives correct GQL Query but is unable to give output
Hi All, I have a Data Agent connected to a Graph data source that keeps giving error: I'm unable to directly retrieve the data due to a technical issue translating the request to a graph query. However, here is the correct GQL query you can use to get .... The GQL query provided by the Data Agent works perfectly on the Graph instance but the Data Agent is not giving the output. Not sure what is the exact error and where can I see to troubleshoot it. Both Data Agent and Graph are in same workspace (even same folder for that matter).
