HI
@VK-16022053-0,
The behavior you're describing is actually a strong clue: this is probably not a problem with the list itself or with publishing.
For SharePoint Lists used as a Copilot Studio knowledge source, the query is evaluated using the user's SharePoint credentials. Microsoft documents that the list connection is real-time and that users are authenticated with their SharePoint credentials before content is returned. If the user doesn't have access, Copilot Studio can effectively return no results rather than an obvious authentication error.
So I would troubleshoot this as a user-context authentication/permission issue.
1. Verify the colleague can read the list itself
Don't only check site membership. Test with the affected colleague's account:
-
Open the exact SharePoint list URL directly.
-
Open a few specific items.
-
Confirm they have at least Read permission on the site/list.
-
Check for unique item-level permissions.
-
Check whether the list has any item-level security that differs from your account.
Microsoft specifically states that SharePoint knowledge sources respect the user's permissions and require at least Read access to the SharePoint site/list.
2. Check the agent authentication configuration
Go to:
Copilot Studio → Settings → Security → Authentication
If the agent is intended to retrieve SharePoint data for each user, make sure it isn't configured as No authentication.
For Teams / Microsoft 365 / Power Apps, Copilot Studio normally uses Microsoft authentication for SharePoint sources. Microsoft also notes that selecting No authentication means the agent doesn't retrieve information from SharePoint.
If you are using Authenticate manually, check the Entra app registration and scopes. Microsoft currently documents Sites.Read.All and Files.Read.All for this scenario, along with the corresponding scopes in the Copilot Studio authentication configuration. Missing scopes or consent can produce exactly the confusing behavior where the agent returns no results without an obvious error.
3. Check whether you're testing with different authentication contexts
This is an easy one to miss.
You are the agent maker, so your successful test may be using your own authenticated SharePoint context, while your colleagues are being permission-trimmed using their own identities.
I'd run a very simple test with a list containing something unmistakable:
TestID | Name
001 | COPILOT_TEST_ABC
002 | COPILOT_TEST_XYZ
Ask both accounts:
"What is the Name for TestID 001?"
If you consistently get the result with your account and "no results" with another account, that strongly isolates the issue to the end-user SharePoint authentication/authorization path rather than generative AI or the list structure.
4. Check Restricted SharePoint Search
Also verify that Restricted SharePoint Search isn't enabled in the tenant. Microsoft documents that when it is enabled, SharePoint knowledge-source access is blocked and can result in no results.
5. One important distinction
If your colleagues can open the list in SharePoint but the agent still returns nothing, I would next compare the actual authentication configuration rather than changing the list.
Specifically compare:
Your account
↓
Copilot Studio authentication
↓
SharePoint
↓
List
↓
Results
Colleague account
↓
Copilot Studio authentication
↓
SharePoint
↓
List
↓
"No results"
The fact that two completely different SharePoint Lists fail for the same colleague(s) is important. It makes a list-specific schema/indexing problem much less likely.
I'd also test one affected colleague in the same Teams/M365 channel, rather than the Copilot Studio test pane, because the authentication context can differ between the maker test experience and the end-user channel.
If the colleague can access both lists directly in SharePoint, the agent is correctly authenticated, and the same published version still returns no results only for that user, I'd capture a successful run from your account and a failed run from theirs and raise it with Microsoft as a SharePoint knowledge-source user permission/authentication trimming issue.
The key point is: SharePoint List knowledge is intentionally user-permission-aware, so "I can retrieve it but another user can't" is not expected to be solved by republishing the agent.
