Copilot Studio + SharePoint: Markdown (.md) Files in Doc Libraries Supported as Knowledge Sources?
Hi all, We’ve been doing some deeper testing with Copilot Studio agents grounded in SharePoint knowledge sources, and I’m hoping to clarify whether what we’re seeing is a known limitation or an undocumented gap. Scenario A Copilot Studio agent uses SharePoint document libraries as a knowledge source The library contains Markdown (.md) files that are intentionally used as canonical design references The same .md files: ✅ Work well when uploaded directly to the agent ❌ Are not retrievable or citable when stored in a SharePoint library and added as a SharePoint knowledge source To help with grounding, we created modern SharePoint index pages that: Explain what the markdown collections are (Patterns, ADRs, Guardrails) Link directly to the canonical folders and files Explicitly state that the .md files are the source of truth The agent can: Discover and summarize the index pages correctly Understand that .md artifacts exist and where they live But it cannot: Read the content of the individual .md files Apply a specific pattern or ADR from those files in a design conversation Cite them as sources, even when permissions and search indexing are confirmed What We’ve Checked Permissions (agent user has access) Folder depth (kept shallow) Search results (markdown files appear in SharePoint search) SharePoint indexing status Work IQ enabled Same content works when attached directly to the agent This behavior also seems consistent with what others have reported here: Markdown works when uploaded directly Markdown retrieval degrades when hosted in SharePoint libraries Questions for the Product Team / Community Are Markdown (.md) files in SharePoint document libraries officially supported as Copilot Studio knowledge sources today? If yes, are there specific constraints (file size, rendering, parsing, indexing) that differ from Word/PDF? If no (or “not yet”), is this a known limitation on the roadmap? Is the recommended pattern to: Convert important markdown files into .aspx pages, or Use thin “index / summary” pages and keep markdown canonical until retrieval improves? We’re happy to adapt our information architecture — just trying to align with the intended platform direction rather than work against it. Thanks in advance for any guidance or clarification. This capability is extremely powerful, and clearer expectations here would help a lot of teams make the right design tradeoffs.
Copilot Studio Knowledge Source Limitation When Iterating Over Multiple SharePoint Documents
Hi, I’m looking for clarification on a limitation we’re currently encountering in Copilot Studio that is blocking some of our use case. Example Scenario (Policy Agent) We have a SharePoint document library containing ~100 policy documents. A Copilot Studio agent is configured with this library as a knowledge source. The agent performs well for typical question-answering scenarios where responses can be derived from a subset of documents. For example: “How much annual leave can I take?” correctly returns answers sourced from multiple relevant policies. Issue When the question requires the agent to evaluate all documents individually, the results are incomplete. Example prompt: “Review each policy document and return the review date.” In this scenario: The agent only processes the first ~10 documents. It then stops, without indicating that the response is partial or that a limit has been reached. The remaining documents in the library are not evaluated. During a recent Microsoft-led course, we were advised that this behaviour is expected due to platform limitations. Specifically: While it will reside over all documents to genereate the most suitable response, the agent is not designed to self‑iterate across all items in a large knowledge source for individual document responses. Asking it to “review each document” effectively requires iteration, which is constrained. The suggested workaround was to: Create a trigger-based flow Implement a loop to process the documents in batches We were able to make this approach work, but it feels like a heavy and brittle workaround for what seems like a common enterprise requirement. We’ve Tried Both available SharePoint knowledge source connection methods Allowing sufficient time for indexing and refresh Rephrasing prompts to encourage broader coverage None of these approaches changed the outcome, the agent consistently returns results for only the first subset of documents. Is this behaviour a documented or known limitation of Copilot Studio knowledge sources? Are there recommended design patterns for scenarios that require document-by-document evaluation at scale? Is there a more native or supported approach planned to avoid custom looping logic for this kind of use case? Any guidance or confirmation would be appreciated. Thanks.
