SharePoint action returns http status 400 instead of 503 and retry policy is not applied

(1) Share

Report

Posted on by ElenaN

I have a "Send HTTP Request to SharePoint" action that has a default retry policy set. Today the flow failed because the connector returned status 400, but in the error message the error code is 503, which should trigger the retry policy to be applied.

"status": 400,

"message": "503 Service Unavailable..."
 
This is obviously the case when retry policy should be applied. Why SharePoint actions are not passing through the correct status codes, and is there anything could be done about it? I definitely don't want to add retry blocks to every SharePoint action.
 
Thanks!

Categories:

Building flows

Using connectors

I have the same question (0)

All responses (3)

Answers (0)

Sort by

Suggested answer

Vish WR 3,748 on at

Like
a
(0)

Report
Copy link

Link copied!

@ElenaN

SharePoint connector wraps backend errors, so even if SharePoint returns a 503, the action reports it as a 400 with the real error only inside the message body. Retry policies only evaluate the top-level status code, not the message content, so the retry never triggers

Workarounds:

* Use HTTP (Premium) action to get actual status codes
* Wrap the action in a child flow with centralized retry logic
* Implement a Do Until loop checking the message for “503” and retry manuall

Also raise a support ticket with Microsoft there is a chance it will be fixed and also post in community portal idea submissions

Vishnu WR

LinkedIn - My Tech Space

Please ✅ Does this answer your question if my post helped you solve your issue. This will help others find it more readily. It also closes the item. If the content was useful in other ways, please consider answering Yes to Was this reply helpful? or give it a Like ♥

Was this reply helpful? Yes No
Suggested answer

Haque 3,653 on at

Like
a
(0)

Report
Copy link

Link copied!
Hi @ElenaN

Because the connector sees the HTTP status as 400 (Bad Request), it does not trigger the retry policy, even though the message indicates a 503 (Service Unavailable), which normally should trigger retries.

Logically, this mismatch happens if the SharePoint backend or proxy returns a 400 with a message indicating a 503 condition.

So two contradictions are here:

If the connector returns 400, it treats it as a client error and does not retry.

The error message inside the response body showing "503 Service Unavailable" is just text and does not influence the retry logic.

I know you don't want to add retry logic in every trigger/actions - but this is the reality you can't avoid.

Resolution: Let's attack the issue with specific error

Use a Configure run after on the HTTP action to catch failures.

Add a parallel branch or scope that checks the error message content for "503" and then triggers a manual retry or delay + retry logic.

I am sure some clues I tried to give. If these clues help to resolve the issue brought you by here, please don't forget to check the box Does this answer your question? At the same time, I am pretty sure you have liked the response!

Was this reply helpful? Yes No
Suggested answer

11manish 3,333 on at

Like
a
(0)

Report
Copy link

Link copied!
Retry policy is not triggered because the SharePoint connector returns HTTP 400, even though the message contains 503.
Power Automate only evaluates the outer status code, not the message, so it treats this as a non-retryable error.

This is a connector limitation, not your mistake
For reliability:

Use custom retry logic

Or switch to direct HTTP calls for correct status handling

Was this reply helpful? Yes No