Dataverse as a knowledge source for agents

What it does

Points a Copilot Studio agent at Dataverse tables so it can answer questions from your operational data. Retrieval runs through Dataverse search, which means the search index and the columns you marked searchable are what the agent can actually see — the table list in the knowledge picker is only half the configuration.

Key facts

Dataverse search must be turned on for the environment. Without it, you can't add a Dataverse table as a knowledge source at all.
The agent's authentication has to be set to Authenticate with Microsoft. No authentication and Authenticate manually aren't supported for this knowledge source.
Up to 15 Dataverse tables per knowledge source. Table suggestions in the picker are based on the agent's name, which is a nudge rather than a recommendation.
Synonyms, glossary terms and column descriptions are the tuning surface. Updated glossary terms and definitions can take up to 15 minutes to take effect.
Unstructured reasoning over Multiline Text (MemoType) and File (FileType) columns is in preview as of the May 2026 documentation update. It needs those columns marked Searchable and added to the Quick Find View.
If you add the knowledge source before configuring those columns for search, backfill can take up to two days. Re-adding the knowledge source after configuring search is the documented way to speed it up.
Virtual tables can be used as knowledge, but only virtual tables on the finance and operations data provider. Any other provider isn't supported.
Creating a search index carries extra Dataverse capacity cost — Microsoft documents this on the Dataverse search configuration page rather than quoting it in the Copilot Studio docs.

When to use / skip

Use it when the questions are genuinely lookup-shaped — "what's the status of my order", "which contracts expire this quarter", "who owns this account". That's what the retrieval path is good at, and it comes with the user's own row-level access for free, which is the single biggest reason to prefer this over dumping an export into a file knowledge source.

Skip it when the answer needs aggregation, computation or a guaranteed-complete result set. Retrieval returns relevant chunks, not a query result — an agent asked "how many open cases are there" is doing something the mechanism wasn't built for. That's a tool or an action calling a real query, not a knowledge source. Getting this distinction wrong is the most common reason a Dataverse-grounded agent demos well and disappoints in pilot.

Configuration decisions

Which tables, given the 15-table ceiling per knowledge source — and whether the answer is fewer tables with better descriptions rather than more tables.
Which columns are marked searchable, because that list and not the table schema is the agent's actual field of view.
How much glossary and synonym work you're committing to. This is where the quality difference lives, and it's ongoing effort, not a one-off configuration task.
Whether unstructured reasoning over notes and file columns is worth taking a preview dependency for.
Whether a knowledge source is the right shape at all, or whether the requirement is really a tool that runs a defined query.

Gotchas

Column names like cr_123_abc mean nothing to the model. Numeric or coded columns need an explicit description saying what the values represent, or the agent will confidently misread them.
The 15-minute delay on glossary changes catches people mid-demo. They tweak a definition, retest immediately, see no change and assume the feature is broken.
Turning on Dataverse search is an environment-wide change with a capacity consequence. It's often the first real cost of an "just a quick agent" pilot.
The preview backfill window of up to two days makes iteration on multiline and file columns painfully slow. Configure search first, then add the knowledge.
Requiring Authenticate with Microsoft rules out anonymous and externally-facing agents on this knowledge source. Clients planning a public-facing assistant grounded in Dataverse need to hear that on day one.

Consultant notes

Frame this as search tuning, not AI configuration. The people who get good results are the ones who treat synonyms and glossary terms as a maintained artefact with an owner.
Push for a small, well-described table set in the pilot. Agents grounded on twelve loosely-described tables answer worse than agents grounded on three well-described ones, and clients find that counter-intuitive.
Set expectations on aggregation early and in writing. "It can find things, it can't count things" saves a lot of grief in UAT.
Test as a low-privileged user, not as the maker. Retrieval respects the signed-in user's access, so the maker's experience of the agent is the best case, not the typical one.

Worth re-reading when unstructured reasoning over notes and file columns goes GA — the preview limits are most of what's constraining this today