Forum Discussion

sohnash's avatar
sohnash
Iron Contributor
Aug 25, 2026

Intermittent Post-Deployment Issues with Copilot Agent Using SharePoint Knowledge Sources

Summary

We are testing a Copilot Studio agent following admin approval and installation for a set of users before we launch it to everyone in the organization - the objective being to test out the end user experience and check that everything is working fine.

We have encountered several inconsistent behaviours using the agent across both the Copilot app and Microsoft Teams. The issues seem to be resolved after signing out, restarting the application, or signing in again.

📍Looks like a lot of instabilities and poor end user experience with this method & this is blocking us from launching the agent to the organization.

Agent Setup

  1. Agent built in Copilot Studio & deployed via pipeline (Development > QA > Production)
  2. Knowledge source 1: SharePoint connection using Dataverse indexing/synchronisation
  3. Knowledge source 2: Live SharePoint connection
  4. Tested in the following apps after admin approval/publishing/pinning:
    • Microsoft Copilot app
    • Microsoft Teams

Issues observed

  1. Agent not visible in Copilot app
    1. After agent is approved, installed, shared and pinned (to specific users) from Admin side, the agent is not visible in Copilot app. We gave it over 8 hours after the admin process.
    2. Agent appeared after signing out of Copilot app and signing back in again.
  2. SharePoint connection consent prompt not displayed
    1. Users are expected to receive a prompt with consent to connect to SharePoint (with "Allow" button). What appears is only a message but no card with the "Allow" button.
    2. This started working after signing out of Copilot app and signing back in again - so the sign out + sign in had to be done twice
  3. Responses not retrieved from Knowledge source 1
    1. In spite of proceeding with the "Allow" prompts, for some users, the responses are coming only from Knowledge source 2 (live connection) & not Knowledge source 1 (connection with dataverse indexing). This is seen both when interacting with the agent in Copilot app and Teams.
    2. For some users, this was fixed after signing out and back into the apps

Questions

  • Has anyone experienced such instabilities with admin deployment/publishing of agents?
    • If yes, what have you done to sort them out and have you been able to successfully launch agents organization wide with this approach?
  • Does anyone know about known issues/glitches with admin deployment/publishing of agents? We did not see these issues when sharing the agent using Copilot Studio.
ai agents
copilot studio
microsoft 365 copilot

2 Replies

  • sohnash's avatar
    sohnash
    Iron Contributor
    Aug 25, 2026

    Thank you for sharing your inputs, CoralieSimonaire​ ! Hope you are well too 😊

    I agree with you that this seems related to client-side caching. The multiple sign out and sign ins are the biggest hindrances for adoption at this point.

    To add on - The agent was visible in Copilot on the browser. But the SharePoint connection consent card didn't display. I had to get some users to refresh the browser for the connection prompt to be displayed. Now, I'm also seeing a behavior that the agent retrieves from Knowledge source 1 (and not Knowledge source 2).

    Previously for the testing and pilot of this agent, I was publishing the agent directly in Copilot Studio through Microsoft 365 and Teams channels. These issues didn't come up then (occasionally apps needed a restart but that was all - there was never any inconsistency in establishing connection or in the responses).

    👉 I've just been suggested (through Q&A forum in Microsoft Learn) to wait up to 48 hours since publishing for the agent to appear in Copilot. So I'm going to give that a try and check if these caching related issues go away. I'll post updates on this thread.

  • CoralieSimonaire's avatar
    CoralieSimonaire
    Brass Contributor
    Aug 25, 2026

    Hi Sohnash, 

    I hope you're doing well ? 

    Yes, I've already seen similar behavior when deploying Copilot Studio agents published to Teams and Microsoft 365 Copilot.

    What makes me think this is related to propagation or client-side caching is the fact that the agent becomes visible after signing out and back in, and that some of the issues disappear after users reconnect to Teams or Copilot.

    Microsoft documents several scenarios where an approved or published agent does not appear immediately because of client-side caching and recommends signing out and signing back in.

    It documents a known issue where Teams may temporarily continue using a previously published version of an agent after it has been published or republished.

    However, I haven't found any source that specifically describes the SharePoint consent card not being displayed or a specific malfunction affecting a Dataverse-indexed SharePoint knowledge source.

    For those aspects, I would focus on validating the authentication configuration, user/admin consent, SharePoint permissions, and any propagation delays affecting the environment.