Power Community

Power Community

429 Errors reported by the trigger in your flow in Power Automate

This morning I was asked about 429 Errors in flows, But rather than 429 errors in actions, this time it was about 429 errors in triggers of a flow.

429 Errors

429 is the number that represents errors due to systems being to busy. In Power Automate you could for example have a flow that uses SharePoint to heavily and then SharePoint protects itself by slowing you down. The calls to SharePoint will then fail with a 429 error status. Power Automate recognise this 429 code and will retry the failing steps until it works.

In my above mentioned post from a while back, I discussed handling 429 errors in actions.

But what do you do if your trigger receives a 429 error? In your flow run history you will see Skipped flow runs. and there isn’t an easy way to recover from this.

Flow runs appearing with a status Skipped

When you open the flow run you will see a skipped trigger.

Trigger with a status Skipped

Or sometimes you might get the 429 errors to appear in failed flows showing the red marker on the trigger.

429 Errors can appear showing a trigger with a status 429

For business critical flows that deal with heavy data processing, this could be quite a big problem. “Is Power Automate not reliable?” is what I hear often asked.

Well it is all about developing your flows in the right way.

Solution 1- queue them up

As with actions receiving 429 errors, with triggers showing this problem.

Within actions you might find that retries are happening and the actions are actually succeeding after some failed attempts.

Actions with 429 errors will retry

Or actions might fail after a number of retries.

Actions may end with 429 errors after a number of retries

The error on the right hand side will tell you : “Looks like your flow’s operation is hitting an action limit designed to protect the connector service being called.”

But for triggers this is all not the case. So maybe we should queue up the requests. So let the trigger start and don’t run the actual flow to reduce the number of actions being called. Before you build a complicated queueing system, please look at solution 2 and 3.

Solution 2 – Reduce the number of actions called

One way of solving the issue is to reduce the number of calls that your flow makes. But that may be difficult. We might have to do what we might have to do. There comes a point that your flow just can’t be cleaned up any further.

Solutions 3 – Degree of parallelism

Concurrency Control setting in triggers.

If we zoom in on the Concurrency Control setting …

Degree of parallelism set to 5

Now it is possible to do the sums. Looking at the number of actions (+1 for the trigger) running in my flow and the throttling details for the connector that I’m using, I can now decide how many flows I should run at a maximum. Not that you shouldn’t just consider a single flow. Maybe also consider other flows that use the same connector. Once you have configured this degree of parallelism, you will find that there are flow runs with status of Waiting.

These flow runs of Waiting will run at some point but only after there is a slot free to run the flow instance.

429 Errors reported by the trigger in your flow in Power Automate Microsoft 365 image 54

When a quieter time appears, the queue of outstanding flows will now be processed.

This post was originally published on this site

- Advertisement -spot_img


Please enter your comment!
Please enter your name here

- Advertisement - Advertisement

Latest News

5 Benefits of In-App Notifications for Microsoft Dynamics 365 CRM users

For a successful sales process, you need to stay up-to-date with crucial sales information like deal closures, opportunities won,...

More Articles Like This

- Advertisement -spot_img