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

Question

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

Sohna Sukumaran Hemalatha 0

Summary

We are testing a Copilot 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

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

Issues observed

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.
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" buttons
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
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.

Sohna Sukumaran Hemalatha 0 Reputation points

2026-08-25T13:41:44.6033333+00:00
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).
Ashlesha Pawar (Tata Consultancy Services Limited) 395 Reputation points Microsoft External Staff

2026-08-26T07:07:27.7233333+00:00
Hello,

Thank you for reporting this. Since there appear to be three separate behaviors, I recommend testing each one independently to determine whether the issue is related to deployment/client state, authentication, or SharePoint retrieval.

Issue 1: Agent visibility

Confirm the affected user is included in the agent's assigned audience.

Open Microsoft 365 Copilot in an InPrivate/Incognito session and check whether the agent is visible.

If not, refresh or sign out/in and check again.

Please note the approximate publish/assignment time and when the agent becomes visible.

If the agent is still unavailable in a fresh session, please provide a screenshot and timestamp.

Issue 2: SharePoint consent

Using a test user with access to the SharePoint content:

Start a new conversation in Teams or Microsoft 365 Copilot.

Ask a question that requires the SharePoint source.

Check whether the consent card and Allow/Connect option are displayed.

Repeat the test after refreshing the client or using an InPrivate/Incognito session.

Please also verify the agent's Copilot Studio > Settings > Connection Settings and confirm that the Production authentication/connection is valid.

If the consent card appears only after refresh/sign-in, please provide the screenshot, timestamp, client (Teams/Copilot/browser), and Conversation ID.

Issue 3: SharePoint knowledge retrieval

To isolate the two knowledge sources, please create two uniquely identifiable test documents:

Indexed: INDEXED-TEST-92741 – The answer is Cedar.

Live: LIVE-TEST-68352 – The answer is Maple.

Then:

Confirm the affected user can access both documents.

Confirm the indexed source is Ready in Production.

Allow sufficient time for the indexed content to synchronize.

Start a new conversation and test each document separately.

If possible, repeat the test with the same user and prompt.

If the issue persists, please provide detailed reproduction steps, including the client used, exact prompt, expected vs. actual behavior, and any relevant screenshots or error messages. We will use these steps to attempt reproduction from our side.

Thanks!

1 answer

Your answer

Sohna Sukumaran Hemalatha 0 Reputation points

2026-08-25T13:41:44.6033333+00:00

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).

Answer 1

Yes. The behavior described matches documented platform limitations and known deployment/runtime issues rather than a simple misconfiguration.

What is currently known:

Newly published agents might not appear immediately For Employee Self-Service agents, publishing can take up to 48 hours before the agent appears in Microsoft Copilot. A documented workaround is to download the manifest in Copilot Studio and upload it manually to Integrated Apps in the Microsoft 365 admin center.
Teams and Microsoft 365 Copilot deployment has known channel issues In multitenant mode, Copilot Studio has known issues including:
- makers can't unpublish an agent from the Microsoft 365 Copilot channel
- Teams and Microsoft 365 Copilot channels can't be managed independently outside the channel checkbox
- turning off the Teams channel can disrupt service and might require publishing again
Teams has persistent-session behavior that can cause stale state Teams conversations persist across days, and ConversationStart fires only the first time the agent is added. Reinstalling the app doesn't retrigger it. This can lead to:
- stale context
- token expiration
- outdated cached content
- users continuing to interact with outdated logic
This aligns with the pattern where sign-out/sign-in or app restart temporarily restores expected behavior.
SharePoint knowledge retrieval can fail at runtime for user-specific reasons For declarative agents grounded in SharePoint, runtime failures can occur when:
- the signed-in user doesn't have a Microsoft 365 Copilot license
- the user can't access the SharePoint site URL defined in items_by_url
- the agent connection isn't using User authentication
- the user lacks at least Read permission on the SharePoint site
SharePoint knowledge sources can silently return no results when authentication is incomplete If the app registration or agent authentication is missing required scopes, the agent can return no results with no explicit error. For SharePoint, the minimum required scopes are:
- Sites.Read.All
- Files.Read.All and those scopes must also be present in the agent authentication settings together with profile and openid, with consent granted.

Based on the symptoms, the most relevant checks are:

Allow more time for visibility before broad rollout Immediate visibility after admin approval is not guaranteed in all cases. If the deployment path depends on publishing into Microsoft 365 surfaces, delayed appearance is a known issue.
Validate SharePoint retrieval prerequisites per affected user For each user who gets incomplete results:
- confirm the user has an active Microsoft 365 Copilot license
- confirm the user can open the target SharePoint site directly
- confirm the agent connection uses User authentication
- confirm the user has at least Read access to the SharePoint site
Review the SharePoint authentication configuration If Knowledge source 1 depends on SharePoint authentication, verify the app registration and agent authentication include Sites.Read.All, Files.Read.All, profile, and openid, and that consent was granted. Missing scopes can produce exactly the “connected but no results” behavior.
Account for Teams session persistence during pilot testing Because Teams keeps long-lived conversations and cached state, pilot users can see inconsistent behavior after deployment updates. For validation, test with fresh sessions after publish changes and avoid relying on existing conversation threads as proof of current behavior.
Escalate third-party identity/SSO issues if applicable If the consent-card problem is tied to third-party IdP or SSO topology, that area is explicitly noted as not fully evaluated for every configuration topology, and the guidance is to submit a Microsoft support case.

For the rollout question: documented issues show that organization-wide launch is possible, but delayed visibility, stale client state, and SharePoint runtime/authentication dependencies can affect end-user experience during admin-based deployment. The sign-out/sign-in workaround is consistent with the known client/session behavior, especially in Teams.

References: