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.From SOP Overload to Simple Answers: Building Q&A Agents With SharePoint Online + Agent Builder
Government teams run on Standard Operating Procedures, manuals, handbooks, review instructions, HR policies, and proposal workflows. They’re essential—and everywhere. But during every Government Prompt‑a‑thon we've run this year, one theme kept repeating: "Our policies are many and finding the right answer quickly is nearly impossible." Turning SOPs into Simple Q&A Agents with M365 Copilot's Agent Builder or SharePoint Agents is possibly one of the fastest wins for public‑sector teams.Welcome let's get started
Welcome to the Copilot Studio Community on Microsoft Tech Community! We're thrilled to announce that Copilot Studio now has a dedicated home on the Microsoft Tech Community, and we'd love for you to be part of it from day one. Whether you're just getting started with building Agents in Agent Builder or you are a pro building agents and automations with Copilot Studio, this is your space to: Ask questions and get answers from the community and Microsoft experts Share what you've built — show off your agents, flows, and use cases Stay up to date on the latest features, releases, and best practices Connect with peers across industries who are shaping the future of AI-powered work The community is open to everyone, from first-time explorers to seasoned pros. Every question asked and every insight shared makes this a better resource for all of us. We can't wait to see what you build. Welcome!Agent Builder, Copilot Studio, or Azure AI Foundry: How We Decide for Every Client
Every client conversation starts the same way. Someone has seen a demo, attended an Ignite session, or read a press release. They want to build an agent. Then comes the question that derails more projects than any technical challenge: "Which tool should we use?" After deploying agents for clients across industries - insurance, professional services, manufacturing, public sector - we have developed a repeatable framework for answering that question. It is not based on which tool is newest or which has the best marketing. It is based on where projects actually succeed or fail in production. The three tools are not competitors The first mistake most teams make is treating Agent Builder, Copilot Studio, and Azure AI Foundry as a hierarchy - basic, intermediate, advanced. That framing leads to bad decisions. They are not a ladder. They are three distinct tools built for three distinct contexts. The right question is not "which tool is most powerful?" It is "which tool fits this project's constraints?" The framework: 4 questions We evaluate every project against four dimensions before recommending a tool: Who is building it? Where do users live? How complex is the logic? Who owns it after go-live? Agent Builder Copilot Studio Azure AI Foundry Builder profile Maker, no code Developer / power user Pro developer, Python User surface M365 Copilot Chat Teams, web, M365 Copilot Custom app, any surface Logic complexity Simple Q&A, task routing Multi-step flows, connectors Fully custom orchestration Post-go-live ownership Business team IT + Business joint Engineering team Governance M365 Admin Center Power Platform DLP Custom, Azure RBAC When we recommend Agent Builder Agent Builder is the right call when the business team wants to own the agent end-to-end, the use case is bounded, and the users already live inside M365 Copilot Chat. The key advantage is distribution - an Agent Builder agent surfaces natively inside Copilot Chat with zero additional deployment work. No IT ticket, no app registration, no Teams app package. The ceiling is real. Agent Builder does not support complex branching logic, external API calls, or dynamic prompt injection. The moment a client asks "can it also update a record in our CRM?" the answer is usually no. Use it when: The maker owns it, the use case is narrow, and M365 Copilot is already the user's primary surface. When we recommend Copilot Studio Copilot Studio is our default recommendation for the majority of enterprise agent projects. It covers the wide middle ground between no-code simplicity and full-code flexibility - within the Microsoft governance perimeter most enterprise IT teams already control. Power Platform connectors - 1,000+ out-of-the-box connectors means most enterprise data sources are reachable without custom API development M365 Copilot channel - surface a Copilot Studio agent directly inside M365 Copilot Chat, Agent Builder-level distribution with enterprise-grade logic underneath Topic-level governance - fallback behaviors, confidence thresholds, escalation paths configurable without code DLP policy enforcement - the agent operates within the same data loss prevention perimeter as the rest of the Power Platform tenant The most common mistake: under-investing in the knowledge layer. The agent authoring is the easy part. Getting SharePoint content structured, metadata consistent, and documents deduplicated is where most projects hit delays. Budget for it. Use it when: The use case requires connectors, dynamic responses, or M365 Copilot integration - and you want IT to own governance without requiring a developer team. When we recommend Azure AI Foundry Foundry is the right call when you need to bring your own model, build a fully custom orchestration pipeline, or integrate into a surface that has nothing to do with Microsoft 365. In practice, this means one of three scenarios: The client has a model fine-tuned on proprietary data that must be used The agent is embedded inside a custom-built web or mobile application The logic requires Python-level control - complex reasoning chains, multi-agent coordination, custom evaluation loops Foundry projects require a professional developer, take longer, and produce something the business team cannot maintain without engineering support. That is not a reason to avoid it - it is a reason to be honest with the client upfront. Use it when: You need full control of the model, the orchestration, or the surface - and you have a developer team to own it. The question that resolves most debates When a client is torn between Copilot Studio and Foundry, we ask one question: "Who is answering the 2am support call when this breaks in production?" If the answer is a developer, Foundry is viable. If the answer is the IT admin or the business owner, Copilot Studio is the right call. Not because Foundry is unreliable, but because the operational model has to match the tool. More projects fail from ownership mismatch than from technical limitations. What we see go wrong Reaching for Foundry too early. Developers often want full control and reach for Foundry before validating the use case. We have rebuilt several Foundry POCs in Copilot Studio when the production constraints called for it - faster to ship and cheaper to run. Under-scoping Agent Builder. Business teams choose Agent Builder because it looks simple, then hit the ceiling at month two. The re-platform cost is higher than building in Copilot Studio from the start. Ignoring the M365 Copilot channel. Many Copilot Studio projects are deployed as standalone Teams apps when they could surface directly inside M365 Copilot Chat. The distribution advantage is significant and underused. The short version Agent Builder - maker-owned, bounded use case, M365 Copilot surface, fast Copilot Studio - IT + business joint ownership, connectors, production governance, M365 Copilot integration Azure AI Foundry - developer-owned, custom model or surface, full control, higher cost Start with the ownership model. Everything else follows. Elliot Margot - Team Lead Jumpstart, Copilot and Agents at Witivio (Microsoft Partner). Connect on https://www.linkedin.com/in/elliot-margot-52742a156/.
Giving AI Agent access to move files between folders
Hi Community, I have built a PDF to Excel reconcilliation AI Agent using Microsoft Copilot that reconciles supplier statements against payables data for our organisation. The agent works well. it reads PDF supplier statements and Excel reports from a SharePoint document library, performs the reconciliation, and produces a structured audit-ready report. However, I am hitting a limitation at the final step. Once the reconciliation is complete, I would like the agent to automatically move the processed supplier statement PDF from its current folder to a subfolder called "reconcilled" within the same SharePoint document library. My question is What is the recommended way to give a Copilot AI Agent the ability to move files between SharePoint folders? Any guidance, documentation links, or examples from others who have implemented similar workflows would be greatly appreciated. Thank you!
Copilot Studio Agent resetting when processing PDF drawings (300MB+) via Claude 4.6 Sonnet
Hello everyone, I am building an automated drawing review verification agent inside Copilot Studio using the Claude 4.6 Sonnet model. The goal of the agent is to read a comments package (20-40MB) and verify if those design comments were successfully incorporated into a milestone drawing set (300MB–400MB). When testing this workflow natively within Claude, the model handles the token load perfectly and returns an accurate compliance/incorporation summary within approximately 20 minutes. However, when running the exact same agent setup within Copilot Studio, the conversational canvas repeatedly crashes and resets the session. I suspect I am hitting the 100-second synchronous conversational timeout or overloading the chat runtime payload limits due to the massive file sizes. Because of corporate compliance policies, this agent must live within our Microsoft tenant so it can be scaled across our operations team via Microsoft 365. How can I fix Copilot Studio to have its performance match Claude's, as it is utilizing the same agent model. I am fairly new to working with AI but am willing explore any avenue as if I can figure out a solution this will help save a lot of time for colleagues. Thanks in advance for any insights!
Designing a Governed RTO Compliance Agent Using Copilot Studio and Databricks Genie
Enterprise AI adoption in HR scenarios comes with a unique challenge: how do you deliver actionable insights without compromising privacy, trust, or policy boundaries? In this blog, I’ll share how we built an RTO (Return‑to‑Office) Compliance Agent using Microsoft Copilot Studio and Databricks Genie, focusing on governance‑first design, controlled data access, and real‑world enterprise constraints. This solution was developed as part of an HRLT proof‑of‑value initiative and is designed to support people managers with clear, aggregated compliance insights, delivered conversationally inside Microsoft Teams. The Problem We Were Solving As hybrid work models mature, organizations need a reliable way to answer questions such as: How compliant is my team with RTO expectations? Are there trends across regions or time periods? Traditional dashboards often fall short because they: Require manual interpretation Expose too much granular data Are difficult to govern at scale Our objective was to create an AI‑powered conversational interface that provides: Only manager‑authorized, aggregated insights Zero visibility into individual‑level behavior Built‑in enforcement of HR and privacy policies Architecture Overview The solution integrates Copilot Studio with Databricks Genie, backed by curated data sources. (Image: High-level Copilot Studio and Databricks Genie architecture) Key Components Copilot Studio – Conversational orchestration, policy enforcement, and Teams deployment Databricks Genie – Governed natural-language interface to curated datasets RokFusion Platform – Trusted HR and badge-swipe data This layered approach ensures governance is applied before data is ever queried. Controlled End-to-End Data Flow The interaction pattern follows a strict, auditable flow: A manager asks a question in Copilot Studio Copilot forwards the request to Genie with instruction constraints Genie executes logic only on curated, approved tables Calculations are performed at team or manager level only Copilot formats and returns compliant responses (text, tables, or charts) At no point are employee IDs, badge events, or individual metrics exposed. Using Genie as a Governance Layer, Not Just a Query Tool One of the most critical decisions was to treat Databricks Genie as a policy‑enforcement layer, not merely a natural‑language SQL generator. (Image: Genie instruction configuration enforcing compliance rules) What We Configured in Genie Synonyms and NL mappings for HR terminology Strict filtering logic for employee categories Population threshold enforcement (minimum count) Explicit rejection of sensitive attributes such as gender, race, religion, or age Prevention of formula or row‑level data exposure This approach ensured that even malformed or risky prompts could not bypass policy constraints. Compliance Scenarios Supported The agent supports multiple business‑aligned interpretations of RTO compliance: Hybrid Compliance Hybrid employees counted only on eligible hybrid days Onsite Compliance Onsite employees counted across standard working days All Employees View Weighted aggregation combining hybrid and onsite logic These scenarios are embedded into the agent’s instruction logic, not dynamically inferred at runtime—ensuring consistency and auditability. Why We Chose Conversational AI Over Dashboards A key insight early on was that managers don’t want spreadsheets—they want answers. Instead of navigating filters and charts, managers can ask: “What was my team’s compliance last week?” “Show me a comparison across regions.” When required, the agent can also render simple visual outputs. (Image: Sample Microsoft Teams output with compliance visualization) Importantly, visuals follow the same governance rules as text responses. Publishing and Validation in Microsoft Teams Once configured, the agent was published directly from Copilot Studio to Microsoft Teams, making adoption frictionless. (Image: Publishing Copilot Studio agent to Microsoft Teams) End‑to‑end testing validated: Authorization boundaries Population rules Safe handling of incomplete or ambiguous queries Key Engineering Learnings Governance must be instruction‑driven Relying on frontend filtering alone is insufficient for HR data. Natural language needs strong guardrails Enterprise AI benefits from being constrained, not free‑form. Aggregation builds trust Managers are more comfortable with insights when they know individual visibility is impossible. Copilot Studio accelerates enterprise delivery Security, deployment, and integration stay within the Microsoft ecosystem. Closing Thoughts This RTO Compliance Agent demonstrates how Copilot Studio and Databricks Genie can be used to build governed, enterprise‑ready AI solutions—especially in sensitive domains like HR. By embedding policy into architecture, instructions, and data access, we were able to deliver: Useful insights Strong privacy guarantees High user trust This pattern is extensible well beyond RTO—opening the door for future HR intelligence use cases built on the same foundation.
