Forum Widgets
Latest Discussions
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.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!File Uploads Not Passed to Custom Engine Agent in Microsoft 365 Copilot Chat
Hi all, I'm working with a custom agent built in Copilot Studio (full authoring experience — topics, knowledge sources, agent flows) published to both the Microsoft Teams channel and the Microsoft 365 channel. I've noticed a significant UX discrepancy when it comes to file and image attachments, and I want to confirm my understanding and check whether any workaround or roadmap item exists. What works: ✅ File/image uploads work as expected in the Copilot Studio test pane ✅ File/image uploads work in Teams chat when interacting with the agent What doesn't work: ❌ File/image uploads do not reach the agent when interacting via the Microsoft 365 Copilot app (both the desktop app and the web experience at microsoft365.com) The UX problem: The M365 Copilot app presents a "+" button in the chat input area with options including "Upload" and "Take screenshot." Users naturally assume these options work. The file even appears as an attachment in the sent message — but the agent never receives it. There's no warning, error, or indication to the user that the attachment was silently dropped. This creates a misleading experience, particularly for end users who have no visibility into the channel behavior differences. What I've found so far: I'm aware this is documented as a known issue for custom engine agents in the Microsoft 365 Copilot Extensibility Known Issues page: "File attachments — Users can't upload files in agent chats and the agent can't return files for download." I also found a related GitHub issue (OfficeDev/microsoft-365-agents-toolkit #15325) where a Microsoft team member confirmed this is a "Copilot platform shortage" — not an Agents Toolkit issue — with no published ETA. My questions for the community and any Microsoft product team members: Is there any currently supported workaround to enable file/image input for a Copilot Studio agent running in the M365 Copilot app (desktop or web)? For example, any manifest configuration, agent settings, or alternate approach? Is this limitation being actively worked on? Is there a roadmap item or Microsoft 365 feature ID that can be tracked for when file attachment support is extended to custom engine agents in the M365 Copilot chat experience? Is the UI behavior (showing upload options that don't work) being addressed separately? Even if full file processing isn't ready, a visible warning or disabled state in the UI would significantly reduce user confusion. Any insight from others who have hit this — or from Microsoft PMs — is appreciated. Happy to share more configuration details if helpful. Thanks! Brian
All Copilot Studio Workflow Tools Suddenly Returning HTTP 403 Before Execution
Hello Copilot Studio Community, I am experiencing an authorization issue with multiple workflows connected to an agent built using the Copilot Studio new experience and new Workflows experience. These workflows worked successfully for multiple users yesterday. Today, all workflow tools connected to the agent began returning an immediate HTTP 403 authorization error. I did not intentionally change the agent, workflows, environment, or workflow permissions before the issue started. Error message: You don’t have permission to use this tool. You’re signed in, but access to this resource is blocked. Error details: Authorization - 403 Example error information: Status: Failed Error message: Flow returned HTTP 403 Error code: Http403 Inner error code: NotSpecified Tool duration: Approximately 93 milliseconds Configuration: - Copilot Studio new agent experience - Copilot Studio new Workflows experience - Agent and workflows are in the same Power Platform environment - Workflows use the "When an agent calls the workflow" trigger - Each workflow includes a "Respond to the agent" action - Workflows are saved and published - Agent is saved and published Observed behavior: The problem affects several independent workflows, including: - New-request submission - Current-user identity resolution - Approval decisions - Requester justification - Executive decisions - Fulfillment updates For every affected workflow: - The agent fills the workflow inputs correctly. - The tool call fails almost immediately. - No corresponding run appears in the workflow Activity history. - The workflow trigger is never reached. - No workflow actions execute. Because no workflow run is created, the rejection appears to occur before workflow execution, possibly within the Copilot Studio agent-to-workflow authorization or invocation layer. Troubleshooting already completed: - Confirmed that all workflows are published. - Confirmed that the agent is published. - Tested in a completely new conversation. - Removed an affected workflow tool from the agent. - Saved the agent. - Added the same published workflow back to the agent. - Reconfigured and verified the tool inputs. - Republished the agent. - Confirmed that no workflow Activity run is created. - Confirmed that the issue affects multiple workflows rather than one specific workflow. Removing and re-adding the workflow did not resolve the problem. Questions for the community: 1. Is anyone else currently experiencing HTTP 403 errors when Copilot Studio agents invoke workflows? 2. Is this a known issue or regression in the new Workflows experience? 3. Is there an environment-level or tenant-level permission that controls agent-to-workflow invocation? 4. Could a tenant policy, Conditional Access change, service principal, connection reference, or workflow-sharing configuration cause all workflow tools to fail simultaneously? 5. Where can an administrator find detailed authorization logs when the workflow never creates a run? 6. Has anyone found a workaround for this issue? Any guidance or confirmation from others experiencing the same behavior would be appreciated. I can provide screenshots, complete error details, timestamps, and additional configuration information if needed. Thank you.What is the best file format for an AI agent knowledge base?
This is a best practice sharing the best format for an agent and show you why you should convert your PPT, PDF, WORD into a TXT markdown. I had an issue with my agent, time taken to answer was too long, and usually we spend a lot of time asking: What is the best prompt? Why is my agent slow? Why does retrieval sometimes work and sometimes fail? How can I improve answer quality? But I realised I was asking another question much less often: What is actually the best file format for the knowledge base? PDF? Raw text? Markdown? Pre-chunked text? Semantic sections? Context-enriched text? And more importantly: How much does the format alone affect agent performance? I tried to find a quantified benchmark answering this specific question, with the same agent, same source knowledge and same questions, but different knowledge representations. I couldn't find one that really answered what I wanted to measure. So I decided to run the experiment myself on a real case. My first exploratory tests were already surprising: depending on the representation, the agent could be significantly faster and more accurate, despite working from the exact same source information. So I decided to push the test further. My objective I want to identify, without assumptions and based on actual evaluation data, how a long document should be prepared for an LLM knowledge base so that the agent can retrieve, understand, ground and answer from it as reliably as possible. I focused on five dimensions: Answer quality Retrieval reliability Source grounding / citations Execution time Robustness across single-turn and multi-turn questions The broader question I'm trying to answer is: How should we structure knowledge so that an LLM can retrieve and use it as reliably as possible? The test case I deliberately chose a document that isn't particularly friendly for RAG: a 46-page European regulation, https://eur-lex.europa.eu/eli/reg/2011/1169/oj?locale=fr, on the provision of food information to consumers. The information is distributed across articles, definitions, exceptions, annexes, tables, numerical thresholds and cross-references. That makes it useful for testing retrieval: answering correctly often requires finding a very specific piece of information while preserving enough context to understand how it applies. I used the native PDF as the baseline and created 6 additional knowledge-base representations of the same document: Raw TXT Markdown Chunk-ready TXT RAG-oriented units Semantic TXT Contextual TXT One rule: same knowledge, same agent, same instructions, same questions. Only the knowledge representation changes. The benchmark I used two evaluation sets: 42 single-turn questions testing broad coverage of the document: direct facts, thresholds, exceptions, annexes, lists and cross-references. 5 multi-turn conversations containing 13 questions, to see what happens when a user asks a question and then follows up with things like: "And in this case?" "What are the exceptions?" "And for dietary fibre?" This gave me: 47 evaluated test cases / 55 actual questions per format Across all 7 formats: 329 evaluated conversations 385 user questions executed First results Metric Native PDF Best structured representation Overall pass rate 66.0% 85.1% - Contextual TXT Best single-turn score 69.0% 88.1% - Chunk-ready TXT Multi-turn benchmark 40% 80% - Contextual TXT Multi-turn execution time 14m24 5m54 Total benchmark time 44m31 24m49 The quality gap was already substantial: 66.0% → 85.1% That's +19.1 percentage points while keeping the underlying knowledge unchanged. I also saw a major difference in execution time. On the multi-turn test: 14m24 → 5m54 That's approximately 2.4× faster. Across the complete benchmark: 44m31 → 24m49 Around 44% less execution time. These timings represent the complete agent evaluation pipeline, so they shouldn't be interpreted as pure LLM inference latency. But the difference under identical test conditions is large enough that I want to understand it better. Findings There wasn't one format dominating every benchmark. Chunk-ready TXT scored highest on independent questions: 88.1%, while Contextual TXT performed better across multi-turn conversations and finished with the highest overall score. That may suggest that the way we optimise a document for isolated retrieval isn't exactly the same as the way we should prepare it for conversational retrieval. In the contextual version, I tried to make every section understandable when retrieved independently by keeping useful information around it: Source references Section context Retrieval cues Relevant cross-references For regulatory documents, this seems particularly important. A numerical value retrieved alone can be meaningless without knowing which rule it belongs to, under which conditions it applies, and whether another article contains an exception. Where I am now This remains an exploratory benchmark: One document One domain One agent setup One evaluation framework One run per configuration There are plenty of things I still want to test: repeated runs, retrieval-level evaluation, token consumption, larger knowledge bases, other document types, chunk sizes, overlap, contextual headers, and more. But these first results already convinced me that the preparation of the knowledge base deserves much more attention when evaluating an agent. We often spend hours refining instructions while the same information may behave very differently depending on how it reaches the retrieval layer. Next step I'll share the prompts, knowledge-base formats and evaluation methodology on GitHub so the experiment can be reproduced and challenged. I'll keep enriching the repository as I test new formats, improve the evaluation set and add new results. If people here have ideas, edge cases or formats worth testing, I'd genuinely like to include some of them in the next iteration. What would you test next?Unanswered Questions on GitHub Copilot Harness in Copilot Studio
We're piloting the GitHub Copilot harness in Copilot Studio (GA August 2026) and several operational and architectural details remain undocumented in the GA FAQ, Microsoft Learn, or licensing guides. Looking for official answers or PM contacts on: Architecture & Execution – When the harness breaks tasks into subtasks, does it use internal sub-agents or only skills/connected agents, what are the exact timeout/retry/max-execution-duration limits for long-running workflows, and are planning/context-retrieval/orchestration internals documented anywhere or is the orchestrator a black box? Model Selection – Can individual skills within one agent use different models or is selection strictly agent-level, how are models chosen internally when multiple skills execute, are any internal models developer-configurable, and what's the roadmap for models being added/retired/deprecated plus the lag between public release and Copilot Studio availability? Cost & Token Optimization – How exactly is the ~45% token reduction achieved, how much control do makers have over context/caching/retrieval/tool calls, what are per-model credit consumption characteristics, which models are most cost-effective for specific workloads, and what's the minimum credit cost for trivial interactions? Memory Management – What are retention periods for session/working/agent memory beyond the documented 28-day user-memory expiry, is true long-term memory supported, and what changed versus earlier implementations? Knowledge Retrieval – Can skills or system instructions influence retrieval strategy/document selection/prioritization/filtering, can planning stages perform conflict/duplicate/version detection before retrieval, and how does the harness decide which sources to search? Apps Feature – What is the "Apps (preview)" capability for, when does it GA, and how does it differ from workflows/skills/adaptive cards/agents? Billing & Credit Sizing – Is there a framework to classify users/agents by expected consumption and size credit allocation per group (citizen vs pro developers), and what's the minimum/typical consumption for simple/medium/heavy interactions? Governance & Admin – Can usage limits be set at user level (not just environment/agent), is there an API/IaC path for large-scale credit assignment, can non-admins view their own consumption/remaining allocation, and is there a self-service request-more-credits dashboard? ALM & Environments – What's the recommended path to move harness agents across Dev/Test/UAT/Prod (Solutions/ALM "setup differs" per parity chart—how?), does GitHub integration replace or complement solution-based deployment, are there recommended AgentOps practices for source control/releases/versioning, and what baseline credits and onboarding model are suggested for citizen developers under usage billing—any enterprise reference implementations?Fix: Hyperlinks render as plain text in Copilot app (but work in the test pane in Copilot Studio)
My use case SharePoint knowledge-retrieval agent built in Copilot Studio to answer employee questions from internal policy and guidance documents. These documents, in addition to text content, contain embedded hyperlinks to internal apps and resources (intranet pages, expense app, ticketing tools etc.). It was important for these links to be surfaced in the agent response so employees can directly follow the link - so they needed to be clickable hyperlinks, otherwise the answer was effectively incomplete. Note that I am not using specific topics/actions to create generative answers. I'm relying solely on instructions. The problem Hyperlinks from the source documents appeared as clickable links in Copilot Studio test pane, but when the same agent was published and accessed via the M365 Copilot app, the links were displayed as plain text - not clickable. My original instructions told the agent to include hyperlinks in content & I also verified that the hyperlinks in the source documents were all absolute URLs. 🙌 What changes finally worked Keeping the original "include links" directive and adding a strict formatting rule that requires both Markdown formatting and an HTML <a> tag wrapper, with the URL preserved exactly. The final instruction lines I included: If hyperlinks are contained within the source content and related to the answer, ALWAYS include them in the response. ALWAYS format the link as full Markdown and preserve the URLs exactly within an HTML <a> tag. What was the problem Copilot Studio is a forgiving renderer. M365 Copilot app uses a stricter markdown rendered that can supress hyperlinks that don't come be default in the format it expects. Hence, including an explicit hyperlink formatting in the instructions helps. I hope this helps someone and saves a few hours in troubleshooting the issue 😉📣 Microsoft Copilot Studio and Agent Roadmaps Have a New Home
Microsoft Copilot Studio and Agent Roadmaps Have a New Home Starting July 2, 2026, feature updates for Microsoft Copilot Studio, Sales Agent, Finance Agent, and Service Agent, will be published on the Microsoft 365 Roadmap. This creates a single destination to discover what capabilities are coming next across Microsoft 365 core apps, Copilot, agents, and more. As part of this transition, Release Planner will no longer be a source for feature information for these products. Future updates will be available through the Microsoft 365 Roadmap, making it easier to stay informed, plan ahead, and leverage AI-powered experiences that can discover and consume information more effectively. What you need to know No immediate action is required Update any saved Release Planner bookmarks to the Microsoft 365 Roadmap Begin using the Microsoft 365 Roadmap as your primary source for feature updates Share this change with stakeholders who currently rely on Release Planner Resources: Stay up to date on what’s new and what’s next: Microsoft 365 Roadmap Microsoft 365 Copilot release notes Microsoft 365 Copilot Roadmap Webinar - Register today Get started with AI-powered change insights: Microsoft MCP Server for Enterprise - Gives MCP-compatible AI tools secure, read-only access to your organization’s Message Center and Service Health data, enabling personalized summaries, impact analysis, and stakeholder communications based on your existing permissions and security controls. Microsoft Release Communications MCP Server - Provides free, natural-language access to official Microsoft 365 Roadmap and Azure Updates information, enabling AI agents to answer questions about upcoming features, rollout timelines, and product changes. We're excited to bring roadmap information together in one place to deliver a more consistent, accessible, and AI-ready experience for planning what's next.
