Every Copilot Studio agent I have built or seen built starts with the same decision. Where does the knowledge live. SharePoint or Dataverse. The copilot studio knowledge sources picker makes it look like a flat choice. It is not. The two behave very differently once real content and real users hit them, and the wrong call shows up around month three when answers start drifting.
I have been reading a lot about this lately and talking to people at other organisations who hit the same wall. Here is how I actually compare the two now, across four dimensions that matter.
Content ceiling and file limits
SharePoint as a knowledge source caps out at 4 SharePoint sites per agent, and Copilot Studio indexes the documents through Graph search. That sounds generous until you realise the same site is often wired into three agents with different filters, and indexing latency on freshly uploaded files can run several minutes before the agent sees them.
Dataverse knowledge sources let you attach tables with up to 25 columns indexed for semantic search, and you can scope to specific rows with security roles. The ceiling is higher and the control is finer. The tradeoff is you have to actually get the content into Dataverse rows in the first place, which is real work if your source of truth is a folder of PDFs.
Governance and ownership
This is where I keep seeing teams pick wrong. SharePoint feels easy because the content is already there. But the same SharePoint site ends up wired four different ways by four different makers with no shared governance, which I wrote about in more detail when Dataverse got knowledge sources and agent feedback loops.
Dataverse forces ownership. Each knowledge source is a managed record with an owner, a solution layer, and environment promotion. You can audit who changed what. With SharePoint sites, the agent sees whatever a site owner decides to upload that afternoon. That is not governance, that is hoping.
Latency and answer quality
| Dimension | SharePoint | Dataverse |
|---|---|---|
| Indexing latency | 2-10 minutes typical | Near real-time on row update |
| Content ceiling | 4 sites per agent | Multiple tables, row-level filters |
| Citation quality | File and page reference | Row-level with column context |
| Governance | Site owner discretion | Solution-bound, owned record |
| Setup effort | Low if content already in SharePoint | Higher, needs data model |
Citation quality matters more than people admit. When an agent cites a 200-page PDF in SharePoint, users still have to find the answer inside the document. With Dataverse row-level citations, the agent points at the specific record, which makes hallucinations easier to spot and correct. The new Dataverse MCP server tool shape splits metadata inspection, querying, and search into cleaner boundaries that make this even more precise for agents.
Cost and licensing
SharePoint knowledge sources use the standard SharePoint connector, which keeps things in the base licensing envelope for most internal scenarios. Dataverse knowledge sources mean Dataverse capacity, and depending on how much you index, that adds up. If near real-time data freshness is part of your argument for Dataverse, the low-latency sync from Dataverse to Fabric hitting GA is worth factoring into the broader data architecture conversation at the same time. Do not pay for Dataverse capacity you do not need.
Microsoft documents the current connector and capacity behaviour in the Copilot Studio docs, and it is worth checking before you commit a topology.
Choose SharePoint if, choose Dataverse if
Choose SharePoint as your Copilot Studio knowledge source if the content is already in SharePoint, lives as documents rather than structured data, the agent serves under a few hundred users, and you can live with multi-minute indexing latency. It is the right call for a policy lookup agent pointed at an existing HR site.
Choose Dataverse as your knowledge source if the content is structured, ownership and auditability matter, you need row-level security, or the agent is going to be promoted across environments under ALM. It is the right call for any agent that touches process logic, business skills, or anything a regulator could ask about later.
The decision is not which one is better. It is which one matches the shape of your content and the seriousness of the use case. I have made the wrong call on this and paid for it in debugging time. Pick deliberately.
Frequently Asked Questions
What are the best copilot studio knowledge sources for enterprise agents?
The two main copilot studio knowledge sources are SharePoint and Dataverse, and the right choice depends on your governance needs and content structure. SharePoint is quicker to set up if content already exists there, but Dataverse offers better control, row-level filtering, and near real-time indexing for more demanding use cases.
When should I use Dataverse instead of SharePoint as a knowledge source in Copilot Studio?
Dataverse is the better choice when you need strict governance, auditable ownership, or row-level security over your content. It also suits scenarios where indexing latency matters, since Dataverse updates are reflected near real-time compared to SharePoint’s typical 2-10 minute delay.
Why does my Copilot Studio agent not pick up newly uploaded SharePoint files immediately?
Copilot Studio indexes SharePoint content through Graph search, which can introduce a delay of several minutes before freshly uploaded files become visible to the agent. This latency is a known tradeoff of using SharePoint as a knowledge source rather than a structured data store like Dataverse.
How do I improve answer quality in a Copilot Studio agent?
Switching from SharePoint to Dataverse as your knowledge source can improve citation quality, since Dataverse returns row-level references with column context rather than broad file or page links. Scoping your knowledge source to well-structured tables with relevant columns indexed for semantic search also helps the agent return more precise answers.
Leave a Reply