Turn Data Agent User Feedback Into Reusable Evaluation Test Cases
Fabric Data Agents can now capture feedback from consumers. This is valuable, but reviewing feedback manually does not create a repeatable quality assurance process. Please allow Data Agent owners to convert a user question, incorrect answer, or negative feedback item directly into a reusable evaluation test case. The test case should store the original question, expected data source, expected measures or fields, expected query behavior, expected answer criteria, and optional reviewer notes. Creators should be able to maintain a library of these tests and run the complete evaluation suite before publishing changes to agent instructions, semantic model configuration, query templates, ontology context, or other agent settings. Fabric should compare results between the current and proposed agent versions and highlight Pass, Fail, Improved, and Regressed results. This would turn real production feedback into a continuous improvement and regression testing process for Fabric Data Agents.Built a free tool to inventory & risk-rate legacy SSIS packages before a Fabric migration
Hi all, Sharing something I built that might save some of you the painful "open every .dtsx in SSDT one by one" phase of an SSIS → Fabric migration. The problem it addresses: most teams sitting on a legacy SSIS estate have dozens to hundreds of undocumented packages and no clear starting point. Before any actual migration work, someone has to answer: what does each package do, which components map cleanly to Fabric, and which need a full rewrite? What it does: Parses .dtsx package XML and extracts control flow tasks, data flow components, connection managers, variables, and precedence logic Maps each component against a Fabric equivalent — Data Flow Task → Dataflow Gen2, Execute SQL Task → Script/Stored Procedure Activity, Script Task → Notebook Activity, Foreach Loop → ForEach Activity, and so on Gives each package a Low/Medium/High risk rating based on concrete signals (Script Task usage, Fuzzy Lookup, deprecated CDC/Attunity components, nesting depth, dynamic connection strings) Flags every component individually as auto-mappable or needs-manual-redesign, not just the package as a whole Across a batch of packages, produces a portfolio rollup: risk tier counts, the blockers showing up across the most packages, deprecated components flagged separately, and a suggested migration order What it's built as: a Claude Skill (Anthropic's Claude AI), with the actual XML parsing done by a plain Python script with zero dependencies — not an LLM guessing at package structure. It's designed to run fully offline, no live Azure/Fabric API access assumed, though it flags anywhere that access would improve accuracy (resolving a dynamic connection string, for example). What it deliberately doesn't do yet: this covers the Inventory/Classify phase only. It won't draft actual Fabric pipeline JSON or claim a package is production-ready — every future draft artifact gets an explicit DRAFT/NEEDS REVIEW label. I'd rather it under-claim than over-claim. Repo's on GitHub with a sample package and example report included, so you can see the actual output before running it against your own packages: https://github.com/HBBH11/ssis-fabric-migration-assistant Genuinely interested in feedback from people who've done these migrations for real — particularly whether the risk heuristics hold up against messier packages than my test case, and whether the Fabric equivalence mappings match what you've found in practice. Happy to take suggestions on what a Phase 2 (draft pipeline generation) should prioritize too.
NL to KQL/GQL generation
Hi Team, This is coming from Using Data Agents for NL to KQL/GQL generation | Microsoft Fabric Community. It would be great if we could have a feature where the data agent or the ontology agent can return just the grounded KQL/GQL query (or query variants) required to answer a NL question rather than actually execute it and summarize the result. This is important in use-cases like ours where retrieval needs to be split from query generation. Currently Fabric IQ doesn't provide a way to do that, and the only way seems to be to inspect the data agent's run steps which seems roundabout for something that might be asy to support natively. Please consider this feature request. Thanks!Preserve Power BI Semantic Model Measures and Business Metadata When Generating Fabric IQ Ontologies
When Fabric IQ generates an ontology from an existing Power BI semantic model, it should preserve more of the business semantics that organizations have already invested in defining. Today, a semantic model may contain years of curated business logic and metadata. Generating an ontology should reuse that semantic investment instead of requiring teams to recreate important context manually. Fabric IQ should preserve or map, where applicable: Measures and measure descriptions Business-friendly display names Column and table descriptions Hierarchies Formatting and units Date and time semantics Hidden versus visible fields Source lineage Business metadata associated with model objects Other semantic annotations that can improve ontology and agent understanding Fabric should also provide a mapping report showing: Which semantic-model objects were successfully mapped into the ontology Which metadata could not be mapped Any transformation or interpretation applied Warnings where business semantics may be lost For example, if a semantic model already defines measures such as Revenue, Gross Margin, Active Customers, or On-Time Delivery with descriptions, formatting, and business context, that information should help enrich the generated ontology rather than being discarded. This request is intentionally separate from reusing semantic-model relationships, which is already covered by another Fabric Idea. The focus here is preserving measures and rich business metadata when generating Fabric IQ ontologies. This would reduce duplicate modeling effort, improve consistency between Power BI and Fabric IQ, and give Data Agents richer governed business context from the beginning.Enforce OneLake Row and Column Security End-to-End in Fabric IQ Ontology
Fabric IQ Ontology should natively preserve and enforce OneLake Security when users access ontology entities, relationships, graphs, and downstream AI experiences. Enterprises may define row-level and column-level security directly in OneLake so that security policies are consistently enforced across Fabric workloads. Fabric IQ should participate in that same centralized security model rather than requiring separate security configuration or exposing broader access through ontology bindings. When an ontology entity is backed by a secured Lakehouse or other supported OneLake source, queries through the ontology should execute using the requesting user's identity and enforce the applicable OneLake permissions. The capability should include: Row-level security enforcement Column-level security enforcement User identity passthrough Security inheritance from the underlying OneLake source Support for ontology relationships without bypassing source security Security-aware Graph and Data Agent queries Clear diagnostics showing why a user cannot access an entity, property, or relationship Administrative visibility into which identity and security policy were applied Consistent enforcement when ontology entities are used by downstream AI agents and applications For example, if a Sales ontology contains Customer, Account, Opportunity, and Territory entities, a regional sales user should only receive the rows and properties permitted by the underlying OneLake security policies, even when asking questions through a Data Agent or traversing relationships through Fabric IQ. Organizations should be able to define security once in OneLake and rely on Fabric IQ to honor those policies consistently. This is particularly important for financial, healthcare, HR, government, and other regulated enterprise scenarios where semantic and AI layers must never become a path around the underlying data-security model.Make Fabric IQ Ontology Entities First-Class Assets in OneLake Catalog
Fabric IQ ontology entities and business concepts should be discoverable as first-class governed assets in OneLake Catalog. Today, users often need to know the underlying Fabric item, table, semantic model, or workspace before they can find the data they need. With Fabric IQ, organizations are defining business concepts such as Customer, Asset, Work Order, Supplier, Contract, Shipment, Device, and Product. These semantic entities should be directly searchable and discoverable in OneLake Catalog. For each Fabric IQ entity, OneLake Catalog should display: Business name and definition Entity type Properties and key attributes Related entities and relationships Underlying Lakehouse, Warehouse, Eventhouse, semantic model, or other bound data sources Data owner and steward Endorsement or certification status Sensitivity and governance metadata Lineage Associated Data Agents, reports, dashboards, Graph models, or applications using the entity Users should be able to search the catalog using business terminology such as "Customer", "Asset", or "Work Order" and discover the governed Fabric IQ entity even if they do not know the physical table or Fabric item name. This would connect technical data discovery with semantic discovery and make OneLake Catalog much more useful for business users, data stewards, architects, analytics developers, and AI agent developers. This request is different from general full-text search in OneLake Catalog. The goal is to make Fabric IQ entities and relationships themselves governed, searchable catalog assets, not simply to improve text search across existing Fabric items.Add Incremental and Event-Driven Refresh for Fabric IQ Ontology
Fabric IQ Ontology should support incremental and event-driven updates when the underlying source data changes. For operational and real-time scenarios, ontology entities and relationships may be backed by Lakehouse, Eventhouse, semantic models, or other Fabric data sources that change frequently. Fabric should not require users to manually refresh or rebuild large portions of the ontology simply to make changed source data available. Fabric IQ should automatically identify which entities, properties, and relationships are affected by source-data changes and update only the impacted portions of the ontology. The capability should include change-aware incremental refresh, Eventstream-triggered refresh, pipeline-triggered refresh, configurable freshness targets, entity-level refresh status, last-successful-update timestamps, failed-record diagnostics, dependency-aware refresh ordering, and monitoring of refresh processing and capacity consumption. For example, if the status of an Asset, Work Order, Shipment, Customer, Device, or other operational entity changes, Fabric IQ should be able to update the relevant ontology state quickly without requiring a full ontology refresh. This would make Fabric IQ significantly more practical for operational intelligence, Digital Twin scenarios, Real-Time Intelligence, and AI agents that depend on current business context.Add Versioning, Git Integration and CI/CD for Fabric IQ Ontologies
Fabric IQ Ontology can become a shared enterprise definition of business entities, relationships, properties, and context. As ontologies become dependencies for Data Agents, Graph, applications, and other AI experiences, they need the same production lifecycle controls as other Fabric artifacts. Fabric IQ Ontology should support version history, Git integration, export/import, compare and diff, pull-request review, deployment pipelines, environment-specific data bindings, rollback, and a complete audit history. Fabric should also provide dependency and breaking-change analysis before an ontology change is deployed. For example, if the definition, key, or relationship for a Customer entity changes, Fabric should identify affected relationships, Graph models, Data Agents, applications, and other downstream consumers. This would make Ontology practical for enterprise development teams that need controlled development, testing, approval, deployment, and rollback across development, test, and production environments.
