Official documentation checked October 14, 2026.
A SharePoint sign-in failure in Copilot Studio can come from the connection, the account used by a tool, a resource permission, or a channel requirement. It does not automatically require a new Entra app registration or tenant-wide Microsoft Graph permissions.
Start with the exact failing operation. Do not grant Sites.ReadWrite.All, give the agent a site administrator’s connection, or turn off Conditional Access simply to see whether an error disappears.
1. Distinguish a SharePoint tool from a knowledge source
A SharePoint connector tool performs an operation such as reading a list item. A SharePoint knowledge source supplies content for generated answers. A custom connector or HTTP action that calls SharePoint is a third implementation, with its own authentication definition.
Open the agent and identify whether the failure is attached to a tool on the Tools page, a source on the Knowledge page, or an action in a flow. Record the environment, published channel, connector/operation name, account, timestamp, and exact error. A generic no answer from knowledge retrieval is not the same evidence as a connector’s 401 response.
Microsoft explicitly separates the manual-authentication instructions for SharePoint knowledge sources from Power Platform connectors. Do not copy that article’s app-registration scopes into an unrelated connector repair. If you are troubleshooting knowledge retrieval instead, follow its current authentication and source-access requirements.
2. Check the existing connection and intended account
- For a connector tool, open the agent’s Settings > Connection Settings and locate the connection used by the failing tool.
- Review its status. Use the status link to reconnect or choose the intended connection if it is expired, stale, missing, or bound incorrectly.
- Sign in with the account and tenant that the design actually requires. Complete legitimate consent and multifactor-authentication steps.
- Return to the tool and test a harmless read against an approved test item before trying any update or deletion.
These controls are documented in managing agent connections. When adding a replacement tool, the supported entry point is Tools > Add a tool > Connector, followed by the SharePoint operation and its connection. See connector-tool setup.
Confirm whether the tool uses the end user’s credentials or a deliberately approved maker-provided connection. Do not assume that the agent creator’s successful test proves another user’s access. Substituting the maker’s account can disclose records the user cannot otherwise read; Microsoft documents that risk in its maker-credential guidance.
3. Verify the SharePoint resource and policy result
Using the same intended account, open the target SharePoint site and the exact list, item, or file in a browser. Check the connector’s Site Address and resource inputs against the real location. A missing dropdown entry is not proof that the site does not exist; guest accounts and connector limitations can affect discovery.
If direct access is denied, ask the resource owner whether this account should have access. Grant only the access required for the approved task through normal administration. Do not make a reader a site administrator or add write permissions for a read-only operation.
If direct access works but the connector fails, keep the error code and provider details. A 401 or 403 is a useful clue, not a unique diagnosis. Ask the identity administrator to check the corresponding sign-in and policy result. Microsoft’s SharePoint connector reference notes that policies such as multifactor authentication and device-compliance requirements can affect connector access.
For a custom HTTP or custom-connector implementation, the API owner must separately verify the requested resource, token audience, grant, and permissions. Do not assume that changing the site URL changes the token’s audience. A built-in SharePoint connector is not repaired by inventing an app with the bot’s name or copying a broad permission list from another integration.
4. Test the actual channel and preserve the access boundary
After saving an approved configuration correction, publish it through your normal release process and test a fresh conversation in the channel users actually use. The agent does not need to be published to the same SharePoint site merely to make a connector token valid. Adding the site’s domain to a Teams manifest also does not grant permission to its content.
Check the current tool-authentication channel requirements, including the linked Teams sign-on instructions where applicable. A designer test or unauthenticated demo website is not a substitute for that channel test. Do not assume that every authentication configuration supports seamless single sign-on.
Use two ordinary test accounts: one authorized to read a harmless test record and one without that access. Under an end-user connection, the first should retrieve the intended record and the second should remain denied. If a shared connection is part of the approved design, verify the permitted agent audience and output explicitly instead of claiming user-level trimming.
If the problem continues, provide support with the connection status, tool and operation, channel, timestamp, redacted error, and direct-access test result. Keep tokens, client secrets, and document contents out of the ticket. A successful fix restores the intended operation without extending who can read or change SharePoint data.