Forum Discussion
Fabric data agent
I am using Link to fabric to get data from dataverse and onelake model for my data agent. I have multiple choice columns, what will be the best way to handle the choice columns for data agent? How to increase the accuracy?Any suggestions?
Hi aishwariaAL ,
Choice columns come into OneLake as numeric option values, which is why the data agent struggles. The labels are synced separately in the metadata tables — OptionsetMetadata, GlobalOptionsetMetadata, StateMetadata, StatusMetadata.
What tends to work best:- Build a curated Lakehouse/Warehouse view that joins your tables to those metadata tables (on EntityName + AttributeName / GlobalOptionSetName + Option, filtered by language code) and exposes both the code and a readable label column. Point the data agent at that layer.
- For multi-select, split the delimited values, join to metadata, then re-aggregate into a label list.
- In the agent, add clear data source instructions describing each choice column and common user synonyms, plus a few validated example queries. Iterate using the Run Steps view and a small benchmark set.
Quick things to check: are your choice columns single-select, multi-select, or both — and is the agent pointed at the mirrored Lakehouse directly or a curated layer on top?
If this got you what you needed, a Kudos and an Accepted Solution mark would be great! — it helps others searching for the same thing find the answer quicker.Hello aishwariaAL,
For Data Agents, it's generally better to expose meaningful business values rather than the raw Dataverse choice values.
A few recommendations:
Replace choice codes with their display labels before exposing the data to the semantic model (or include both code and label if needed).
Add clear descriptions to tables and columns in the semantic model so the Data Agent has better business context.
Use friendly column names instead of technical Dataverse schema names.
Create dimension/lookup tables for frequently used choice fields and relate them to your fact tables. This helps the Data Agent better understand the domain.
Hide technical columns that aren't useful for business users to reduce ambiguity.
Test the agent with different phrasings of the same question and refine the semantic model where responses are inaccurate.
In my experience, Data Agents produce much better results when the semantic model is business-friendly and choice fields are represented by descriptive labels rather than numeric option-set values.
Best regards,
Omkar Shinde
Microsoft Fabric Enthusiast | Power BI Consultant
💡 If you found this response helpful, please consider giving it a Kudos.
✅ If this resolves your question, please mark it as the Accepted Solution to help others in the community.
2 Replies
Hi aishwariaAL ,
Choice columns come into OneLake as numeric option values, which is why the data agent struggles. The labels are synced separately in the metadata tables — OptionsetMetadata, GlobalOptionsetMetadata, StateMetadata, StatusMetadata.
What tends to work best:- Build a curated Lakehouse/Warehouse view that joins your tables to those metadata tables (on EntityName + AttributeName / GlobalOptionSetName + Option, filtered by language code) and exposes both the code and a readable label column. Point the data agent at that layer.
- For multi-select, split the delimited values, join to metadata, then re-aggregate into a label list.
- In the agent, add clear data source instructions describing each choice column and common user synonyms, plus a few validated example queries. Iterate using the Run Steps view and a small benchmark set.
Quick things to check: are your choice columns single-select, multi-select, or both — and is the agent pointed at the mirrored Lakehouse directly or a curated layer on top?
If this got you what you needed, a Kudos and an Accepted Solution mark would be great! — it helps others searching for the same thing find the answer quicker.Hello aishwariaAL,
For Data Agents, it's generally better to expose meaningful business values rather than the raw Dataverse choice values.
A few recommendations:
Replace choice codes with their display labels before exposing the data to the semantic model (or include both code and label if needed).
Add clear descriptions to tables and columns in the semantic model so the Data Agent has better business context.
Use friendly column names instead of technical Dataverse schema names.
Create dimension/lookup tables for frequently used choice fields and relate them to your fact tables. This helps the Data Agent better understand the domain.
Hide technical columns that aren't useful for business users to reduce ambiguity.
Test the agent with different phrasings of the same question and refine the semantic model where responses are inaccurate.
In my experience, Data Agents produce much better results when the semantic model is business-friendly and choice fields are represented by descriptive labels rather than numeric option-set values.
Best regards,
Omkar Shinde
Microsoft Fabric Enthusiast | Power BI Consultant
💡 If you found this response helpful, please consider giving it a Kudos.
✅ If this resolves your question, please mark it as the Accepted Solution to help others in the community.