Teaching Copilot Your Business Language: Dataverse Semantic Model

Ever asked Copilot a perfectly reasonable business question and gotten back a shrug, even though the data was sitting right there in Dataverse? That’s usually not a Copilot problem. It’s a language problem. Your team doesn’t talk in table and column names; you talk in “client,” “deal,” “ARR,” and “in the oven.” The AI, left to its own devices, only knows what the schema tells it, and schemas are rarely written in plain English.

Microsoft’s answer to this is the Dataverse semantic model, a new piece of Dataverse Intelligence that’s now in public preview. I spent some time setting it up and testing it against my own environment, and this post walks through what it is, how to turn it on, and a real before-and-after example of it doing its job.

What the semantic model actually is

The simplest way to describe it: the semantic model is a layer that sits between your raw Dataverse schema and any Copilot or agent experience that reasons over your data. Instead of an AI agent guessing what a column named ikl_targetarr or a picklist value like 3 means, the semantic model gives it a business-aware understanding of your tables, built partly from what’s already in your environment and partly from vocabulary you define yourself.

Microsoft describes it as combining three building blocks, and once you see them laid out, it’s a lot easier to understand what you’re configuring and why:

• Data scope with semantic indexing: Which tables are actually included. Only tables in scope contribute to what an agent understands, so this is your first lever for both relevance and performance.
• System-inferred signals: Relationships, public views with join conditions, sub-grid views, form display names, and column/table descriptions that the model reads automatically from metadata you’ve already configured. Sample data rows can optionally feed in too, though that’s off by default.
• The glossary: The human-curated layer. This is where you tell the model the things it can’t infer on its own: acronyms, internal slang, and department-specific shorthand.

Worth calling out: system views such as Quick Find, Advanced Find, Associated, and Lookup views don’t feed the model, and neither do personal views. For forms, only the display name is picked up, not the layout. Polymorphic relationships aren’t supported yet. None of this is a dealbreaker, but it explains why a view you expect to contribute to the model sometimes just doesn’t.

Why this is worth your time?

Four things stood out to me as the practical payoff:

• Better accuracy: The agent is interpreting intent instead of pattern-matching against column names.
• Faster answers: A well-scoped model means less ambiguity for the agent to resolve at query time.
• Less setup work over time: The model pulls from metadata you already maintain and refreshes on its own as your schema evolves.
• Consistency across agents: Every agent pointing at the same semantic model shares the same understanding, so you don’t get three different answers to the same question from three different bots.

Setting it up

You’ll need System Administrator access for this. There are two admin surfaces involved before you ever touch the semantic model itself.... Read More