How can AI agents improve decision-making with Microsoft Fabric IQ?
I am exploring how AI agents can work with modern data platforms to help businesses move from traditional reporting toward proactive decision-making. Some possible use cases: AI agents analyzing business data and identifying important trends Automatically generating insights from Fabric data models Triggering workflows based on detected patterns or anomalies Helping teams interact with enterprise data using natural language Combining AI reasoning with governed data sources I would like to understand how the community is approaching AI-powered analytics with Microsoft Fabric IQ. Are teams using AI agents, Copilot experiences, or custom automation workflows on top of Fabric data solutions? What architecture patterns and best practices have you found useful?
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.
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 .
