Forum Discussion
Copilot Studio agents problems connecting to Sharepoint knowledge source
Hello,
Since last week users in my tenant are experimenting issues regarding the connection between copilot studio agents and Sharepoint. The agents are not able to extract information from Sharepoint sites, printing there is not information in the Sharepoint site regarding the user's question when that information is in Sharepoint. These agents used to work well till last week. Does have been any update in Microsoft 365 services that can be affecting these agents ability to retrieve information from Sharepoint?
15 Replies
Could someone please explain why I need to sign in for Copilot every time I need to use it throughout the day? I usually sign in first thing in the mornings.
I'm experiencing exactly the same issue. Our Copilot Studio agent was working perfectly with its SharePoint knowledge source — it was still fine up until this Tuesday, then suddenly stopped retrieving any SharePoint content.
Same symptoms as described here:
- The knowledge source still shows as "Ready" and the connection looks healthy
- The content is fully searchable and openable directly in SharePoint (same account), so it's not a permission issue
- It fails in both the published production version and the test environment
- The agent triggers the SharePoint source but returns zero matches, even for phrases that appear verbatim in the files
I've already tried refreshing and re-adding the SharePoint knowledge source with no effect. Has anyone found a resolution on this? Thanks!
Possible Workaround / SolutionI found a few things that may be related to this issue. I’m sharing them here in case they help others facing the same problem.
1. XLSX files are not always retrieved
If your knowledge source contains an XLSX file, the agent may sometimes fail to retrieve information from it. In my case, the agent was working previously, but it sometimes stopped retrieving content from the XLSX file without showing any explicit error.
2. Direct file path vs. folder path
I also noticed different behavior when using a direct path to a DOCX file versus the folder path.
Not working – Direct file path:
https://example.sharepoint.com/sites/SiteName/Shared Documents/FolderA/Document.docx
Working – Folder path:
https://example.sharepoint.com/sites/SiteName/Shared Documents/FolderA/
The direct DOCX file path was working previously, but it is no longer retrieving the content for me. Using the folder path works instead.
3. Encoded URL vs. normal SharePoint path
I also noticed that the URL-encoded SharePoint path that was working previously is no longer working.
Not working:
https://example.sharepoint.com/sites/SiteName/Shared%20Documents/FolderA
Working:
https://example.sharepoint.com/sites/SiteName/Shared Documents/FolderA/
So, changing the path from the encoded format (%20, %26) to the normal SharePoint path with spaces and special characters resolved the issue in my case.
Summary
Based on my testing:
- XLSX knowledge sources → Retrieval can be inconsistent.
- Direct DOCX file path → Previously worked, but currently not working for me.
- Folder path → Working.
- URL-encoded folder path → Not working for me.
- Normal SharePoint folder path → Working.
These are observations from my environment, so I’m not sure whether this is a permanent fix or a temporary workaround. Hopefully, this helps others troubleshoot the same issue.
cc: jferCould you please try testing with a different folder from the same SharePoint site and let me know whether it works?
I’m facing the same issue as well. In my case, some folders from the same SharePoint site are working correctly, while another folder is not returning any results.
It would be helpful to know if you observe the same behavior with different folders.
I'm indexing at site level, not folder level
Having the same issue here. I've created new agents for testing and all failing to return information. nothing changes in the tenant, nothing changed in the agent. not really an opportune time for Microsoft to be testing in production.
I would start with one affected agent and one known SharePoint page that used to answer correctly. Re-index or refresh that knowledge source, then ask the agent a question whose answer appears verbatim on the page. In parallel, test whether the same user can find that content through Microsoft Search and open the file or page directly. If direct access and Microsoft Search work but the agent still answers as if the content is missing, collect the agent ID, SharePoint site URL, failed prompt, timestamp, and environment region for a Microsoft support case. That evidence points to retrieval rather than permissions.
Thanks for the detailed troubleshooting,
This issue has now expanded and is currently affecting all users and all agents across our environment. Direct access and Microsoft Search continue to work as expected, but retrieval through Copilot Studio fails across the board.
We followed this path and gathered the necessary evidence (Agent IDs, SharePoint site URLs, timestamps, failed prompts, and region details), and a support ticket with Microsoft has officially been opened.
I see from the previous reply that you are using the classic experience and not the new experience.
A few other things to check (if you haven't already), jfer .
- If you search for content directly using SharePoint search, is that returning results? This is to check the default search behavior
- In Copilot Studio > Knowledge > Is the status of all knowledge sources showing as "Ready"?
- What is the behavior when you test the agent straight in Copilot Studio Test Pane? Can you see that it is triggering your configured SharePoint knowledge sources? Is that giving your responses?
- Test it in Production, Test/QA and also Development
And I agree with the earlier recommendation to open a support ticket with Microsoft!
1- Yes it is returning results.
2- Yes they are showed as ready
3- It is triggering sharepoint but then the answers say there is not content related in Sharepoint. Same in Dev environment.
Hello,
Since this is a sudden regression affecting multiple agents simultaneously across your tenant (agents that previously worked), one question first:
Which Copilot Studio experience did you use to build your agents — the classic experience (canvas with topics) or the new experience (production-ready preview)?
Microsoft's documentation confirms that some SharePoint features are not yet available in the new experience, and authentication and retrieval behaviors can differ between the two...
This will help narrow down the diagnosis.
In parallel, here are the points you can check :
- If a tenant admin recently enabled Restricted SharePoint Search, SharePoint access is completely blocked for Copilot Studio agents. Check : SharePoint Admin Center > Search > Restricted SharePoint Search.
- If a SharePoint site or folder used as a knowledge source was recently renamed, the existing source link breaks and causes a permission gap the agent silently returns no results.
Verify that the SharePoint URLs configured in your agents still match the current site/folder names.
- Check your M365 Admin Center > Health > Service health for any active incidents related to Copilot Studio or Microsoft Search.
- Verify that your Entra ID app registration still has Sites.Read.All and Files.Read.All granted. If consent was silently revoked, the agent returns no results without surfacing any error.
- A service-side indexing change can silently interrupt SharePoint content retrieval with no visible alert.
The recommended next step is to open a support ticket via the M365 Admin Center, referencing the exact date the regression started, so Microsoft can correlate it with any service-side changes on their end.
Hope you find this useful
We are using the classic experience.
About Restricted SharePoint Search, this is retired and we have not enabled the RCD at any moment.
No sites were renamed or links changed, also it is affecting multiple sites.
Service Health is correct, there are some advisories but not related.
Entra ID App registration is not realted, we are using M365 suite with Copilot Studio, an app was not created for this.
