Dataverse actions retry policy

(1) Share

Report

Posted on by djidji

168

Hello, I have an application account that makes a lot of request to dataverse via Power Automate, I made a lot of optimizations throught API when I make a bulk update so I don't have API rate limitation error.

However sometimes I have many requests in order to read or write the database, sometimes concurrent users call a flow or different flows, I have the possibility to have this error:

{

    "statusCode": 400,

    "headers": {...},

    "body": {

        "error": {

            "code": "0x80040224",

            "message": "APIM request was not successful :  StatusCode : 429, Reason : Too Many Requests, Response from APIM: { \"statusCode\": 429, \"message\": \"Rate limit is exceeded. Try again in 1 seconds.\" }",

            "@Microsoft.PowerApps.CDS.HelpLink": "http://go.microsoft.com/fwlink/?LinkID=398563&error=Microsoft.Crm.CrmException%3a80040224&client=platform",

            "@Microsoft.PowerApps.CDS.TraceText": "\r\n[Microsoft.Xrm.DataProvider.Connector.Plugins: Microsoft.Xrm.DataProvider.Connector.Plugins.ConnectorRetrieveMultiplePlugin]\r\n[c2e5f549-ad55-f011-bec1-000d3ae70152: External plug-in implementation]\r\n\r\n",

            "@Microsoft.PowerApps.CDS.InnerError.Message": "APIM request was not successful :  StatusCode : 429, Reason : Too Many Requests, Response from APIM: { \"statusCode\": 429, \"message\": \"Rate limit is exceeded. Try again in 1 seconds.\" }"

}

}

}

The Status code given by the action gives the StatusCode 429, however the statusCode is 400, I think that's why I have a failed action instead of an expiration that's why I can't set up a retry policy.

I don't know how I can manage those cases without making the flows very complexed, and I don't know what is the general approach to manage this issue.

We plan to make the read actions outside dataverse calls to prevent those errors to occur, but I don't think we can rule them out completly, I fell like the retry policy should be the basic behaviour.

Thank you for your help.

Best regards,

Djilali.

Categories:

Using flows

I have the same question (0)

All responses (4)

Answers (0)

Sort by

Suggested answer

Haque 3,653 on at

Like
a
(0)

Report
Copy link

Link copied!
Hi @djidji,

If I were you - first, what I would do was monitor the limits (Power Platform Admin Center → Analytics → API Calls to monitor usage) ~6000 requests per 5 minutes per user/service principal [five-minute (300 second) sliding window] and varies on license . If you see you are hitting the limit - you can optimize the flow that way.

Analysis of the error you are confronted with:

StatusCode: 400 → The flow failed with a bad request.

Inner error: 429 Too Many Requests → This is the real cause. It means your requests to Dataverse via the API Management (APIM) gateway exceeded the allowed rate.

Message: "Rate limit is exceeded. Try again in 1 seconds." → Dataverse throttled your flow because too many requests were sent in a short time.

Error code: 0x80040224 → A Dataverse platform error indicating throttling.

Based on the error above we need to optimzie the flow: (I belive you have employed some of them - but if something got missed out from the list - can be handy)

Retry logic is your friend - meaning embrace Dataverse calls in a retry policy. Introduce the Configure Run After or Scope with Retry pattern. In case of error 429, wait (respect the “Retry-After” header, usually 1–5 seconds) and try again.

Handle throttle before it hits - you can add Delay actions between requests when processing large volumes. For example: after every 100 records, pause for 1–3 or 2-5 seconds.

If not already, you can use ExecuteMultiple or Batch API calls to reduce the number of individual requests. For updates, send multiple records in one request instead of looping.

I am very careful using Parallelism control in db application - but do assess with attention if multiple flows or users can trigger at the same time, use Concurrency Control in the trigger settings - please do so/choose wisely!

Please let me know if you have alredy covered all of them or not.

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
djidji 168 on at

Like
a
(0)

Report
Copy link

Link copied!

Hello @Haque, thank you for your response, indeed that's really good recommandations, I think I missed some elements when I have redacted my message:

- The limit I faced is not depending on the licence, it's the security limit which is I think about 52 of parallel requests at the sames times for a user

- I am indeed using ExcecuteMultiple operations that are very handy for specific cases, and allows to make operations much faster without limit for specific needs

- Batch API if I remember well is a very bad idea, it is still limited and is behaving like parallel API requests, so the throttling error is very likely to happen in those us cases, I think it does not ensure that everything is done properly and simply send back the list of failures

- The issue is not the flow individually, as there is no concurrent operations, it's when multiple operations are executed at the same time by different users.

I think for now there is not any easy solution for that, what bothered me is that there is no retry behaviour so I don't know how I will manage that, it's not something that happens very often but when it occurs I don't know what to say to the users.

I think I will have to work on the reading operations to get read of them as much as possible by reading them in an external system.

Was this reply helpful? Yes No
Suggested answer

Haque 3,653 on at

Like
a
(2)

Report
Copy link

Link copied!

Hi @djidji

I understand your pain, its excurciating when customers face it!

Apparently, it seems the situation is critical - you have addressed all of the ideal cases (I consider). Now things need to be troubleshoot in cold-head with strategic plan.

One vague idea to soften your clients - you can send them a message "Some maintenance task will be going on over the next couple weeks to improve the system performance - you may face some troube in the meantime... bla bla.." or what you think.

After buying some tme window - you attack the application strategically. First thing - is this somehting need to server from PA? If, so how lightger my PAF can be. You can think reducing the number of users from PA, stop 10 users at the first place, for example. Or can we take out some logic at business rule side (Dataverse level) - if possible.

Right now your thought is good - as you said, offload read operations to an external system (cache or replicated store). This will reduce pressure on Dataverse and avoids hitting concurrency limits. Also, a chance to use elastic table for scenario involcing high-volume read/write workloads and horizontal scaling can be an option (hectic thoguh).

In parallel - implementing partion keys for CRUD operation to improve performance by dedicating request to specific data partition is not a far beyond optoin.

Hopinig things will be easy soon.

Was this reply helpful? Yes No
Suggested answer

11manish 3,333 on at

Like
a
(0)

Report
Copy link

Link copied!
You’re hitting a classic throttling scenario in Microsoft Dataverse via Microsoft Power Automate:

The real issue is 429 (Too Many Requests) wrapped inside a 400 response, so retry policy doesn’t trigger automatically

Probabilities :

High number of concurrent requests (read/write)

Multiple flows/users hitting Dataverse at the same time

No built-in retry due to incorrect status code handling

Best solution is to implement custom retry logic + control concurrency + add delay based on throttling response

Was this reply helpful? Yes No