Having Flows that do everything for us without us even having to trigger them is fantastic. The “Recurrence” trigger does precisely this for us. It triggers at defined periods that can be as frequent as you want.
So let’s explore it a bit further.
Where to find it?
The “Recurrence” trigger is part of the default set of triggers. The other ones are “automated” (all the ones that react to some changes) and “manually” (that we trigger ourselves either using other Flows or via the app, for example).
When creating a scheduled Flow, we’re asked for the timeline that we want the Flow to trigger.
If you’re creating a Flow from scratch, you can go to “Schedule.”
Select the “Recurrence” trigger.
This is what it looks like.
Once you add the trigger, you can define the schedule. The schedule can be as frequent as “seconds” to as infrequent as “months.” Let’s look at each of them individually.
There’s not a lot of configuration needed for the seconds. You can define the number of seconds and are good to go.
Please take a look below at the recommendations regarding seconds.
Minutes follow the same reasoning as the “seconds.” You can define a number, and that’s it.
Minutes should be used instead of seconds if you can.
Hours follow the same structure as before.
It would be best to use “hour” to run each X number of hours. However, if you’re going to run, for example, every day at 2,4, and 6 pm, then you should use the “Day” (see below).
The day is a bit more complex but extremely useful.
Besides the standard X number of days, you can define, during those days, at what hours and minutes you want the Flow to fire. However, there are some things to keep in mind.
First, the Flow will trigger at an hour and a minute. So if you define 1,3 and 30,45, it will fire at “1:30”, “1:45”, “3:30”, and “3:45”.
Times are defined in the 24-hour format. So if you’re using the AM and PM, you can add 12 to the PM time to get the 24-hour format.
Finally, if you don’t define the minutes, Power Automate will consider it 00.
The week works precisely the same way as the day but with the added parameter for the day.
The same rules apply, but you can define one or more days of the week you want your Flow to run.
The month follows the same rules as the hour and minute. You provide a number, and the Flow will run every X months.
It’s a given, but I’ll say it anyway. For monthly tasks prefer this option instead of the weeks. You’ll only get part of the month if you try to do the math. You’ll get more or less depending on the number of days in that month. Also, a month is never four weeks, so consider this.
The “recurrence” trigger won’t return any information since it only fires at the defined timeline. It’s one of the few that behaves this way, so keep this in mind. If you need to know the time of the trigger, you can have a compose action with a “now” function to see the time that the Flow is triggering.
If it doesn’t fire
It happens that some Flows won’t fire at the time they are supposed to. There are many potential reasons, but one is that the Flow has errors or warnings. Power Automate will not start the scheduler if the Flows have failed in the tests, for example. A trick to solve this issue is using the “Flow checker” to solve all warnings and problems. After that, run the Flow manually and see if it runs correctly. If all goes well, define the “Start Time” and check if the Flow ran correctly.
There are some limitations for each frequency:
- Month: 1-16 months
- Week: 1-71 weeks
- Day: 1-500 days
- Hour: 1-12,000 hours
- Minute: 1-72,000 minutes
- Second: 1-9,999,999 seconds
Here are some things to keep in mind.
It’s a balance
Knowing what schedule to use is tricky. If you define it too frequently, your Flow will fire with few things to do. On the other hand, tasks will wait a long time to be performed if it’s too infrequent.
Do the math and try to understand the max time you can wait for a task to be performed. If you need to do something only once a day, there’s no need to define a 15-minute schedule, for example.
Only use if there’s no automated trigger.
Power Automate has many triggers, and a lot will fire “when something happens.” For example, if you have the “When a new email arrives” trigger, it will fire when a new email arrives. If you get five emails daily (lucky you!), it will fire only five times a day. If you have a trigger that will fire every 15 minutes, it will fire 96 times daily. It’s a huge difference, and it’s pretty wasteful to have Flows running without having anything to do.
Another advantage of using “automatic” triggers is that they will trigger the instant that something happens. The email will trigger as soon as you receive an email; otherwise, you would have to wait, in the worst-case scenario, 15 minutes.
So, as a rule of thumb, prefer the “automated” versions of the triggers and only use “recurrence” triggers if you need them.
Use to batch too frequent automated triggers.
There’s an exception to the recommendation above when the tasks are too frequent. For example, if you receive many emails, the “When a new email arrives” trigger will always fire and, sometimes, in parallel. As a result, it will burn your quota quite quickly, so you can think about batching tasks. Batching means that you trigger the actions periodically and parse all the changes in one go simultaneously. This is a lot more efficient, and you have control over the times your Flows trigger.
Be careful with the quotas.
If the schedule is too frequent, you’ll burn through your quota quickly since the Flow will always trigger. However, even if there’s little to do, it will count towards your quota, so be careful and do the math to avoid running into limitations or extra costs.
You should always be in control, even if you have automated Flows where the frequency is less deterministic.
Avoid the “Seconds” frequency.
I think the “seconds” frequency is a “red flag.” If I have to define a Flow that needs to be that frequent, I should think further about what I’m doing. First, if it’s that frequent, I’ll probably run into issues with the number of system requests or your quota. Second I should investigate if I have an automated Flow that does the same action. Lastly, we should consider if another system can do this more efficiently. Although Power Automate is extremely powerful, it should not be used for tasks that frequently. Sooner or later, you’ll run into issues, so be especially mindful when using the “seconds” frequency.
Please don’t use it for time-sensitive actions.
If you have actions that need to be run to the second, you should be careful while using Power Automate. Power Automate has nothing wrong, but it’s built to trigger “more or less” at the defined time. Remember that things take time to run, and the frequency will drift over time due to the time Flow takes to run. This is not a big deal when we have extended frequencies, but it adds up quite quickly for shorter frequencies.
Finally, Microsoft warns that for more extended frequencies, like day and month, there may be a slippage of 1 minute of the timestamp, so keep this in mind if you need it to run at the “exact” minute.
Define small numbers for intervals
Although there are limitations to the intervals, you can define large numbers when a smaller ones. For example, it’s the same as doing:
But the latter is a lot easier to understand. So again, it’s the same, and the trigger will fire simultaneously, but it’s all a question of readability.
Use whole numbers and not decimals.
Power Automate won’t complain if you insert “1.3” in the “interval” field, but you should always use whole numbers. Unfortunately, it’s harder to understand, and there needs to be a clear answer on what Power Automate will do with that number. I need to investigate further, but I suspect the number will be rounded.
Always define your time zone.
Times are one of the most tricky things to deal with because of time zones. 1 pm means something entirely different for everyone, and if you have Flows running
Know the impact of running something
You should always know the impact of a Flow running at a specific time. For example, if you’re running a Flow that backups up something during working hours, you’ll be backing up something stale as soon as you finish. Another example is Flow which performs actions on production systems. If the action is “heavy” for the systems, end users will notice the impact and generate downtimes.
Always think about “what’s the consequence of running this Flow?” Testing helps a lot. Test with a small subset, try to increase it over time, and understand the impact on the entire dataset. It’s all about control and reducing impact.
Use it to spread the load on the systems.
If you’re doing something that impacts the production serves, and you have a worldwide team, meaning that you don’t have time for downtime, you can use the “recurrence” trigger to spread the load on the system over time. If you have to copy files, for example, copy a bunch of them every 10 minutes instead of copying them in one shot at one time. Doing this will alleviate the pressure on the systems and impact less on your end-users.
Don’t define custom frequencies.
Although Microsoft was nice enough to allow for “custom values” for the frequency, there’s not a good reason (in my opinion) to do it.
Define the start time
If you don’t define the start time, Power Automate will fire it as soon as it’s saved. Unless you want it to run right away, you should control when it’s fired the first time since the recurrence will start from that point forward. It’s good to know that the Flow will run at time X or minute Y, especially when you need to monitor if it ran correctly or impacted the end systems.
Name it correctly
The name is super important since we can get the trigger from anywhere and with anything. Always build the name so that other people can understand what you are using without opening the action and checking the details.
Always add a comment.
Adding a comment will also help to avoid mistakes. Indicate your expectations, why the Flow should be triggered, and the data used. It’s essential to enable faster debugging when something goes wrong.
Back to the Power Automate Trigger Reference.