Microsoft Flow – Is timeout handling your worst nightmare?

In the past I wrote quite a few posts about error handling in Microsoft Flow.  In general, error handling means that you need to deal with something that has gone wrong. Timeouts however can be more complicated as your flow may sometimes work and sometimes fail. This can become your worst nightmare.

 

Handling the timeout can be done by setting the run after settings

This could then result in something like this:

In my above example I’m sending emails when a timeout has occurred or when a HTTP call has failed. Depending on what the call was doing you might need to redo or correct something. This is where timeout handling becomes potentially complicated.

Rather than trying to correct the Timeout it is better to avoid the timeouts all together. Within the HTTP request there is a Timeout setting. This timeout setting can be increased so that timeouts are less likely, however when you run HTTP requests that take a long time, you might want to fix the issues within the API that you’re calling.

Splitting a long running function into smaller tasks is a lot easier to handle than the timeouts within Flow. There are a number of ways that you can split your jobs.

Split data into smaller chunks

Imagine that you wanted to update 100000 records and this is taking too long. You could now consider splitting the data into smaller chunks and deal with 1000 records at a time.

Split large tasks into smaller tasks

Imagine if you created many list items in SharePoint then update SQL database records and then finally update SharePoint list items again. Rather than a single job it might be possible to do this in 3 steps.

Finally it is also possible to combine both of the above options.

Have you got any timeout issues in Microsoft Flow? Please leave a comment below. I’m interested in hearing about your issues.