Designing Scheduled Flows in Power Automate — Month-End Processing, Business-Day Checks, and Reminders in Practice

“As month-end approaches, someone in accounting emails every department: ‘the expense-reimbursement deadline is the ◯th.’” “Every morning after starting work, someone opens the order list and eyeballs it to check whether anything is still unprocessed.” “Documents past their submission deadline get cross-checked against a ledger and chased down one by one.” Even at companies that have already adopted Microsoft 365, work where “a person acts based on watching a calendar and a ledger” remains surprisingly common. Forgetting turns into an incident, and yet the only mechanism to prevent forgetting is that person’s memory and their Outlook calendar.

Power Automate’s scheduled execution (the Recurrence trigger) can automate this kind of recurring task. But the moment you actually try to build it for Japanese business practice, you run into three walls right away: the default time is UTC (Coordinated Universal Time), the concept of a “business day” doesn’t exist as a built-in, and you have to write expressions yourself to determine things like “month-end” or “the 20th closing date.” This article lays out the Recurrence trigger’s specifications and pitfalls, a toolbox of date calculations, business-day checks driven by a holiday master list, reminder design that doesn’t nag too much, and the operational risks specific to scheduled flows.

By the way, we wrote in detail about how to handle the Japanese date requirements of the Japanese calendar era, public holidays, and closing dates across systems in general, in a separate article, Japanese Era Dates, Public Holidays, and Closing-Date Processing in Business Apps — Era-Resilient Design, JapaneseCalendar, and Business-Day Calculations in Practice. This article is the practical companion piece that applies that thinking to Power Automate flows.

1. The Bottom Line First

• The Recurrence trigger’s time is treated as UTC unless you specify a time zone. You prevent the accident of thinking you set “every morning at 9” but actually running at 6 PM Japan time by selecting “(UTC+09:00) Osaka, Sapporo, Tokyo” in the time zone field and explicitly setting the start time.¹²
• “Run on weekdays only” can be built with frequency “Week” plus day-of-week selection (Mon–Fri). However, holidays aren’t taken into account. A fixed date like “the 20th of every month” can be built with a start date/time plus frequency “Month,” but you can’t specify a moving date like “the last day of every month” or “the previous business day if the closing date is a holiday,” so the practical solution is “run every day and check with an expression.”²
• utcNow() inside an expression is also always UTC. Convert it with convertTimeZone(utcNow(), 'UTC', 'Tokyo Standard Time') before using “today” in Japan time. Forget to convert in a flow that runs during the 8 AM hour, and “today” ends up being the previous day.³⁴
• There’s no built-in mechanism for recognizing Japanese public holidays. There’s no holiday function in the list of expression functions either,⁵ so the standard practice is to keep your own holiday master list (a SharePoint list, etc.), have the flow determine “is today a business day” right at the start, and terminate if it isn’t. The Cabinet Office’s holiday CSV can serve as the master list’s primary source.⁶
• Build reminders as one message per person, bundled together, rather than one message per record. Using data-operation actions like Filter array and Create HTML table lets you build this readably while avoiding nested Apply to each loops.⁷
• A scheduled flow is hard to notice “not running.” Design failure notifications and a run record in from the very start, on the assumption of the following specifications: turned off after 14 consecutive failures, turned off after 90 days with no trigger, and a run history that only covers 28 days by default.⁸⁹

2. Taking Stock of “Work Where a Person Watches a Calendar and Acts”

The first thing to do isn’t building a flow — it’s identifying every piece of “work driven by watching a calendar” and sorting out whether each one is suited to scheduled execution.

There are three criteria for the sort: can the condition be expressed as data (a “case that just feels off somehow” can’t be automated), can the rule for the execution day be put into words, and can it recover the next day even if it fails (anything that can’t is Chapter 8’s development territory).

Of these, the second is the toughest spot in Japanese business practice. Even something as simple as “send the closing reminder at month-end” actually involves a person making adjustments like “move it up to the previous business day if month-end falls on a weekend or holiday, and send it before the break in a Golden Week year.” Think of writing this tacit knowledge out as an explicit specification as the real core of building the flow. Build the flow while leaving this ambiguous, and you’ll lose trust in ways like “a chasing email went out on a public holiday” or “the pre-holiday reminder went out during the holiday itself.”

3. The Basics and the Pitfalls of the Recurrence Trigger

A scheduled cloud flow is created as a “Scheduled cloud flow,” and you set the frequency and interval with the Recurrence trigger.¹ Frequency can be chosen from seconds, minutes, hours, days, weeks, or months, with a minimum interval of 60 seconds and a maximum of 500 days.⁸ The specification itself is simple, but it’s also a trigger with plenty of pitfalls.

Pitfall 1: The Default Is UTC — “Should Have Been 9, but It Ran at 6 PM”

This is the most common accident. If you don’t select a time zone, the Recurrence trigger’s start time is interpreted in UTC format with a trailing Z (YYYY-MM-DDThh:mm:ssZ). Select Japan in the time zone field, and the start time is treated as local time in that time zone (YYYY-MM-DDThh:mm:ss, no Z).¹² If you’re building a “flow that notifies every morning at 9,” the correct approach is to set the time zone to “(UTC+09:00) Osaka, Sapporo, Tokyo” and the start time to 9:00.

Pitfall 2: Skip the Start Time, and It Fires Once the Instant You Save

If you don’t specify a start date/time, the first run fires immediately the moment you save the flow.² That’s fine while testing, but it can turn into an accident where you save a flow that includes a chasing email in the evening, and everyone gets chased right then and there. Always specify the start date/time.

Furthermore, if you don’t specify “at these hours/at these minutes” in the advanced options, every run after the first is calculated relative to the previous run’s time, so accumulated delay causes the execution time to drift little by little.² For a flow you want to run at a fixed time every day, it’s safest to explicitly specify the execution time in addition to the start date/time.

Pitfall 3: “Weekdays Only” Works, but Monthly Detail Options Are Limited

Setting the frequency to “Week” lets you choose days of the week (Mon–Fri), and setting it to “Day” or “Week” also lets you specify a time of day (hour/minute). In other words, “9 AM on weekdays only” can be built with trigger settings alone. On the other hand, these detailed options are only available when the frequency is “Day” or “Week” — the “Month” frequency has no field for specifying a date like “the 20th of every month” or “the last day of every month.”²

That said, if the date is fixed and monthly, you don’t need to run it every day. Set the start date/time to the target date (e.g., 9:00 on the 20th of next month) and the frequency to “Month,” and execution becomes monthly, anchored to the start date/time, so “9 AM on the 20th of every month” can be built with trigger settings alone.² Avoid launching a flow that only needs to run 12 times a month 365 times a day and discarding most of them via a condition check — it makes the run history harder to read and wastes request quota for nothing.

The configuration of “run every day and check at the top of the flow with an expression whether today is the target date” becomes necessary for monthly work where the date itself moves around. Dates like “the last day of every month” (the 28th through the 31st, depending on the month), “the previous business day if the 20th is a weekend or holiday,” or “the Nth business day of every month” cannot be expressed by the trigger. We cover that judgment expression in the next chapter. Note also that specifying a fixed date of the 29th through 31st as the start day requires you to test, through actual implementation, what happens in a month where that day doesn’t exist, so it’s safer to lean toward “run every day + check” from the start for anything around month-end.

Pitfall 4: Daylight Saving Time — A Concern Only for Overseas Locations

If you write the time in UTC without selecting a time zone, the execution time shifts by an hour every time a region with daylight saving time (DST) makes its seasonal switch. If you’ve selected a time zone, the schedule keeps up with the seasonal switch and stays consistent.¹⁰ Japan has no daylight saving time, so there’s no real-world harm for domestic-only use, but if the same flow also handles notifications for an overseas location, you need to explicitly select that location’s time zone.

Pitfall 5: An Expression Written Into the Trigger Gets Locked In at Save Time

Write an expression like utcNow() into a trigger’s input, and that value gets calculated and locked in at the moment you save the flow. It is not recalculated on every run.¹¹ Keep in mind that the idea of putting an expression into the trigger because “I want the start time to be today” simply doesn’t work.

Pitfall 6: Time It Was Turned Off Doesn’t Get Made Up Later

The Recurrence trigger does not batch-process, after resuming, any schedules that passed while the flow was off — it simply resumes from the next cycle.¹⁰ An accident like “turning off a month-end flow for a few days to make a change, and it happened to span the month-end execution date, so this month’s run just never happened” is entirely possible. Make it standard practice to check the next scheduled run date before turning off a scheduled flow.

4. A Toolbox of Date Calculations — Judging Month-End, Month-Start, and Closing Dates With Expressions

Date calculations inside a flow are written with the same expressions (functions) shared with Logic Apps.⁵ As a premise, what utcNow() returns is always the current time in UTC.¹² So, structuring things so that you build “today in Japan time” once at the start of the flow, store it in a variable (or a Compose), and reuse it from then on makes your expressions much easier to read.

convertTimeZone(utcNow(), 'UTC', 'Tokyo Standard Time', 'yyyy-MM-dd')

convertTimeZone(timestamp, source, destination, format) is the time zone conversion function,¹³ and the time zone name uses the name from Windows’s list of time zones. Japan’s is “Tokyo Standard Time.”⁴ If you’d rather not write an expression, there’s also a “Convert time zone” action that does the same thing.¹³

The reason the conversion is mandatory is that there’s a 9-hour gap between UTC and Japan time. Until 9 AM Japan time, it’s still the previous day in UTC. Write formatDateTime(utcNow(), 'yyyy-MM-dd') in a flow that runs at 8 AM, and the “today” you get back is yesterday’s date. Because this date mismatch appears or doesn’t depending on the execution time, it’s easy to miss during testing, and it surfaces in production in ways like “processing that was supposed to be month-start also ran on the very last day of the month.”

Here’s a summary of judgment patterns once you’ve built “today in Japan time” (referred to below as Today).

addDays, addToTime, startOfMonth, formatDateTime, and dayOfWeek are all functions defined in the shared Logic Apps/Power Automate expression reference.⁵ The combined expressions in the table above are the author’s own implementation pattern, so when you adopt them, test with dates spanning month-end, month-start, and a leap year (February 29) before putting them into production. We wrote about how frightening a date bug that only strikes on a specific date can be, and how to pick the dates worth testing in advance, in Chapter 4 of the article on the Japanese calendar, public holidays, and closing dates.

5. Business-Day Checks — Keep Holidays in a Master List

There’s No Built-in Holiday Check

To repeat, Power Automate has no built-in feature for recognizing Japanese public holidays. The Recurrence trigger’s day-of-week setting looks at literally nothing but the day of the week, and the list of expression functions only goes as far as date arithmetic, formatting, and time zone conversion — there’s no function that returns “is this date a holiday.” We wrote in detail, in Chapter 3 of the article on the Japanese calendar, public holidays, and closing dates, about how computing holidays with a formula is fundamentally impossible in principle (the equinoxes are only finalized the year before, and holidays themselves shift due to legal amendments and special-measures laws). The conclusion is the same here: keeping holidays as data (a master list) plus an update operation is the right answer.

The easy way to keep this in Power Automate is to build a “holiday master list” as a SharePoint list (a date column plus a name column). For the primary source, you can use the CSV of holiday dates and names, from 1955 through next year, published by the Cabinet Office (substitute holidays are included as rows too).⁶ Since only finalized dates get published, the design has to extend as far as putting the task of importing next year’s dates into the master list, once a year, onto the business calendar. Forget to update it, and it becomes an actual malfunction, in the form of a chasing notification going out on next year’s holiday. Also, keep company closure days like summer holidays or a founding anniversary in a separate list rather than mixing them into the holiday master — because “a bank-transfer due-date check should only look at public holidays” while “an internal chasing reminder should also look at company closure days,” and the set of holidays you should reference differs depending on the purpose.

A “Business-Day Guard” at the Top of the Flow

For a flow you want to run only on business days, put the following check at the top of the flow, in addition to Recurrence’s day-of-week setting (Mon–Fri).

1. Build “today in Japan time” (Chapter 4)
2. Run SharePoint’s “Get items” against the holiday master list, and search for today’s date with a filter query like HolidayDate eq 'Today'¹⁴
3. Run the same search against the company closure-day list as well
4. If even one hit comes back, stop execution with the “Terminate” action

Terminate is the action that stops a flow’s execution on the spot and ends it in the state you specify (Succeeded/Failed/Cancelled) — it can’t be placed inside an Apply to each or Do until loop.¹⁵ Setting the state to “Cancelled” here lets you tell, at a glance in the run history, “a day skipped because it wasn’t a business day” apart from “a day the processing actually ran.” That makes later investigation much easier than lumping everything together as “Succeeded.”

“Moving Up to the Previous Business Day” and “N Business Days Before”

What a month-end closing reminder actually needs isn’t “every month-end” — it’s “the previous business day if month-end is a day off.” This can be expressed, in a flow that runs every business day, by checking “today is a business day, and there is not a single business day between tomorrow and month-end.” As an implementation, you loop through the dates from tomorrow up to the month-end date (Chapter 4’s expression) in order, and the moment you find a day that’s neither a weekend nor in the holiday master list, you conclude “today is not the last business day” and break out.

N business days before, like “chase 3 business days before the payment due date,” follows the same reframing. Replace “when it becomes N business days before the due date” with “run every business day, count the number of business days from today to the due date, and check if it matches N.” Counting business days is simply a matter of counting days that are “not a weekend, not in the holiday master, and not in the company closure-day list.” That said, a flow-loop process that counts dates one day at a time turns into a loop of record count times day count once the target caseload exceeds a few hundred, and that inflates both run time and API calls. Once you reach that scale, it’s healthier to push the business-day calculation outside the flow (a business-day table in a database, or a small API), or to treat it as Chapter 8’s development territory.

6. Designing Reminders and Chasers — One Message Per Person, Bundled

Prerequisite: The Ledger Has to Already Be Data

You can only automate chasing overdue items if “what it is, whose responsibility it is, and when it’s due” can be pulled as data. If your ledger is still an Excel file circulating as an email attachment on a shared folder, consider migrating it to a SharePoint list first. What follows assumes a SharePoint list with “Due Date,” “Status,” and “Assignee” columns.

Filter at Retrieval Time

Rather than pulling every item in the list and then branching on a condition inside the flow, filter for overdue items on the server side with Get items’s filter query (an OData filter).¹⁴

DueDate lt '2026-07-18' and Status ne 'Complete'

Embed the “today in Japan time” expression built in Chapter 4 into the date portion. Note that the filter query’s column names must be written using SharePoint’s internal names, not the display names shown on screen, and that only 100 items are returned by default, so a list with a large item count needs either a Top Count limit specified or pagination configured.¹⁴

Avoiding Apply-to-Each Hell — How to Bundle Into One Message

Loop over the extraction results directly with Apply to each and send an email for each one, and if assignee A has 10 unprocessed items, they get 10 emails every morning. Keep that up for a few weeks and the notifications are guaranteed to stop being read, killing the reminder mechanism itself. The rule is: bundle notifications into one message per assignee. Using data-operation actions, you can build this in the following flow.⁷

1. Use Select to build an array of assignee email addresses from the extraction results, and use union() to remove duplicates and build a “list of assignees to notify today.”⁵
2. Loop over that assignee list with Apply to each, and inside it, use Filter array to extract “just this assignee’s items.”
3. Use Create HTML table to format them into a table of subject, due date, and status, embed it in the body of one email (or Teams message), and send just that one message (enable HTML display for the email case⁷)

Here’s what the whole picture looks like.

flowchart TD
    Rec[Recurrence trigger<br/>Weekdays, 9:00 AM, time zone: Osaka, Sapporo, Tokyo] --> Today[Build today in Japan time<br/>convertTimeZone]
    Today --> Hol{Is today in the holiday master<br/>or company closure-day list?}
    Hol -- Yes --> Term[Terminate, Cancelled<br/>End because it's not a business day]
    Hol -- No --> Get[Get items<br/>Extract overdue and incomplete records]
    Get --> Any{Any matches?}
    Any -- No --> End([End, no notification])
    Any -- Yes --> Sel[Build the assignee list with Select<br/>Deduplicate with union]
    Sel --> Each[Loop per assignee]
    Each --> Filter[Filter array<br/>Extract only this assignee's items]
    Filter --> Table[Format into a table with Create HTML table]
    Table --> Send[Send one notification to the assignee<br/>Teams or Outlook]
    Send --> Log[Record the run result to a log list]

Choosing Between Teams and Outlook

Choose the notification channel based on the nature of the message.

The standard split is Teams for daily summaries, and email for formal pre-closing reminders and overdue chasers. Sending the same content down both channels is not recommended, since it only increases the total volume of notifications.

Designing So You Don’t Nag Too Much

The scariest part of automating reminders is sending so many that they all get ignored. Manual chasing has a natural brake — it’s awkward to say, so people keep the frequency down — but a flow has none. You have to build that brake into the design.

• Design the total volume. Every morning, everyone, everything is the worst pattern. Narrow down the sending conditions — for example, send daily only for items due today or overdue, and limit advance reminders to just two: 3 business days before, and the day before.
• Add stages. Notify only the individual at first, and add the manager as a recipient once the overdue period has continued for N business days — split the escalation like that. Send everything to the manager from the very start, and the notification just becomes noise.
• Build in a way for it to stop. Always provide an exit where notifications stop starting the next day once the assignee sets the list’s status column to “Complete.” If completion reports are still just email replies, the flow keeps chasing, and the assignee ends up resenting the flow.
• Keep “no notification means no problem” trustworthy. This only holds true together with the monitoring covered in the next chapter.

7. Operational Cautions — You Can’t Tell When a Scheduled Flow Has Stopped

With an event-triggered flow, the business side notices when “I submitted the request and it didn’t run.” A scheduled flow has no such detector. If the month-end reminder has stopped, the closing just gets delayed with nobody saying anything. Base your operational design on the following specifications.

• There are conditions under which a flow turns off automatically. A flow whose trigger or actions keep failing turns off after 14 days, and a flow that keeps getting throttled also turns off after 14 days. Furthermore, a flow that has never once been triggered in 90 days can be turned off (this doesn’t apply to a flow whose owner holds a premium license or a capacity license such as Process; the owner and co-owners are notified 30 days before it turns off, and you can turn it back on to keep it going).⁸ If you’re building a “flow that only runs once a quarter,” watch out for this 90-day rule.
• By default, only 28 days of run history are visible.⁹ For a monthly flow, that math works out to only being able to check the most recent single run. Adding a step at the end of the flow that appends one row — “run date/time, record count processed, result” — to a logging SharePoint list lets you check “did it actually run last month” regardless of the run history’s expiration. That’s why the log-recording step sits at the end of Chapter 6’s diagram.
• Give the flow itself a way to notice failures. Without a branch that notifies an administrator on failure (an action configured with the “has failed” run-after condition), nobody notices a failure for the whole 14 days before it turns off. We cover building error handling and retries in detail in Error Handling and Retry Design in Power Automate.
• The owner leaving or transferring stops the entire schedule. A Recurrence-triggered flow runs on the flow creator’s connection.¹¹ If the owner’s account is disabled, the connection breaks, the flow starts failing, and it eventually turns off. Finish setting up co-owners and taking stock of connections on day one of going live.¹⁶ Ownership, connections, and handover documentation are worth a dedicated design of their own, not something to sort out only after someone has already left.
• Time spent turned off never runs retroactively (Pitfall 6 in Chapter 3). When you turn a flow off for maintenance or incident response, check the next scheduled run date, and decide in advance on a manual-run fallback for cases where you end up spanning it.¹⁰

8. How Far Should You Go With Power Automate?

Scheduled execution is an excellent entry point into automation, but turning anything and everything that “runs periodically” into a flow is dangerous. Here’s a rough guide for drawing the line.

As a rule of thumb, the line falls somewhere around: Power Automate up through “making someone notice,” development for “finalizing” (rewriting core-system data). We’ve seen cases, more than once, where trying to build the closing process itself as a flow turned into an explosion of branches, and things usually stabilized once it was split back into “the closing itself runs on the existing system or through contract development, and only the reminder that prevents forgetting to close stays as a flow.” Also, for recurring processing that completes entirely inside a server without going through the cloud, PowerShell and Task Scheduler can sometimes be simpler and easier to maintain. Comparing when to use which is a topic worth covering in its own article.

9. Summary

The real substance of designing a scheduled flow lies less in configuring the Recurrence trigger itself, and more in what comes before and after it. What comes before is putting the tacit knowledge of “acting by watching a calendar” into an explicit specification: what happens if month-end falls on a holiday, who enters holidays into the master list and when. A flow built without settling these will always malfunction against the Japanese calendar sooner or later. What comes after is the operational practice for noticing when it has stopped: a 28-day run history, the various automatic-turn-off conditions, a schedule that stops when the owner leaves. Build in failure notifications and a run log from the very start, on the assumption that a scheduled flow stops silently.

The technical points boil down to three: make the time zone explicit (the default is UTC), convert dates to Japan time before checking them, and keep holidays in a master list and reject non-business days with a guard at the top of the flow. Once you’ve got those three nailed down, bundle notifications by assignee, and give chasers both stages and an exit. Do all of this, and a considerable share of “work where a person acts by watching a calendar” can be replaced with a scheduled flow you can trust to run on its own. And when you find yourself wanting to push into “finalizing” processing — like the closing process or core-system batch jobs — that’s the moment to consider switching over to development territory.

Related Articles

• Automating Business Processes with Power Automate — Cloud Flows, Desktop Flows, and Robust Error Handling
• Japanese Era Dates, Public Holidays, and Closing-Date Processing in Business Apps — Era-Resilient Design, JapaneseCalendar, and Business-Day Calculations in Practice
• Error Handling and Retry Design in Power Automate

Related Consulting Areas

Komura Software LLC handles everything from design reviews of scheduled processing and reminders built with Power Automate, through to developing closing processes, business-day calculations, and core-system integration batch jobs that go beyond what a flow can handle.

• Technical Consulting & Design Review
• Windows App Development
• Contact

References

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These topic pages place the article in a broader service and decision context.

Frequently Asked Questions

Common questions about the topic of this article.

How do I make a Power Automate scheduled flow run every morning at 9 AM Japan time?

Select "(UTC+09:00) Osaka, Sapporo, Tokyo" in the Recurrence trigger's time zone field, and specify the start time. If you don't specify a time zone, the start time is treated as UTC with a trailing Z, so setting it thinking it means "9:00" will actually run at 6 PM Japan time. Also, utcNow() inside expressions always returns UTC as well, so whenever you use "today's date" inside a flow, convert it to Japan time first with something like convertTimeZone(utcNow(), 'UTC', 'Tokyo Standard Time', 'yyyy-MM-dd').

Does Power Automate have a feature for recognizing Japanese public holidays?

No built-in feature exists. The Recurrence trigger's day-of-week setting lets you run on "weekdays only," but it doesn't take holidays into account, and there's no function in the expression list that returns holidays either. In practice, you build your own master list of holiday dates (a SharePoint list, for example), search whether "today is in the master list" right at the start of the flow, and terminate if it isn't a business day. For updating the master list, the holiday CSV published by the Cabinet Office can serve as your primary source.

Can I build a flow that only runs on the last business day of the month?

For a fixed date, such as "the 20th of every month," you can set the start date/time to the target date and set the frequency to "Month," which creates an execution on the same day and time every month, anchored to the start date/time. On the other hand, the Recurrence trigger has no option to directly specify "the last day of the month," and detailed day-of-week or time-of-day settings are only available when the frequency is "Day" or "Week." For processing where the date moves around, like month-end, build the flow to run every day (or every weekday), have an expression at the top decide "is today the last day of the month" or "is today a business day," and terminate on any day that doesn't meet the condition. You can express the month-end check as "today is the last day of the month if today's month differs from tomorrow's month." "Run on the last business day if the month-end falls on a weekend or holiday" is expressed by adding a holiday-master check to that same structure.

My scheduled flow turned itself off without me realizing. Why did that happen?

Power Automate has several conditions that automatically turn a flow off. A flow whose trigger or actions keep failing turns off after 14 days, and a flow that keeps getting throttled (exceeding limits) also turns off after 14 days. In addition, a flow that has never once been triggered in 90 days can be turned off (this doesn't apply if the owner holds a premium license or a capacity license, and the owner and co-owners are notified 30 days before it's turned off). Because it's hard for anyone to notice when a scheduled flow stops running, it's important to build in failure notifications and a run record from the very start.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.