Ontology entities are not visible in Graph
I have a problem with some entities in my ontology. I created an ontology item and added some tables. Note this was still the old experience of the ontology item. I use it as a source for my Fabric Data Agent and it worked fine. (Reason for using the old version of the ontology is because the new version can't seem to be connected yet.) Now the problem comes. I added some more tables from a different lakehouse to the ontology later on. I can see the data of these tables in the ontology item when I look at instances. However, when I ask the Fabric Data Agent it can't seem to query those entities. When I look at the graph item that the ontology created I see that it only contains the tables that I added at the start, but not the ones that were added later. Does anybody have any idea how this could occur? I tried refreshing the Graph item but that doesn't seem to solve the problem.Fabric IQ: from booked hours to next year's forecast
You might remember that the first time you asked an AI agent about next year's project hours, it told you it could not predict the future. Fair enough. It had historical data, not a forecast. In this build, we gave it one. Fabric Plan generated monthly forecasts from booked hours. We wrote those values back to a database, connected them to the business entities in an ontology, and let a data agent answer questions about them. That distinction matters. Predict produced the numbers. The data agent retrieved and explained them. The interesting part was getting those pieces to agree on what "forecast" meant. We used synthetic planning, procurement and maintenance data. Forecasting connected the planning model, ontology and agents. Live telemetry and graph exploration showed where the other pieces fit, and where they did not. Disclaimer: These are notes from a hands-on lab built on synthetic data, and the findings are our own. Fabric IQ features and limits change quickly, so treat the Microsoft Learn and official documentations in the references as the authoritative source. Put a forecast behind the question The starting point was a planning semantic model with actual booked hours by project, discipline and month. In Fabric Plan, closed periods took those actuals. Open periods held editable forecast values. We used Predict [1] to populate the open periods from historical data. For monthly forecasting, the current guidance calls for at least 24 months of history; some algorithms need more. Our sample history went back to September 2023. The forecast was then written to a Fabric SQL database and exposed through a OneLake shortcut in the gold lakehouse. We added a ProjectForecast entity to the ontology, linked to Project and Discipline. The data agents could now reach the forecast as data rather than being asked to invent it. The question became: Which projects have the most forecast hours in 2027? That has a queryable answer: select the forecast scenario, filter the year, group the detail rows by project and rank the totals. Writing back the forecast did not automatically add it to the original semantic model. We had to expose that new table deliberately. This demonstrated the workflow, not forecast accuracy. The data was synthetic, and we did not backtest the forecast against held-out actuals. A correct answer about stored predictions is a different test from whether those predictions will be useful. Two forecasts, two different questions The first problem was not statistical. It was vocabulary. Our planning semantic model already had a measure called Forecast Hours At Completion. It estimated total hours at completion from baseline hours and earned-value progress. It was not a month-by-month prediction. Asked for the 2027 forecast, the agent initially chose that measure, applied a 2027 filter and found nothing. The measure name sounded right. The meaning was wrong. We made the distinction explicit in the agent instructions: Monthly, yearly and future-period forecasts use the Plan forecast table. Estimates at completion and overruns use the earned-value measures. An unqualified "forecast" means the Plan forecast in this application, and the answer must say so. After that change, the next-year question returned the expected project ranking. The useful check was not whether the answer sounded confident. It was whether the selected source, filters and totals matched the query we expected. The at-completion estimate also used the current activity snapshot. A date filter did not turn it into a historical estimate. That was another definition worth stating rather than leaving the agent to infer. The writeback table needs rules Our writeback contained more than a tidy list of future values. It included actuals, forecast values, subtotal rows and blank cells. That creates several ways to get a plausible but wrong total. Summing detail and All subtotal rows double-counts hours. Selecting the wrong value column mixes up actuals and forecasts. Treating every blank as zero changes the meaning of missing or unpopulated values. For this table, the query needed to: Select the intended scenario and Hours Forecast value column. Exclude All subtotal rows from project, discipline, year and month. Filter the requested period and aggregate at the required grain. Preserve the distinction between a blank and a recorded zero. Those rules can live in source instructions, but a curated view is easier to reuse when several consumers need the same result. Either way, the agent needs to know what a row means before it starts adding rows together. Ontology adds meaning, not missing data The ontology integration with data agents [2] is in preview. It supplies entities, relationships, definitions and source bindings. The data agent uses that context to choose a source and generate SQL, KQL or DAX; the underlying source executes the query. That separation explained one of our early failures. The agent could see only part of the lakehouse, and the forecast binding pointed elsewhere. Adding business context could not compensate for tables it could not reach. We had to check the actual source configuration and table selection. There was a less obvious problem too. An AI-assisted ontology edit added the forecast entity but repointed a shared connection to the plan database. Other entities still depended on that connection reaching the gold lakehouse. The ontology opened normally; the saved definition exposed the mistake. We corrected the connection and bound ProjectForecast to the shortcut in gold. The lesson was practical: after changing an ontology, inspect the saved bindings and rerun representative questions. A successful edit message is not enough. Shared business meaning belongs in the ontology. Source-specific query guidance belongs with the source. Keeping those responsibilities clear is more useful than repeating the same join rules in every agent prompt. Test the answers, including the expected ones We used the data agent evaluation SDK [3], also in preview, to run question sets and save the results. SQL queries computed expected answers from the sample data, and a grader compared them with the agent responses. That made instruction changes testable. It also exposed a mistake in our test: a planning question used a definition of baseline hours that did not match the semantic model. The apparent agent failure was a disagreement about the expected answer. Query-derived expectations still need review. They stay tied to the data, but a wrong join or business definition will produce the wrong benchmark very consistently. For an ontology comparison, keep the sources, permissions, questions, runtime and expected answers constant. Comparing an agent with access to the full lakehouse against one that can see only a few tables tells you little about the value of the ontology. We also kept answer checking separate from presentation. Inspect the query, result and any generated code, not just the final paragraph. Save the configuration with the run so a later score is comparable. More guidance when needed, analysis after the query Two preview features helped beyond basic question answering. Topics [4] let the agent retrieve relevant sections of longer guidance rather than send all of it with every question. They currently apply to SQL sources on the preview runtime. Rules that always apply still belong in source instructions; detailed definitions can be grouped into topics. The run steps show which topic was opened. The code interpreter [5] works on retrieved data in a sandboxed Python environment. In the procurement demo, it produced a chart of late deliveries by supplier quality rating. That was easier to read than a long answer listing percentages. It can also combine results from multiple sources for analysis. That is different from a database query joining those sources, and it still requires compatible keys and grain. We did not treat a chart of synthetic data as evidence that supplier ratings caused delivery performance. The generated Python and its inputs are part of the answer worth checking. Use the graph for relationships We also materialized part of the ontology as a graph: Supplier, PurchaseOrderLine, WorkOrder, Project and Installation. This made it possible to follow a supplier's order lines to projects and its contractor work orders to installations. It was a useful way to explore connections without writing each join. A connection alone did not prove that a supplier had delayed a project; that still required dates and status filters. The graph projection [6] is in preview and has its own eligibility rules. Our Equipment entity, which also carried Eventhouse telemetry, was not eligible. We kept live readings in the Real-Time Dashboard and operations agent rather than forcing them into the graph. Making the graph work also uncovered a compatibility problem. We changed relationship mappings and some entity keys. Afterwards, that ontology would no longer attach to the data agent, while a copy from before the changes still worked. We used the graph-ready copy for exploration and the earlier copy for the domain agent. We did not isolate which change caused the failure. This was a workaround for our build, not evidence that every solution needs two ontologies. From a sensor reading to a Teams recommendation The operations agent [7] covered a different job: watching a signal rather than waiting for a question. Our preview setup monitored simulated pump telemetry in an Eventhouse. Every five minutes it evaluated peak vibration and alerted when the value crossed above 5 mm/s. We observed the Teams recommendation and used Investigate further to explore the alert. This was a simulated bearing-wear scenario, not a validated fault diagnosis. The threshold identified a condition to investigate. The transition rule mattered. "Crosses above" is not the same as "is above." For a repeatable test, we first let the agent observe a below-threshold window, then introduced the fault. Restarting the stream or leaving an empty window did not guarantee a new crossing. We configured a Power Automate action with human approval, but did not complete end-to-end verification of the approved action's result. Its parameters were fixed for the demo pump, not dynamically mapped for every asset. The confirmed result was the alert and investigation, not an automatically created maintenance request. The client still matters Fabric IQ appearing in several clients does not mean each client can reach every Fabric item in the same way. Microsoft 365 Copilot Chat [8] can use Power BI reports and semantic models. The Copilot Cowork plugin [9] currently reaches semantic models through their reports; it does not directly ground answers in lakehouses, Eventhouses, ontologies or data agents. Existing Power BI permissions and row-level security apply. Publishing a Fabric data agent as a Microsoft 365 agent is a separate integration path [10]. It should not be confused with the Power BI connection. We used Prep data for AI [11], which is in preview, for model-level AI instructions and schema selection. We also covered verified answers for recurring questions. Preparing the model does not make the separate forecast table available to a client that cannot query it. Before choosing a client, check which source it can reach and how the answer is produced. The Fabric IQ name alone does not settle that. What changed We started with an agent that could answer questions about recorded work. We ended with one that could also answer questions about a stored forecast. The change was not a more ambitious prompt. It was a forecast with a defined grain, an accessible table, business context and explicit routing between two different meanings of the same word. That is the useful part of this Fabric IQ build: planning produces values that can be queried alongside operational data. The forecast still needs validation, and the answer still needs checking. But "next year" no longer has to mean "there is no data." Try it yourself: sample data, semantic models and data agent setup on GitHub References (Microsoft Learn, accessed 16 October 2026) [1] Predict forecasts: https://learn.microsoft.com/fabric/iq/plan/planning-forecasting/planning-how-to-generate-statistical-forecasts-using-predict-feature [2] Ontology in a data agent: https://learn.microsoft.com/fabric/data-science/data-agent-ontology-sources [3] Evaluate a data agent: https://learn.microsoft.com/fabric/data-science/evaluate-data-agent [4] Data agent topics: https://learn.microsoft.com/fabric/data-science/data-agent-topics [5] Code interpreter: https://learn.microsoft.com/fabric/data-science/data-agent-code-interpreter [6] Ontology graph: https://learn.microsoft.com/fabric/iq/ontology/how-to-use-ontology-graph [7] Operations agent: https://learn.microsoft.com/fabric/real-time-intelligence/operations-agent [8] Fabric IQ in Copilot Chat: https://learn.microsoft.com/fabric/iq/connectors/microsoft-365-copilot-overview [9] Fabric IQ in Copilot Cowork: https://learn.microsoft.com/fabric/iq/connectors/cowork-overview [10] Data agent in Microsoft 365 Copilot: https://learn.microsoft.com/fabric/data-science/data-agent-microsoft-365-copilot [11] Prep data for AI: https://learn.microsoft.com/power-bi/create-reports/copilot-prepare-data-ai
Production-grade Fabric data agents: moving from Demo to Dependable
Getting a Fabric data agent to work in a demo is one thing. Supporting it once people depend on it is another. Using the Lakeshore Retail demo, this guide covers the practical work behind that transition: reliable data, ontology context, secure access, performance testing, guardrails, and day-two operations. Tutorial data - Lakeshore Retail. The inventory is a CSV reference, not an agent answer; benchmarks are proposed, not measured. 1. Define the service before tuning the prompt Start with verifiable questions: inventory below safety stock, inbound shipments, governed sales measures, and refrigeration readings over a defined window. Agree on definitions, units, time zone, snapshot selection, freshness, and an answer owner. Low stock is not a shortage forecast. Two high-temperature readings do not prove a continuous breach: cadence, gaps, quality, and boundaries matter. Store-level relationships do not identify which product occupied a refrigeration unit. Put durable calculations in governed measures, SQL, or KQL. Ordering and other write actions need separate authorization and approval. Figure 1. Reference design; guardrails do not replace authorization. Use the standard runtime for production. Ontology, preview runtime, Foundry integrations/agent guardrails, evaluation SDK, and data-agent source control have separate preview considerations. The core's GA status does not extend to every dependency. 2. Use ontology for meaning, not as a security boundary LakeshoreOntology is now attached to the LakeshoreDataAgent draft, with Standard selected. It supplies entities, relationships, and mappings. SQL, KQL, or DAX executes against underlying sources under user permissions. Figure 2. Tutorial ontology, not proof of query correctness. The integration is preview. Attachment here does not confirm a service-wide fix to the documented new-experience issue. Keep shared definitions in the ontology. Explicitly mount eligible underlying sources before adding source-specific instructions, descriptions, or examples. These settings do not write back to the ontology. 3. Establish one reference answer For the fixed 2026-08-28T18:50:00Z snapshot, select positions where: LocationType = STORE StorageClass = FROZEN OnHandQuantity < SafetyStockQuantity The 48-position inventory fixture has exactly three matches, all Vanilla Bean Ice Cream (P-FRZ-001): Figure 3. A calculation from tutorial files, not a live agent result. For test INV-001, assert exact Store/Product keys, count, quantities, filters, and timestamp, not just three city names. The fixture's InventoryStatus = 1 marks low stock; sample instructions call it healthy. Resolve this first; the reference uses quantities. Do not silently alter data or treat August as current. 4. Prepare and wire the sources Curate objects without losing keys, joins, dates, or measures. Smaller is not automatically better. Use governed Power BI measures, Prep for AI, and Verified Answers. DAX generation uses model metadata and Prep for AI, not agent instructions. SQL/KQL source instructions/examples are separate. AI scoping and hidden fields are not authorization. Column flags do not narrow a selected source table; use supported model configuration or curated objects, not destructive edits to shared models. In development: Check prerequisites: supported paid F2+/P1+ capacity, tenant settings, and same-region agent/source capacities. Use Sources > Add sources > Add an ontology to attach LakeshoreOntology. Review its entities and Ontology data sources. Mount eligible sources for SQL/KQL configuration; prepare the semantic model separately. Set routing, clarification, and response rules, including units, identifiers, and honest failures. Inspect the fixed inventory question's source, generated query, and result. Publish to a restricted test audience; repeat as real consumers. Figure 4. The supplied attached-source draft. It does not establish query, security, or performance success. Validate the published version; republish runtime changes. Standard does not freeze service-managed LLM upgrades. Model Read permits semantic-model queries; authoring needs broader rights. 5. Benchmark the whole request Schema width and preview runtime are experiments, not guaranteed gains. Measure authentication, planning, query generation, source execution, response generation, and wrapper/guardrail work. Fast engine execution does not establish that capacity will fix conversation latency. Figure 5. Proposed experiments, not benchmark results. Vary one factor before combinations: Import, Direct Lake, and DirectQuery have no universal speed ranking. Filter telemetry early. Advanced DAX value indexing currently needs Q&A enabled. Fix questions, data, identities, and versions. Separate new chats/follow-ups and cold/warm runs; interleave baseline/candidates. Never clear shared production caches for a test. Use approved synthetic load with representative volume, cardinality, skew, joins, and freshness; tutorial data cannot prove sizing. Record sample size, p50/p95, timeouts, failures, throttles, correctness, and resources. Count all attempted eligible requests when reporting correct completion within budget, including timeouts. Leave caching off until permission-aware keys, freshness, expiration, and revocation invalidation are proven. 6. Add Foundry without moving the authorization boundary A prompt/hosted agent can use Fabric for orchestration, safety, and escalation, not repair measures, grant access, or replace Fabric's query-generation model. Use defense in depth: Application: authenticate, allowlist tools/arguments, bound calls/concurrency/deadlines, and validate available structured results. Foundry: supported safety controls and orchestration. Fabric and sources: enforce the identity's permissions. Data/semantic layers: business meaning. Use delegated end-user identity for interactive access; test two differently entitled consumers through the whole route. Never silently use the owner's identity. The Fabric tool and Fabric IQ integration differ; the former requires the same tenant. Deployment-principal support does not establish query-principal support. The public published-agent MCP pattern is: https://api.fabric.microsoft.com/v1/mcp/workspaces/{workspaceId}/dataagents/{dataAgentId}/agent Verify OAuth, consent, and networking; private-link routes may need workspace-specific hosts. Keep tokens out of code/logs. Moderation is route-specific, not automatic for arbitrary MCP bridges or nested calls. Test input, tool calls, retrieved content, and output on your route. Safety approval does not prove accuracy or authorization. For hosted guardrails, prove filtering with negative tests. invocations needs invocations_moderation; invocations_ws has no content-safety moderation. Agent-level groundedness/spotlighting are unsupported. Implement and test any missing required control, or block release. Review Code Interpreter/action tools for isolation, retention, and approval. Exclude preview dependencies if policy requires it. 7. Test behavior, not convincing prose Use approved references and holdouts separate from tuning. Assert numbers, dates, filters, and authorized scope deterministically. Test ambiguity, no data, outages, expired identities, follow-up filters, threshold boundaries, gaps, injection, denied fields, and cross-user isolation. Check totals/errors for disclosures too. Test consumers: workspace Admin, Member, and Contributor bypass RLS. Admin success is not an RLS pass. The conversational cap is 25 rows by 25 columns. Compute totals in the source, not from truncated output; offer an authorized report/export route for complete datasets. The preview evaluation SDK uses question/expected_answer columns and a published target. Review detailed steps alongside assertions. Judge scores cannot override failed access checks. Example targets: all critical cases pass; broader correctness >=95%; no disclosures observed in the negative suite; 95% of attempted eligible requests correct within 30 seconds at five concurrent users. These are proposals, not measurements or guarantees. 8. Release a service someone can operate Figure 6. Proposed release gates, not an existing pipeline. Separate dev/test/prod. Version configurations, ontology/models, AI preparation, examples, policies, code, and evaluations. Data-agent source control is preview. Verify target bindings, permissions, region, and freshness. Publish and smoke-test consumers before expanding access. Practice rollback to a known-good release; it does not necessarily restore data, permissions, tools, or the service-managed model. Regress after service changes. Assign business, data, application, security, and operations owners. Monitor outcomes, p95, throttling, freshness, quality, and cost with correlation IDs/versions. Restrict trace access and retention; never log tokens or unrestricted results. Bound transient retries, honor Retry-After, and never retry denials as outages. Add deadlines, circuit breakers, and escalation. Distinguish no matches, no access, and failed queries. Review compliance/geographic boundaries for Foundry, external services, logs, and exports. Fabric's up-to-28-day history retention does not define external retention. Respect Purview/source policies. AI consumption includes instructions, examples, and history; source queries consume separately. Monitor AI Query and engines, budget Foundry/application costs, and compare cost per correct, authorized answer within target. Require evidence for scope, data quality, published bindings, consumer access, correctness, guardrails, load, rollback, ownership, and honest failures. Missing evidence blocks release. Dependable means useful within scope and supportable when things change.Ontology entities are not visible in Graph
I have a problem with some entities in my ontology. I created an ontology item and added some tables. Note this was still the old experience of the ontology item. I use it as a source for my Fabric Data Agent and it worked fine. (Reason for using the old version of the ontology is because the new version can't seem to be connected yet.) Now the problem comes. I added some more tables from a different lakehouse to the ontology later on. I can see the data of these tables in the ontology item when I look at instances. However, when I ask the Fabric Data Agent it can't seem to query those entities. When I look at the graph item that the ontology created I see that it only contains the tables that I added at the start, but not the ones that were added later. Does anybody have any idea how this could occur? I tried refreshing the Graph item but that doesn't seem to solve the problem.
Ontology New Experience: Data Agent and Graph Materialization Issues
Hello, I am currently evaluating the Fabric Ontology new experience (Generation 2, Preview) and have encountered three issues. I would like to confirm whether these are known limitations of the current Preview or unexpected issues. Environment: Microsoft Fabric capacity: F2 Ontology: New experience (Generation 2, Preview) Data sources: Lakehouse and Eventhouse Unable to add an Ontology to Fabric Data Agent When I try to add an Ontology created with the new experience as a data source to a Fabric Data Agent, the operation fails with the following error: Error occurred while adding datasource. Failed to fetch schema for the data source. To isolate the issue, I simplified the Ontology to contain only a single Shop entity and removed all Decimal properties and time-series bindings. Graph materialization completes successfully with this configuration, but adding the same Ontology to the Data Agent still fails. In the same environment, an Ontology created with the old experience (Generation 1) can be added to the Data Agent successfully. Therefore, the Data Agent issue does not appear to be caused by a Graph materialization failure. Graph materialization fails when a Decimal property exists When an entity contains a Decimal property, Graph materialization fails with HTTP 400. In my test, the Shop entity contained the following property: Property: FloorAreaM2 Type: Decimal The following error occurs: FeatureNotImplemented: DECIMAL(P,S) graph properties are not enabled. After removing the FloorAreaM2 property from the Ontology, Graph materialization completes successfully. I would like to confirm whether Decimal properties are currently unsupported for Graph materialization in the Ontology new experience. Graph materialization fails when a time-series binding exists Graph materialization also fails when a time-series binding is added to an entity. To isolate the issue, I reduced the time-series binding to only one property: Entity: Shop Source: TS_SalesHeader (Eventhouse) Property: SalesId Property type: Time series (Integer) Timestamp: SalesDateTime Even with only this single Integer time-series property, Graph materialization fails with HTTP 400. The following error occurs: ModelValidationError: InvalidPropertyType GraphType: Property type INVALID for property SalesId is invalid. If I remove the time-series binding from the same Ontology, Graph materialization completes successfully. I also tested additional time-series properties, and Graph materialization failed regardless of their underlying data types. Therefore, this does not appear to be an issue specific to Decimal properties. Could you please clarify the following? Is the Fabric Ontology new experience (Generation 2, Preview) currently supported as a data source for Fabric Data Agent? Are Decimal properties currently supported when materializing an Ontology to Graph? Are time-series bindings currently supported when materializing an Ontology to Graph? If these scenarios are supported, are these known issues with the current Preview? Are there any known workarounds or planned fixes? Thank you.Ontology New Experience: Data Agent and Graph Materialization Issues
Hello, I am currently evaluating the Fabric Ontology new experience (Generation 2, Preview), and I have encountered the following three issues. I would like to confirm whether these behaviors are known limitations of the current Preview or unexpected issues. Environment Microsoft Fabric capacity: F2 Ontology: New experience (Generation 2, Preview) Data sources: Lakehouse and Eventhouse 1. Unable to add an Ontology to Fabric Data Agent When I try to add an Ontology created with the new experience as a data source to a Fabric Data Agent, the operation fails with the following error: Error occurred while adding datasource. Failed to fetch schema for the data source. To isolate the issue, I simplified the Ontology to contain only a single Shop entity and removed all Decimal properties and time-series bindings. With this minimal configuration, Graph materialization completes successfully. However, adding the same Ontology to the Data Agent still fails with "Failed to fetch schema for the data source. In the same environment, an Ontology created with the old experience (Generation 1) can be added to the Data Agent successfully. Therefore, the Data Agent issue does not appear to be caused by a Graph materialization failure. 2. Graph materialization fails when a Decimal property exists When an entity contains a Decimal property, Graph materialization fails with HTTP 400. For example, my Shop entity contained the following property: Property: FloorAreaM2 Type: Decimal Graph materialization failed with the following error: FeatureNotImplemented: DECIMAL(P,S) graph properties are not enabled. After removing the FloorAreaM2 property from the Ontology, Graph materialization completed successfully. I would like to confirm whether Decimal properties are currently unsupported for Graph materialization in the Ontology new experience. 3. Graph materialization fails when a time-series binding exists Graph materialization also fails when I add a time-series binding to an entity. To isolate this issue, I reduced the time-series binding to only one property: Entity: Shop Source: TS_SalesHeader (Eventhouse) Property: SalesId Property type: Time series (Integer) Timestamp: SalesDateTime Even with only this single Integer time-series property, Graph materialization fails with HTTP 400: ModelValidationError: [InvalidPropertyType] GraphType: Property type INVALID for property SalesId is invalid. If I remove the time-series binding from the same Ontology, Graph materialization completes successfully. I also tested additional time-series properties, and the properties were reported as GraphType INVALID regardless of their underlying data types. Therefore, this does not appear to be an issue specific to Decimal properties. Could you please clarify the following? Is the Fabric Ontology new experience (Generation 2, Preview) currently supported as a data source for Fabric Data Agent? Are Decimal properties currently supported when materializing an Ontology to Graph? Are time-series bindings currently supported when materializing an Ontology to Graph? If these scenarios are supported, are these known issues with the current Preview? Are there any known workarounds or planned fixes? Summary of test results Ontology Generation 1 -> Data Agent: Success Ontology new experience with only a single entity and static data binding, with no Decimal properties or time-series bindings -> Graph materialization: Success Same Ontology -> Data Agent: Failed ("Failed to fetch schema for the data source.") Ontology new experience with a Decimal property -> Graph materialization: Failed ("DECIMAL(P,S) graph properties are not enabled.") Ontology new experience with one Time series (Integer) property -> Graph materialization: Failed ("GraphType: Property type INVALID for property SalesId is invalid.")
Fabric Data Agent on Ontology Fails for Simple and Multi‑Entity Queries (GROUP BY/Aggregation Error)
Hi, I’ve created a Fabric Data Agent using an Ontology as the data source, and I’m encountering consistent failures even when asking simple questions related to a single entity. Queries that span or join multiple entities also fail. Below are the details and the error output. Issue Summary When I ask a basic question (even involving only one entity), the agent returns an error. For multi-entity questions, it fails with the same pattern. The error indicates that the generated Ontology query includes invalid aggregation or grouping logic. Specifically, a field is referenced without being part of the GROUP BY clause or wrapped in an aggregation function. The underlying generated query seems to have a syntax or grouping issue and cannot execute. Query Output: Failed to execute step (RAID: 36eb1c04-9e56-4998-89ac-a9a56919482d). Error: Failed to execute Ontology query with error: "The query is invalid. Reason: BadRequest. Resource: Graph query (graphModelId=9231e6f0-87b9-44b4-9a36-5ddbe39b8d78). InternalCode: 42000. Message: syntax error or access rule violation. Cause: data exception; The identifier node_production_plant.plant_id cannot be used, as it is neither part of the GROUP BY nor an aggregation." I have already enabled "Support GROUP BY in GQL" in the Data Agent instructions. What I need help with: Has anyone seen similar Ontology-based Data Agent failures related to GROUP BY or aggregation? Is this a known limitation or bug when using Fabric Data Agent on Ontology models? Any best practices or modeling patterns to avoid such query-generation errors? Are there known workarounds to ensure the agent produces valid Ontology queries? I can share more examples or screenshots if needed. Thanks in advance for any guidance!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.
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.
