Forum Discussion
Dataverse Data Live Integration with Foundry Agents via Fabric
Hola Ashwath_Bala_S
Thanks for sharing the scenario. I believe there are some important architectural considerations to take into account before choosing the final pattern.
First, with Fabric Link, the data exposed in Fabric is not the same as building a fully materialized analytical layer from the start. In Finance and Operations scenarios, it is also important to distinguish between tables and entities, as both can be enabled and used differently.
Second, it is important to carefully consider the synchronization behavior. According to Microsoft documentation, Fabric Link triggers refresh tasks every 15 minutes, and updated files may appear within approximately 15 to 45 minutes depending on volume and change frequency. Therefore, I consider this solution to be frequently updated, near real-time for analytical purposes, but not suitable for strict real-time ingestion.
Based on this, my recommendation would be to use a medallion-style architecture:
- Bronze: keep Fabric Link as the raw ingestion layer
- Silver: materialize and normalize business data into physical tables in OneLake
- Gold: expose curated, business-ready tables/views for agent consumption
In practice, I would not recommend using the linked layer directly as the final source for Foundry configuration. It is generally better to first use structured and organized business objects, especially when the source comes from Dataverse/FnO entities.
For the Silver and Gold layers, it is worth considering Materialized Lake Views. Microsoft documents them as a way to implement medallion architecture in Fabric Lakehouse, with results stored as Delta files in OneLake and automatically updated through schedules or event triggers. This helps reduce execution time and makes transformations more operational and reusable.
From there, I see two compatible patterns depending on the target agent technology:
- If the goal is conversational access to structured Fabric data: a Fabric Data Agent is a great option. These agents can use Lakehouses, Warehouses, Power BI semantic models, KQL databases, and ontologies as sources.
- If the goal is specifically Azure AI Foundry Agent Service with retrieval/vectorization: the most compatible pattern currently seems to be: curated Fabric data → indexing layer → Azure AI Search / Foundry IQ knowledge base → Foundry Agent
It would be advisable to assume that a Foundry agent can directly use a Fabric Data Agent as its knowledge source, as official Foundry guidance focuses on connections such as knowledge bases.
In summary, my recommendation would be: F&O → Fabric Link (Bronze) → Materialized business tables (Silver) → Curated service layer (Gold) → Consumption by Fabric + Foundry agents (Data Agent knowledge)
This provides:
- separation between ingestion and consumption
- better control over refresh and data quality
- a more scalable and compatible pattern for agent integration
- flexibility to use either Fabric Data Agents or Azure AI Foundry agents depending on the final use case
If my comment helped you resolve your question, I would appreciate it if you marked it as the accepted solution and gave it a like. This helps other users with the same problem and motivates me to continue contributing.
Thank you very much.
Hello Ashwath_Bala_S
You can’t query Lakehouse tables, files, or Dataverse shortcuts directly from Foundry Agents. The supported and intended pattern is Foundry Agent → Fabric Data Agent → Fabric data sources. Fabric Data Agent does the heavy lifting here – it provides the semantic layer, security enforcement, and query translation (NL to SQL, DAX, or KQL), while Foundry simply orchestrates and invokes tools rather than accessing data itself.
For Dataverse specifically, the data must first sit behind a Fabric‑supported analytical surface before a Data Agent can use it. Using Fabric Link (Dataverse Link to Fabric) is the right starting point, as it exposes Dataverse data as linked Delta tables in OneLake. It’s worth remembering that Fabric Link syncs every 15–45 minutes, which Microsoft positions as near real‑time for analytics, not for operational or transactional use.
You’ll generally get better results if you don’t expose those linked Dataverse tables directly to agents. A more robust approach is to apply a medallion architecture: keep linked tables as Bronze, materialise and clean them into Silver, then curate agent‑ready Gold tables or a semantic model. Fabric Data Agents perform noticeably better when querying clean, well‑modelled schemas rather than raw or loosely structured sources.
Fabric Data Agents can sit on top of Power BI semantic models, curated Gold Lakehouse tables, or Warehouses. In practice, semantic model‑backed agents tend to give higher accuracy and shorter prompts because they can lean on rich relationships, measures, and metadata. If you also need search or vector capabilities, treat that as a complement: extract text from curated Fabric tables, build Azure AI Search or vector indexes, and expose that alongside the Fabric Data Agent as a separate tool in Foundry. That multi‑tool pattern extends what the agent can do, rather than replacing the Data Agent altogether.
Hola Ashwath_Bala_S
Thanks for sharing the scenario. I believe there are some important architectural considerations to take into account before choosing the final pattern.
First, with Fabric Link, the data exposed in Fabric is not the same as building a fully materialized analytical layer from the start. In Finance and Operations scenarios, it is also important to distinguish between tables and entities, as both can be enabled and used differently.
Second, it is important to carefully consider the synchronization behavior. According to Microsoft documentation, Fabric Link triggers refresh tasks every 15 minutes, and updated files may appear within approximately 15 to 45 minutes depending on volume and change frequency. Therefore, I consider this solution to be frequently updated, near real-time for analytical purposes, but not suitable for strict real-time ingestion.
Based on this, my recommendation would be to use a medallion-style architecture:
- Bronze: keep Fabric Link as the raw ingestion layer
- Silver: materialize and normalize business data into physical tables in OneLake
- Gold: expose curated, business-ready tables/views for agent consumption
In practice, I would not recommend using the linked layer directly as the final source for Foundry configuration. It is generally better to first use structured and organized business objects, especially when the source comes from Dataverse/FnO entities.
For the Silver and Gold layers, it is worth considering Materialized Lake Views. Microsoft documents them as a way to implement medallion architecture in Fabric Lakehouse, with results stored as Delta files in OneLake and automatically updated through schedules or event triggers. This helps reduce execution time and makes transformations more operational and reusable.
From there, I see two compatible patterns depending on the target agent technology:
- If the goal is conversational access to structured Fabric data: a Fabric Data Agent is a great option. These agents can use Lakehouses, Warehouses, Power BI semantic models, KQL databases, and ontologies as sources.
- If the goal is specifically Azure AI Foundry Agent Service with retrieval/vectorization: the most compatible pattern currently seems to be: curated Fabric data → indexing layer → Azure AI Search / Foundry IQ knowledge base → Foundry Agent
It would be advisable to assume that a Foundry agent can directly use a Fabric Data Agent as its knowledge source, as official Foundry guidance focuses on connections such as knowledge bases.
In summary, my recommendation would be: F&O → Fabric Link (Bronze) → Materialized business tables (Silver) → Curated service layer (Gold) → Consumption by Fabric + Foundry agents (Data Agent knowledge)
This provides:
- separation between ingestion and consumption
- better control over refresh and data quality
- a more scalable and compatible pattern for agent integration
- flexibility to use either Fabric Data Agents or Azure AI Foundry agents depending on the final use case
If my comment helped you resolve your question, I would appreciate it if you marked it as the accepted solution and gave it a like. This helps other users with the same problem and motivates me to continue contributing.
Thank you very much.