by We usually want our Flows to run as fast as possible, but sometimes there Flow or any other platform needs a bit of extra time to process things. The “delay action” introduces a pause in the Flow between actions. I’ll start by saying that you should use this action sporadically and for a reason.
Where to find it?
The “delay action” is in the “Built-in” tab inside the “Schedule” group:
There you can find the “delay action.”
It looks like this.
Power Automate tends to save the most common actions in the main screen, so check there before going trough the full hierarchy. Also you can use the search to quickly find it.
You can also search for it:
And get the same result.
Usage
There are only two options:
- The amount of time to wait
- The unit to wait.
There is the option from Seconds to Months, so pick the one that fits and then add the integer value for the delay.
Why use it?
More important than how to use it is why? There are a few cases that I think the delay action will be useful, so let’s explore a few.
Creating files
If you’re creating a file in SharePoint and then, in the next action, do a “Get File Content Using Path” or “Get File Content” Action, for example, the file may not yet be created. Your Flow may fail because it can’t find the file the second after you trigger to create it. So adding a delay in these cases help to avoid a crash in the Flow, but a delay of 1 to 2 seconds will be enough.
Bulk adding values
If you’re providing many values to insert in a table, for example, it may be wise to delay a bit between batches. Some systems may limit the number of requests, so you may get errors if you trigger too many calls. The best approach is to connect once and send a defined batch of information, but if it’s impossible, look at the logs for random failures.
When Flow and users share files
There may be cases where you have a Flow that edits the same file as other people, and you may get errors in “merging the data.” Considering that this is imperative, like in this case, you can define wait times for when you know the users are editing the files. I want to include this case to provide a different view, but I would use the sync mechanisms in Excel and other apps before I try to manage times and slots where one or the other can edit a file.
Where NOT to use it?
Almost anywhere else besides the examples that I mentioned before. There may be more, and I’ll be happy to add them if you comment or send me an email, but I see it used in these cases. These are some cases, but there may be a lot more. Use the delay wisely and sporadically.
Waiting for user iteration
This happens a lot in cases like approval processes, for example. Power Automate takes care of this for you so take full advantage of it.
Calls to APIs
If the API takes longer than expected to report back, then the “delay action” won’t solve it.
Waiting for a date to come
Never do this. Ever!! Your Flow should start and end as fast as possible. If you need something to happen on a date, either define a scheduled Flow that triggers a defined schedule or use some other strategy to trigger the Flow, but never use the delay option to block the Flow until a certain time arrives.
Trigger reminders
The same as above. Store that information somewhere and trigger a Flow that will check if the time has arrived and then send the reminder.
Controlling multiple runs of the same Flow
If you have a Flow that triggers before the previous run finished, don’t add the “delay action” to “wait” for the other to finish. There is a better way by using the “Concurrency Control” in the Flow’s trigger. Here’s how to do it:
In your trigger, select the Settings:
And in the settings, activate the “Concurrency Control” and set it to 1.
You’re setting no parallelization, and that one Flow can only run after the other ends.
Limitations
I think Microsoft included the “Month” option for the sake of completion, but you should never use it. Flows have a 30 days max runtime, so after that time, regardless of what step you are, the Flow will timeout. So defining anything above that time will never be executed.
Recommendations
Here are some things to keep in mind.
Name it correctly
The name is super important in this case since the “delay action” needs to be clear to everyone. Naming it “delay” doesn’t say much, and it could confuse anyone trying to debug your Flow.
Always add a comment.
Adding a comment will also help to avoid mistakes. It’s essential to add comments to the “delay action” so that people know that there’s a reason to use it. And it better be a good reason; otherwise, removal is the better option.
Always deal with errors.
Let your Flow fail graciously when something goes wrong and notify someone that the Flow failed when trying to use this action. It’s horrible to have failing Flows in Power Automate since they may go unlooked for a while or generate even worse errors.
“Bad Smell”
Even if you build Flows for a living, if you have to use this action more than a couple of times, then there’s something wrong in the process. Adding delays, except for some cases like mentioned above, should always be considered a warning that something should be done differently. Consider this a “bad smell” that something should be reviewed or at least checked.
Back to the Power Automate Action Reference.
Photo by Andy Beales on Unsplash
