Halilcan Soran

Tag: SharePoint

  • SharePoint vs Dataverse as a Copilot Studio Knowledge Source

    SharePoint vs Dataverse as a Copilot Studio Knowledge Source

    SharePoint vs Dataverse copilot studio knowledge sources comparison

    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.

  • SharePoint Lists Are Still the Best Backend for 80 Percent of Power Platform Apps

    SharePoint Lists Are Still the Best Backend for 80 Percent of Power Platform Apps

    SharePoint lists for power platform apps backend architecture decision

    There is a pattern I keep seeing on LinkedIn and in conversations with people at other organisations. A team starts a new Power Platform project, someone labels it ‘enterprise’, and suddenly the backend discussion jumps straight to Dataverse. No one questions it. Licensing gets justified in a spreadsheet, premium seats get budgeted, and six weeks later the solution is a list of 4000 records with a status column and three lookup fields. That is the moment I want to push back. For a big chunk of internal work, SharePoint lists for power platform apps are still the right call, and treating that choice as amateur hour is costing teams real time and money.

    Why SharePoint Lists Keep Getting Dismissed Unfairly

    The dismissal usually comes from two places. First, the word SharePoint carries baggage from the 2013 era that has nothing to do with what Lists actually is in 2026. Second, Dataverse gets sold as ‘the proper enterprise choice’ in every Microsoft deck, so picking anything else feels like admitting you cut corners.

    Neither of those is an engineering argument. They are vibes.

    In practice, a modern SharePoint list gives you a REST and Graph API, column-level validation, versioning, item-level permissions if you really need them, native integration with every Power Platform connector, and a UI that business users can actually open and fix when something looks off. You get Entra ID authentication for free. DLP policies cover it. The audit log flows into the same Purview tenant everything else does. For an internal request tracker, an onboarding checklist, a small approval queue, or a reference table that three flows read from, that is the whole job.

    The Workloads Where SharePoint Is Genuinely the Right Answer

    I am not arguing SharePoint wins everywhere. I am arguing it wins for a specific and very common shape of work.

    If the app is an internal tool, used by under a few hundred people, with a data volume that will never credibly pass 20 or 30 thousand items in any single list, and a schema that fits cleanly into flat records with a handful of choice and lookup fields, you are in SharePoint territory. Registrations, comms sign-offs, small approval workflows, asset inventories, internal request forms, training trackers, audit checklists. This is the bread and butter of Power Platform inside any large organisation.

    Building on a list for that kind of workload is faster in almost every dimension. You spin up the schema in minutes. Makers on your team can read and edit the data directly in the browser without a model-driven app wrapper. Your Power Automate flows use the standard SharePoint connector, which means no premium licence for the thousand people who happen to trigger a flow indirectly. That last point alone saves real budget. I have written before about how licensing shapes architecture choices in enterprise environments, and this is one of the clearest examples.

    The Real Limits You Need to Design Around

    SharePoint lists are not magic. They have hard edges, and you need to know them before you commit.

    The 5000 item view threshold is the one everyone quotes, and it is real, but it is a view and query limit, not a storage limit. A list can hold millions of items. You work around the threshold with indexed columns, filtered views, and delegable queries in Power Apps. If you are careful with your delegation, a list with 50,000 items performs fine for the usage patterns most internal apps actually have.

    Throttling is the other one. The SharePoint connector has its own limits, and if you are running a flow that hammers a list in an Apply to Each loop at full concurrency, you will get throttled. Same story I covered in the throttling post. Drop concurrency, batch your reads, and stop treating the list like a transactional database.

    Where SharePoint genuinely falls over is relational complexity. More than two or three lookups deep and you are building joins in Power Automate, which is painful to maintain. Row-level security beyond basic item permissions gets ugly fast. Calculated columns are limited. And if two users edit the same item in the same second, you can get conflicts the platform does not resolve gracefully. This is also where why Power Automate is still worth learning in 2026 becomes relevant — knowing how to structure flows around list limitations is a skill that pays off repeatedly.

    When to Actually Move to Dataverse

    Dataverse earns its licence cost when the workload has specific characteristics. Genuine relational depth with many-to-many relationships you actually traverse. Role-based security that needs to be enforced at the data layer, not the app layer. Business rules and calculated fields that are part of the data contract. Plugins, server-side logic, or integration with Dynamics. Auditing at the field level for compliance. Transactional guarantees where a failed write must roll back cleanly.

    If your project has three or more of those, Dataverse is the right choice and the licensing conversation is easy to win because the alternative is building those features yourself and maintaining them forever.

    If your project has none of them, and you are about to spend eight weeks justifying premium seats for 400 people so you can store a status column on 4000 records, stop. Build it on a list. Ship it next week. Spend the saved budget on something that actually needs it. And before you wire any intelligence layer into whatever you build, it is worth reading Adding Copilot to Your Power App Is Not the Same as Making It Smarter — the backend choice and the AI layer choice follow the same logic.

    The backend choice is an engineering decision, not a status symbol. I write more about these kinds of trade-offs on my LinkedIn if this is the kind of call you are wrestling with right now.

    Frequently Asked Questions

    When should I use SharePoint lists for Power Platform apps instead of Dataverse?

    SharePoint lists are a strong fit when your app is internal, used by fewer than a few hundred people, and will never exceed tens of thousands of items in a single list. Common examples include approval queues, request forms, training trackers, and asset inventories where a flat schema with a few lookup fields covers everything you need.

    Why does using SharePoint as a Power Platform backend save money on licensing?

    Power Automate flows that connect to SharePoint use the standard connector, which does not require a premium licence. In large organisations where thousands of users might trigger a flow indirectly, avoiding premium connector requirements can add up to significant budget savings compared to a Dataverse-backed solution.

    What are the security and governance features available with SharePoint lists?

    Modern SharePoint lists authenticate through Entra ID and are covered by your organisation’s DLP policies. Audit logs feed into the same Purview tenant as your other Microsoft 365 services, so governance and compliance requirements are met without additional configuration.

    How do I know if Dataverse is actually necessary for my Power Platform project?

    If a solution is genuinely enterprise in scale, involving complex relational data, high record volumes, or advanced role-based security requirements, Dataverse earns its place. However, if the data model is a few flat lists with simple lookups and the user base is a small internal team, reaching for Dataverse by default adds cost and complexity without a clear engineering benefit.