cancel
Showing results for 
Search instead for 
Did you mean: 

Flow Connectors need an Abuse Control / Rate Limiting facility

My company creates the popular Muhimbi PDF connector for Flow and Azure logic apps. All is working well and the Flow team has been very helpful during the process of developing the connector.

 

Because an increasing number of people use or evaluate our connector, we are seeing situations where people create a Flow for testing purposes, activate it and then forget about it. For the sake of this example, let's say they create a Flow that triggers whenever an email is received and converts that email to PDF. (or whenever a file is uploaded to DropBox, SharePoint etc, it really adds up quickly)

 

We love it when people evaluate our software, but when a Flow like this runs in the background, people forget about it, and when the free operations run out, the subscription is put on hold. Our servers deal with this just fine, but multiply this scenario by thousands of times and our systems get an increasing amount of useless requests that just use up bandwidth and eat up other expensive resources.

 

We have optimised this scenario as well as well can on our side, but there is nothing we can do to stop Flow sending requests that - due to the subscription exceeding their limits - will fail anyway. We know there is no mailicious intend on the side of the user, it just appears to happen frequently according to our logs.

 

To cut a long story short, it would be great if a facility could be added to Flow to take this scenario into account. I am sure the team has some good ideas on this topic, but I would like to propose something along the following lines (especially because we have already implemented it that way 🙂

 

  1. When a Flow executes an Action that returns HTTP code 403 (Forbidden) then the Flow is put in a certain state.
  2. If this code is returned multiple times for a Flow, within a certain time frame (e.g. 10 times in a day) then an email / other notification is sent to the Flow owner.
  3. If the owner takes no action then the Flow is paused automatically.

 

And yes, we do send alerts and reach out by email when we encounter situations like this, but for people who evaluate our software, those alerts and emails appear to be ignore / go to their spam folder. 

 

On a related note, we see users creating (accidental) recursive Flows, which ends up sending a lot of useless operations our way in rapid succession, depleting our users' (free) operations. The most common scenario where we see this is

 

  1. Flow author uses a Flow trigger for a SharePoint, DropBox, OneDrive or other storage related connector that is fired every time a new file is created.
  2. File is sent to our connector for PDF Conversion, watermarking, securing, merging, OCR, etc.
  3. Flow author writes the resulting PDF file to the same folder, which fires the Flow Trigger, running the same Flow over and over again.

Now, we have no way to see if a request is the result of a recursive call. I don't know if the Flow team can detect this, but if not then perhaps some rate limiting facility would be nice to have that slows down the requests when made in rapid succession. I know this is a difficult ask, as for some scenarios we want Flows to trigger our connector as quick and often as possible to deal with the large number of real operations that need to be processed.

 

Any improvements in both areas would be very much appreciated as it will really future proof Flow. Our logs show that people are using Flow at a rapidly increasing rate, which is aboslutely brilliant.

 

Status: New