SharePoint connector "Get folder metadata using path" intermittently fails with HTTP 502

(1) Share

Report

Posted on by VB-03020721-0

I have a Copilot Studio agent, Intermittently, the agent fails when calling the SharePoint → "Get folder metadata using path" action, returning an HTTP 502 error. When this happens, the whole conversation is abandoned because this step is a dependency for the remaining logic.

Error Message

An error has occurred.
Error code: ConnectorRequestFailure
Time (UTC): 2026-08-31T11:17:50Z

Trace details:

errorCode: ConnectorRequestFailure
errorMessage: The connector 'SharePoint' returned an HTTP error with code 502.
errorSubCode: Undefined
isUserError: true

What the step was doing

The failing action was calling Get folder metadata using path with a valid SharePoint path (a project folder under a personal OneDrive/Documents/Projects/...). The path and dataset arguments were well-formed, and the immediately preceding step in the plan completed successfully.

Environment / Setup

Product: Copilot Studio (agent published to Microsoft Teams)
Connector: SharePoint (standard connector action "Get folder metadata using path")
Channel: Microsoft Teams
Frequency: Intermittent (transient) — sometimes retrying work

What I've already checked

The target folder path exists and is accessible.
The failure is not consistent — it appears to be a transient/gateway-level (502) issue.
Prior sessions using the same connector succeeded.

Questions for the community

Is anyone else seeing intermittent 502 Bad Gateway responses from the SharePoint connector action recently? Is this a known service-health issue?
What is the recommended way to add retry-with-backoff / graceful error handling for a connector action inside a Copilot Studio agent so a single transient 502 doesn't abandon the entire conversation?
Are there known limits (throttling, large folders, tokens) that could cause the SharePoint connector to return 502 rather than a 429/401?

Any guidance or shared experience would be much appreciated. Thank you!

Categories:

Autonomous agents

Bot extensibility

Calling actions from Copilot Studio

General topics

All responses (5)

Answers (0)

Sort by

Suggested answer

11manish 4,802 Super User 2026 Season 2 on at

Like
a
(1)

Report
Copy link

Link copied!

Your implementation is probably not fundamentally wrong. The missing piece is resilience. Treat Get folder metadata using path as an external dependency that can temporarily fail, rather than assuming it will always return successfully.

For a production audit agent, I would recommend Power Automate as the integration layer with retry/backoff + explicit error handling, and have Copilot Studio receive either a successful evidence payload or a controlled failure status. This will prevent one transient SharePoint 502 from abandoning the entire audit conversation.
Suggested answer

Valantis 7,545 Super User 2026 Season 2 on at

Like
a
(2)

Report
Copy link

Link copied!

Hi @VB-03020721-0,

since Copilot Studio agent flows don't expose native retry configuration on connector actions, moving the SharePoint call into a Power Automate flow as a tool is the right approach and also solves the retry problem.

In the Power Automate flow, on the Get folder metadata action, click the three dots > Settings > Retry policy. Set it to Fixed interval with a count of 3 and interval of PT5S (5 seconds). This handles transient 502s automatically without any extra logic.

For graceful error handling in the agent: configure the flow to return a status field in its output (e.g. Success: true/false). In the agent, after calling the flow as a tool, check that status and handle the failure case with a user-friendly message rather than abandoning the conversation.

On your question about whether this is a known service-health issue: transient 502s from the SharePoint connector are common and not typically tracked as incidents unless they become persistent. Check PPAC service health and the Microsoft 365 status page (status.cloud.microsoft) for active incidents if the frequency increases.

Best regards,

Valantis ✅ If this helped solve your issue, please Accept as Solution so others can find it quickly.

❤️ If it didn’t fully solve it but was still useful, please click “Yes” on “Was this reply helpful?” or leave a Like :).

🏷️ For follow-ups @Valantis.

📝 https://valantisond365.com/ 💼 LinkedIn ▶️ YouTube
Sam_Fawzi 1,150 Super User 2026 Season 1 on at

Like
a
(1)

Report
Copy link

Link copied!

Hey @VB-03020721-0

Before building resilience around this, worth confirming what is actually failing. Two things stand out.

The path looks like personal OneDrive. You mentioned a project folder under Documents/Projects in a personal OneDrive. The SharePoint connector pointed at a my.sharepoint.com/personal/... location is a known source of gateway level failures rather than clean 4xx errors. If that is the case, OneDrive for Business is the correct connector. This may be the cause rather than general service flakiness.

Connector actions already retry by default. Standard connector actions carry a default exponential retry policy, so if a 502 is reaching the user, either the retries were exhausted or the failure is not transient. Adding a fixed interval policy may not change the outcome. Check run history and see whether the failure lands on the same folder path each time. Intermittent across sessions but consistent per path points at the path or the identity, not the gateway.

To get a real error code, call Send an HTTP request to SharePoint against the same folder. It returns the underlying SPO error body instead of the connector's opaque ConnectorRequestFailure, which will tell you quickly whether this is throttling, auth, or a malformed path.

One clarification on the earlier replies: agent flows are cloud flows, so action settings including retry policy are available there. You do not need to rebuild in Power Automate purely to get retries. Moving the call into a flow is still a good idea for the reason @Valantis gave, returning a status field so the agent can handle failure gracefully instead of ending the conversation. Just worth fixing the connector choice first, otherwise you will be retrying a call that was never going to succeed.
Valantis 7,545 Super User 2026 Season 2 on at

Like
a
(0)

Report
Copy link

Link copied!

Hi @VB-03020721-0,

Just wanted to check in and see if everything is working now. If you still need any help, feel free to let me know.

Also, if the issue is resolved, it would be great if you could mark the answer as solved so others with the same question can find it easily.

Thanks and have a great day!
Suggested answer

M Bilal Khan 376 on at

Like
a
(0)

Report
Copy link

Link copied!
A 502 from the SharePoint connector generally points more toward a transient service/gateway issue than an authentication or invalid-path problem, especially when the exact same folder path works successfully in other runs.

For this type of Copilot Studio scenario, I would avoid making the Get folder metadata using path call a single point of failure for the entire conversation.

A few things I would try:

Add retry handling around the connector call. If the action is being executed through a Power Automate flow, configure the action's retry policy with exponential backoff and handle the failure explicitly before returning control to the agent.

2. Use a fallback path. If the metadata is only being retrieved to confirm that a folder exists, consider whether the next step can work with the folder path directly, or use another SharePoint operation that provides the required information.

3. Don't immediately retry in a tight loop. For intermittent 502s, a couple of retries with increasing delays is preferable. Otherwise, you can make a transient service issue worse if throttling is involved.

4. Check the run/trace around the failure. I'd compare successful and failed calls for the same site, library and path. If the request parameters are identical and only the response differs, that strengthens the case for a transient connector/service issue.

I wouldn't assume that a 502 is caused by a large folder or token limit. Those can certainly affect connector operations, but I'd expect throttling to more commonly surface as a 429, while 401/403 would point more toward permissions/authentication.

If this is happening consistently enough to reproduce, I'd also capture the UTC timestamps, correlation/request IDs from the failure details, and check the Microsoft 365/Power Platform service health before raising a support ticket.

For Copilot Studio specifically, the important design point is: treat connector calls as potentially transient and make the agent's dependency on them recoverable, rather than allowing one failed SharePoint call to terminate the whole conversation.