Stairway to Dataverse Heaven

There’s a moment in every agentic strategy project where you realize: how your agent connects to data matters just as much as what data it sees.

Now, coming from the world of Dynamics 365 and Model-Driven Power Apps, Dataverse is the golden data source.

So naturally, when there is an ask to create a custom agent which can “speak” the business app’s language, what is the next step? Connect to Dataverse of course!

Looking at your metaphorical whiteboard, three (plus a bonus one) distinct low-code, native approaches emerge:

Each one represents a different pattern, ranging from search-first AI reasoning to deterministic API-driven execution and agent-native data intelligence.

Let’s break them down and find our own stairway to Dataverse heaven!

Note: Whilst the below post will start comparing and contrasting these three ways, there is another low-code way worth the shout out! This is the use of custom prompts in Copilot Studio invoking Dataverse tables. And who does not love some custom prompts infusing bespoke ways of analyzing data into their agents?

Before going deep into this fun Dataverse rabbit hole, I want to share my heartfelt appreciation for the Microsoft Dataverse team. Not only because they are shipping some cool products, but also because they have been incredibly kind sharing time and feedback with me as I put together this topic and even ahead of my session at Dynamics Minds 2026.

Julie Koesmarno, Kent Weare and Jason Huang, you absolutely rock! Really humbled for everything we covered together. Extra shout out for the recent Build session on demand here with regards to Microsoft Dataverse plugin: unleashing coding agents on the enterprise.

Dataverse as a Knowledge Source

• Treats Dataverse like indexed content for AI retrieval.

• Ideal execution for read-only/ summarization scenarios and optimized for agentic search.

• A great candidate for unstructured data.

• Customer support agent answering questions about past cases or FAQs stored in Dataverse.

• HR bot retrieving company travel policy details from Dataverse tables.

• Sales assistant summarizing account purchase history.

• Traditional connector using actions and parameters.

• Deterministic, API-driven interaction with Dataverse.

• You explicitly define inputs and outputs and can perform DML (Data Manipulation Language) kind of CRUD operations. Worth noting that connectors are more like metadata-aware rather than schema aware like autonomous understanding of relationships.

• Create/update records (e.g., new lead, update opportunity).

• Trigger workflows from agent conversations.

• Structured forms and transactional operations.

A note on the supported tables:

For the Dataverse connector, it is important to note that standard and custom tables are fully supported. This includes the ability to read, write, query, filter, and perform CRUD operations on them. Elastic tables are not supported.

Virtual tables are supported BUT with some limitations:

• They can be read because Dataverse exposes them through the same OData surface.

• The rest of the CRUD operations (Create/ Update/ Delete) will not work unless the virtual table provider explicitly supports write operations and certain other conditions are met. These limitations come from Dataverse’ s virtual table architecture, not Copilot Studio itself.

• Exposes Dataverse as an agent-native capability layer with contextual understanding over business data structures.

• Connected agents can look through both schema and included data.

• Supports both data (DML = Data Manipulation Language) and metadata (tables, columns/ DDL = Data Definition Language) operations.

A note on the origins and the strong technology positioning: MCP Servers originated from Anthropic as an open industry standard applicable to use cases and tools beyond Copilot Studio. Since we always think about mesh ecosystems and interoperability, MCP Servers become even more interesting in architectural patterns. No wonder they are so widely adopted already across the AI industry.

As per the latest documentation, there are many tools available for users to enjoy. Thanks to the clear breakdown of the tools, you can better understand how the Dataverse MCP Server works. And guess what? Better, deeper understanding means more intentional maker building, more governable admin solutions and more efficient user interactions.

The last 3 skills are quite interesting because they finally allow moving files in and out of Dataverse! Big help when it comes to working with unstructured data.

To clarify: MCP Servers are not “intelligent” entities reasoning over data. They are the execution layer. The intelligent reasoning happens at the agent/ LLM layer, by deciding which tools to call and interpreting the results.

• Agent dynamically deciding which table to query, or even whether it should create a new one in the data model.

• Complex multi-step analysis (e.g., “find inactive customers who bought a combo travel package in EMEA”).

• Really complex, custom table solutions with advanced business logic in forms on top.

There is a lot more to cover, in fact a lot that glitters. And some of it is gold.

That what part 2 of this blog post will be about! We will cover topics like governance, ways to determine your use case’s architecture and how to provide more context to agents!