小村软件有限公司
联系我们
菜单

用 Power Automate 设计定期执行流程 ── 月末处理・营业日判定・提醒的实务

· 更新日期: · · Power Automate, 云端流程, 定期执行, 营业日, 法定节假日, SharePoint, Microsoft 365, 业务自动化, 技术咨询

「每到月末临近，财务人员就要给各部门发邮件说『费用报销的截止日期是◯日』」「每天早上上班后，打开订单列表，用肉眼确认是否还有未处理的内容」「把超过提交期限的文件与台账逐一核对，一件一件地催办」。即使是已经导入了 Microsoft 365 的公司，这类「人看着日历和台账去行动」的工作，仍然出乎意料地多。忘记处理就会酿成事故，可用来防止遗忘的机制，却只有负责人的记忆和 Outlook 日历——这就是现实状态。

使用 Power Automate 的定时执行（Recurrence 触发器），就可以将这类定期性工作自动化。不过，一旦真正在日本的业务场景中动手搭建，很快就会碰到三堵墙：时间的默认值是 UTC（协调世界时）、内置功能中不存在「营业日」这个概念、以及必须用表达式来编写「月末」「20日结算」的判定逻辑。本文将整理 Recurrence 触发器的规格与陷阱、日期计算的工具箱、基于法定节假日主数据表的营业日判定、不会催办过度的提醒设计，以及定期执行流程特有的运维风险。

另外，关于日本年号、法定节假日、结算日这类日期需求在系统整体中该如何处理，我们在另一篇文章「业务应用程序的日本年号・法定节假日・结算日处理 —— 抗改元设计与 JapaneseCalendar・营业日计算实务」中做了详细说明。本文则是把那套思路应用到 Power Automate 流程中的实践篇。

1. 先说结论

  • Recurrence 触发器的时间，如果不指定时区就会被当作 UTC 处理。「以为设置的是每天早上9点，结果却在日本时间18点运行」这种事故，可以通过在时区栏选择「(UTC+09:00) 大阪、札幌、东京」并明确指定开始时间来避免。12
  • 「仅在平日执行」可以用频率「周」+星期指定（周一至周五）来实现。但不会考虑法定节假日。像「每月20日」这样的固定日期，可以用开始日期时间+频率「月」来实现，但像「每月末」「结算日若为休息日则提前到前一个营业日」这样会变动的日期无法直接指定，因此实务上的解法是「每天执行、用表达式判定」。2
  • 表达式中的 utcNow() 也始终是 UTC。日本时间的「今天」需要先用 convertTimeZone(utcNow(), 'UTC', 'Tokyo Standard Time') 转换之后再使用。如果在早上8点这个时段运行的流程里忘记转换，「今天」就会变成前一天。34
  • 判定日本法定节假日的机制并未内置。表达式的函数列表中也没有法定节假日函数5，实务上的定式做法是自行维护一份法定节假日主数据表（SharePoint 列表等），在流程开头判定「今天是不是营业日」，不是营业日就终止流程。主数据表的一手数据来源可以使用内阁府公布的法定节假日 CSV。6
  • 提醒不要「一件一封」，而应按负责人汇总成一封。使用 Filter array、Create HTML table 等数据操作动作，就能避免 Apply to each 嵌套，搭建出更易读的流程。7
  • 定期执行的流程很难让人察觉「已经不再运行」。请以连续失败14天后关闭、90天内无触发则关闭、运行历史默认只保留28天这些规格为前提，从一开始就设计好失败通知与运行记录。89

2. 对「人看日历行动的业务」进行盘点

最先该做的不是搭建流程，而是把「靠看日历行动的业务」全部列出来，判断哪些适合定期执行。

业务 与定期执行的契合度 补充说明
每天早上的未处理・异常检查（订单、申请、库存） 适合 前提是判定条件能用列表中的列来表达
月末・结算日前的统一提醒（费用报销、考勤结算） 适合 需要把营业日调整（月末若为休息日则提前到前一营业日）规格化
超过提交期限的催办（文件、报告、审批搁置） 适合 前提是台账已经数据化（SharePoint 列表等）
定期报表的汇总・分发 视条件而定 汇总逻辑简单则用流程处理，复杂则流程只负责分发
月度的请款・付款等确定性处理（结算、红冲蓝字更正、重新计算） 多数不适合 分支与例外较多，失败时需要回滚（第8章）
跨越核心系统的夜间批处理 不适合 属于开发领域，重跑与一致性设计才是核心

分类的判断标准有三个：判定条件能否用数据表达（「感觉有点可疑的案子」是无法自动化的）、执行日的规则能否被语言化、即便失败，第二天能否恢复（做不到的属于第8章的开发领域）。

这三者当中，第二点在日本的业务场景下是最大的难关。即便说的是「每月末发送结算提醒」，实际上人在做的，其实是「月末如果是周末或法定节假日就提前到前一个营业日，黄金周所在的年份要在连休前发送」这类调整。请把这种默会知识写成规格的工作，看作是搭建流程的核心所在。如果对这一点含糊不清就直接做流程，就会出现「催办邮件在法定节假日发出去了」「连休前的提醒在连休期间发出去了」这类情况，进而失去信任。

3. Recurrence 触发器的基础与陷阱

定时执行的云端流程要创建为「已计划的云端流程」，通过 Recurrence（重复）触发器设置频率与间隔。1 频率可以从秒、分、小时、天、周、月中选择，间隔最小为60秒，最大为500天。8 规格本身很简单，但这也是一个陷阱很多的触发器。

陷阱1：默认是 UTC ── 「明明该是9点，却在18点运行」

这是最常见的事故。如果不选择时区，Recurrence 触发器的开始时间会被解释为末尾带 Z 的 UTC 格式（YYYY-MM-DDThh:mm:ssZ）。如果在时区栏选择日本，开始时间就会被当作该时区的本地时间（YYYY-MM-DDThh:mm:ss，不带 Z）来处理。12 如果要搭建一个「每天早上9点通知的流程」，正确做法是把时区设为「(UTC+09:00) 大阪、札幌、东京」，开始时间设为9:00。

陷阱2：不指定开始时间，保存的瞬间就会执行一次

如果不指定开始日期时间，第一次执行会在保存流程的那一刻立即触发。2 如果是在测试阶段，这没有问题，但如果是在傍晚保存一个内置了催办邮件的流程，就可能变成当场向所有人发出催办的事故。请务必指定开始日期时间。

此外，如果不在高级选项中指定「设定时间（这些小时/这些分钟）」，第二次及以后的执行时间会以上一次执行为基准做相对计算，延迟不断累积，就会导致执行时间逐渐产生偏移（漂移）。2 对于希望每天在固定时间运行的流程，除了开始日期时间之外，最好也明确指定执行时间，这样更保险。

陷阱3：「仅平日」可以实现，但月度的详细指定有限

把频率设为「周」，就能选择星期（周一至周五）；如果是「日」或「周」，还能指定执行时间（小时・分钟）。也就是说，「仅在平日的早上9点」光靠触发器的设置就能实现。但另一方面，这些详细选项只有在频率为「日」「周」时才能使用，频率为「月」时并没有可以指定「每月20日」「每月末」这类日期的字段。2

不过，如果是日期固定的月度处理，就不需要每天运行。把开始日期时间设为目标日期（例如下个月20日的9:00），频率设为「月」，执行就会以开始日期时间为起点每隔一个月进行一次，因此「每月20日9点」光靠触发器设置就能实现。2 把一个月只需运行12次的流程，改成每天启动365次、再用判定把大部分丢弃，会让运行历史变得难以阅读，也白白消耗请求配额，应当避免。

「每天执行+在流程开头用表达式判定今天是否为目标日」这种结构，是日期会变动的月度处理所必需的。像「每月末」（因月份不同为28～31日）、「如果20日是周末或法定节假日就提前到前一个营业日」、「每月第N个营业日」这类日期，无法用触发器表达。相关判定表达式将在下一章说明。另外需要注意，把29～31日作为固定开始日来指定时，需要通过实际实现去确认该日期不存在的月份会有怎样的行为，因此对月末附近的处理，从一开始就偏向「每天执行+判定」这一边会更安全。

陷阱4：夏令时 ── 仅需在面向海外据点时注意

如果不选择时区、直接用 UTC 时间来写，在有夏令时（DST）的地区，每次切换夏令时执行时间都会偏移一小时。如果预先选择了时区，日程就会跟随季节切换而保持一致。10 日本没有夏令时，所以仅限国内使用不会有实际影响，但如果用同一个流程处理面向海外据点的通知，就需要明确选择该据点所在的时区。

陷阱5：写在触发器里的表达式会在保存时被固定下来

在触发器的输入中写入类似 utcNow() 这样的表达式，该值会在保存流程的那一刻被计算并固定下来，不会在每次执行时重新计算。11 请记住，「因为想让开始时间是今天」而在触发器中写表达式的思路是行不通的。

陷阱6：关闭期间错过的执行，不会事后补跑

Recurrence 触发器在流程恢复运行后，并不会把关闭期间错过的日程集中补跑，而是从下一个周期重新开始。10 「因为要改造月末处理流程而关闭了几天，结果正好跨过了月末的执行日，导致这个月的处理没有运行」，这样的事故是有可能发生的。请把「关闭定期执行流程前先确认下一次预定执行日」作为一项运维规程。

4. 日期计算的工具箱 ── 用表达式判定月末・月初・结算日

流程内的日期计算，使用的是与 Logic Apps 共通的表达式（函数）。5 前提是 utcNow() 返回的始终是 UTC 的当前时间。12 因此，如果采用在流程一开始就生成「日本时间的今天」并存入变量（或 Compose），此后一直复用这种结构，表达式会更容易阅读。

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

convertTimeZone(时间戳, 源时区, 目标时区, 格式) 是用于时区转换的函数13，时区名称使用的是 Windows 时区列表中的名称。日本是「Tokyo Standard Time」。4 如果不想写表达式，也有一个功能相同的「转换时区」操作可以使用。13

之所以必须转换，是因为 UTC 与日本时间之间存在9小时的时差。在日本时间早上9点之前，UTC 那边还是前一天。如果在早上8点运行的流程里写 formatDateTime(utcNow(), 'yyyy-MM-dd')，返回的「今天」就会是前一天的日期。这种日期偏差会因执行时间的不同而时有时无，测试阶段很难察觉，往往是在生产环境中以「本该是月初的处理，却在月末最后一天也运行了」这种形式暴露出来。

下面整理生成「日本时间的今天」（以下称为 今天）之后的判定模式。

想做的事 表达式示例 补充说明
获取星期几 dayOfWeek(今天) 0=星期日，1=星期一，……，6=星期六。12
判断是否为周末 or(equals(dayOfWeek(今天), 0), equals(dayOfWeek(今天), 6)) 写成「大于5就是周末」会漏掉星期日（0）12
判断是否为月初（1日） equals(formatDateTime(今天, 'dd'), '01') 用 startOfMonth() 也可以直接取得月初的日期本身5
判断是否为20日结算的结算日 equals(formatDateTime(今天, 'dd'), '20') 结算日不要写死，改用环境变量或设置列表输出，方便复用
判断是否为月末 not(equals(formatDateTime(今天, 'MM'), formatDateTime(addDays(今天, 1), 'MM'))) 「如果今天的月份和明天的月份不同，那么今天就是月末」。在2月和闰年也能正确运行
本月的月末日期 addDays(startOfMonth(addToTime(今天, 1, 'Month')), -1, 'yyyy-MM-dd') 以「下个月月初的前一天」来推导。不需要在意每个月的天数
N天前・N天后 addDays(今天, -3) / addDays(今天, 7) 按日历天数加减。基于营业日的计算见第5章

addDays、addToTime、startOfMonth、formatDateTime、dayOfWeek 都是 Logic Apps/Power Automate 共通表达式参考中定义的函数。5 表格中的组合表达式本身是笔者的实现模式，因此在引入时，请先用跨越月末、月初、闰年（2月29日）的日期进行测试，再投入生产环境。「只在特定日期才会发作的日期 Bug 有多可怕，以及应该提前测试哪些日期」，我们已经在日本年号・法定节假日・结算日的文章的第4章中写过。

5. 营业日判定 ── 法定节假日用主数据表保存

不存在内置的法定节假日判定

再重复一遍，Power Automate 并没有判定日本法定节假日的内置功能。Recurrence 触发器的星期指定，顾名思义只会看星期几；表达式的函数列表也只到日期的加减、格式化、时区转换为止，没有能返回「这一天是不是法定节假日」的函数。5 关于「用计算公式求出法定节假日本身在原理上就是不可能的」（春分・秋分要到前一年才会确定，法定节假日本身也会因法规修订或特别措施法而变动）这一情况，我们已经在日本年号・法定节假日・结算日的文章的第3章中详细说明过。结论是一样的：法定节假日应以数据（主数据表）+更新运维的方式来保存，这才是正解。

在 Power Automate 中保存法定节假日，比较简便的方式是在 SharePoint 列表中建一份「法定节假日主数据表」（日期列+名称列）。一手数据来源可以使用内阁府公布的、从昭和30年到次年为止的法定节假日日期・名称 CSV（替代休息日也作为行包含在内）。6 由于公布的只是已确定的部分，设计工作要一直做到每年一次，把次年的数据导入主数据表这项工作纳入业务日历为止。一旦忘记更新，就会在次年的法定节假日上，直接以催办通知发出去的形式表现为误动作。此外，暑期休业、公司周年纪念日这类公司休业日，请不要混入法定节假日主数据表，而应另建一份列表。这是因为「银行转账的到期日判定只看法定节假日」「公司内部催办还要看公司休业日」——不同用途所应参照的休息日集合是不一样的。

流程开头的「营业日守卫」

只想在营业日运行的流程，除了 Recurrence 的星期指定（周一至周五）之外，还需要在流程开头放置以下判定。

  1. 生成「日本时间的今天」（第4章）
  2. 对法定节假日主数据表执行 SharePoint 的「获取多个项目（Get items）」，用类似 HolidayDate eq '今天' 的过滤查询检索今天的日期14
  3. 对公司休业日列表也执行同样的检索
  4. 只要命中一条，就用「终止（Terminate）」操作停止执行

Terminate 是当场停止流程执行、并以指定状态（成功/失败/取消）结束的操作（不能放在 Apply to each 或 Do until 循环内）。15 把这里的状态设为「已取消」，就能在运行历史上一眼区分「因非营业日而跳过的日子」和「实际执行了处理的日子」。比起全部统一设为「成功」，这样做能让后续排查轻松很多。

「提前到前一个营业日」与「N个营业日前」

月末结算提醒实际需要的并不是「每月末」，而是「月末如果是休息日，就提前到前一个营业日」。这可以在每个营业日都执行的流程中，通过判定「今天是营业日，且从明天到月末之间没有任何一天是营业日」来表达。具体实现上，会依次遍历从明天到月末日期（第4章的表达式）之间的每一天，一旦找到一个既不是周末、也不在法定节假日主数据表中的日子，就确定「今天不是最后一个营业日」并跳出循环。

像「在付款到期日的3个营业日前催办」这样的N个营业日前，思路上也是同样的转换。把「到达到期日的N个营业日前时」，替换成「每个营业日都执行，统计从今天到到期日之间的营业日数，如果与 N 相符」。营业日的统计方式，只是统计「不是周末・不在法定节假日主数据表中・不在公司休业日中」的天数而已。不过，用流程循环逐天统计日期的处理，一旦目标案件超过数百件，就会变成件数×天数规模的循环，执行时间和 API 调用次数都会膨胀。到了这种规模，把营业日计算移到流程之外（数据库中的营业日表或一个小型 API），或者当作第8章所说的开发领域来处理，会更健康。

6. 提醒・催办的设计 ── 按负责人汇总成一封

前提：台账已经数据化

只有当「是什么・由谁负责・截止到什么时候」能够以数据形式取得时，才能把超期催办自动化。如果台账目前还是共享文件夹里的 Excel、靠邮件附件传阅，请先考虑将其替换为 SharePoint 列表（把 Excel 台账替换为 SharePoint 列表一文对此有专门说明）。以下内容以 SharePoint 列表中已有「期限」「状态」「负责人」列为前提。

提取时在取得阶段就先筛选

提取超期数据时，不要先取出列表全部内容再在流程内做条件分支，而应通过 Get items 的过滤查询（OData 过滤器）在服务器端就先筛选出来。14

DueDate lt '2026-07-18' and Status ne '已完成'

日期部分需要嵌入第4章中生成的「日本时间的今天」表达式。请注意，过滤查询中的列名必须使用 SharePoint 的内部名称，而不是界面上显示的名称；默认情况下只会返回100条记录，因此条目较多的列表需要指定上限（Top Count）或配置分页。14

避免 Apply to each 地狱 ── 如何汇总成一封

如果直接把提取结果放进 Apply to each 逐条循环发邮件，只要负责人 A 有10件未处理，每天早上就会收到10封邮件。这样持续几周，通知肯定就没人读了，提醒机制本身也会失效。原则是按负责人把通知汇总成一封。使用数据操作动作，可以按下面的流程来搭建。7

  1. 用 Select 从提取结果中生成负责人邮箱地址的数组，再用 union() 去重，生成「今天应通知的负责人清单」5
  2. 用 Apply to each 遍历负责人清单，在循环内用 Filter array 提取「仅属于该负责人的记录」
  3. 用 Create HTML table 整理成包含标题、期限、状态的表格，嵌入邮件（或 Teams 消息）正文中，只发送这一封（邮件的情况下需要启用 HTML 显示7）

整体结构如下所示。

有没有没有有Recurrence 触发器平日 早上9:00 时区：大阪、札幌、东京生成日本时间的今天convertTimeZone法定节假日主数据表・公司休业日中是否有今天Terminate 已取消因非营业日而终止Get items提取超期且未完成的记录有目标记录?结束 无通知用 Select 生成负责人清单用 union 去重按负责人循环Filter array仅提取该负责人的记录用 Create HTML table 整理成表格向负责人发送一封通知Teams 或 Outlook把执行结果记录到日志列表

Teams 与 Outlook 的分工使用

通知的出口，应根据性质分开使用。

视角 Teams（聊天・频道） Outlook（邮件）
易于察觉程度 高，但容易被淹没在消息流中 不容易造成通知疲劳，但会淹没在收件箱里
留存记录性 弱，事后不易查找 会留存，可用作催办的证据
发送对象 仅限公司内部 也可发给公司外部
适合的通知 每天早上的未处理事项摘要等日常轻量通知 截止日期的正式通告、需要留存催办记录的内容、发给外部的通知

常见的做法是：日常摘要用 Teams，结算日前的正式提醒与超期催办用邮件，这样分开使用。往两边都发送相同内容，只会增加通知的总量，因此不推荐这样做。

不要催办过度的设计

提醒自动化最可怕的地方，在于发送过多、结果全部被忽略。人工催办有一种「因为不好开口所以自然会控制频率」的天然刹车，但流程没有这个机制，需要在设计中主动加入。

  • 设计好总量。每天早上・全员・全部记录是最糟糕的模式。收紧发送条件，例如日常只发送当天到期和已超期的部分，事前提醒只在3个营业日前和前一天各发一次。
  • 设置阶梯。先只通知本人，超期持续 N 个营业日后再把上级加入收件人，这样区分升级方式。如果从一开始就全部发给上级，通知就只会变成噪音。
  • 建立会停止的机制。务必准备一个出口：负责人只要把列表的状态列改为「已完成」，从第二天起通知就会停止。如果完成报告一直只靠邮件回复来处理，流程就会持续催办下去，负责人也会渐渐厌恶这个流程。
  • 让「没有收到通知＝没有问题」保持可信。这一点只有和下一章的监控配套起来才能成立。

7. 运维注意事项 ── 定期执行的流程「停了也很难察觉」

事件触发型的流程，业务方会自己察觉到「明明申请了却没动静」。但定期执行的流程没有这样的探测器。即使月末提醒已经停止，也只会在没人说什么的情况下，结算就这样被延误了。请在运维设计中以下面这些规格为前提。

  • 存在会让流程自动关闭的条件。触发器或操作持续失败的流程会在14天后关闭，持续被限流的流程同样会在14天后关闭。此外，90天内一次都没有被触发过的流程也可能被关闭（所有者持有高级许可证或容量许可证（如 Process）的流程除外；关闭前30天会通知所有者及共同所有者，重新打开即可继续使用）。8 如果要搭建一个「每季度只运行一次的流程」，就需要留意这条90天规则。
  • 运行历史默认只能看到28天。9 对于月度流程来说，算下来只能确认最近一次的记录。在流程最后加入一步，把「运行日期时间・处理件数・结果」追加记录到一份用于日志的 SharePoint 列表中，这样就能不受历史过期的影响，去确认「上个月是否正常运行了」。第6章的示意图之所以把日志记录放在最后，原因就在这里。
  • 让流程自身具备察觉失败的机制。如果不加入「失败时通知管理员」的分支（在运行条件设置中配置为「失败时」运行的操作），在被关闭之前的14天里，没有人会察觉到失败。错误处理与重试的搭建方式，我们在「Power Automate 的错误处理与重试设计」中做了详细说明。
  • 所有者离职・调岗会连带日程一起停止。Recurrence 触发器的流程，是以创建者的连接来执行的。11 一旦所有者的账户被禁用，连接就会断开，流程开始失败，最终被关闭。请在上线首日就完成共同所有者的设置与连接的盘点。16 交接的实务做法，我们整理在「Power Automate 摆脱人员依赖的对策 ── 所有者・连接・交接」一文中。
  • 关闭期间的部分不会补跑（第3章陷阱6）。因改造或故障处理而关闭流程时，请先确认下一次预定执行日，并事先决定好：如果跨过了该日期，就用手动执行来补上。10

8. Power Automate 该做到什么程度

定期执行是自动化很好的切入口，但把「定期运行的东西」不分青红皂白全都做成流程是危险的。下面列出划界的大致标准。

情况 判断
每天早上的未处理检查、期限提醒、结算日前的统一通知 Power Automate 的擅长领域，本文的结构已经足够
包含营业日判定・提前到前一个营业日的通知 Power Automate + 法定节假日主数据表可以实现，需要把主数据表的更新运维一并定下来
数百件 × N 个营业日的计算、跨多个列表核对的汇总 流程循环会比较吃力，需要把逻辑移到外部，或归为开发领域
结算日因交易对象而不同、涉及红冲蓝字更正或重新计算的结算处理 分支会爆炸式增长，失败时也需要回滚，属于外包开发・专用系统的领域
跨越核心系统数据库的夜间批处理 属于开发领域，事务・重跑・一致性设计才是核心
只有一台服务器、在公司内部就能完成的文件处理・数据库处理的定期执行 PowerShell + 任务计划程序也是有力选项，比较请参见另一篇文章

大致的感觉是，界线大概落在「让人察觉」为止交给 Power Automate，「确定下来」（改写核心系统的数据）则交给开发。笔者见过好几个想把结算处理本身做成流程、结果分支多到爆炸的案例，多数最终都是通过重新划分为「结算的执行交给既有系统或外包开发，只有防止漏结算的通知留在流程里」才稳定下来的。另外，如果是不经过云端、在服务器内部就能完成的定期处理，PowerShell 与任务计划程序有时会更简单、更容易维护。两者的使用区分，我们整理在「Power Automate 与 PowerShell/任务计划程序的使用区分」一文中。

9. 总结

定期执行流程设计的核心，与其说在于 Recurrence 触发器本身的设置，不如说在于它前面和后面的部分。前面的核心，是把「看着日历行动」这种默会知识规格化：月末如果是休息日该怎么办，法定节假日由谁、在什么时候录入主数据表。不把这些先定下来就做出的流程，在日本的日历面前一定会出问题。后面的核心，是用来察觉「已经停止」的运维：28天的运行历史、各种自动关闭的条件、因所有者离职而停止的日程。请以「定期执行的流程会悄无声息地停止」为前提，从一开始就把失败通知与运行日志纳入设计。

技术层面的要点可以归纳为三条：时间要明确指定时区（默认是 UTC）、日期要先转换为日本时间再判定、法定节假日用主数据表保存，并在流程开头用营业日守卫拦截。把这三点掌握好之后，再把通知按负责人汇总，给催办加上阶梯与出口。做到这一步，「人看着日历行动」的这类业务，相当大一部分都可以放心地替换为可信赖的定期执行流程。而当你开始想要涉足结算处理、核心系统批处理这类「确定下来」的处理时，那就是考虑切换到开发领域的时机了。

相关文章

相关咨询领域

合同会社小村软件（合同会社小村ソフト）承接从 Power Automate 定期处理・提醒的设计评审，到流程无法胜任的结算处理・营业日计算・核心系统联动批处理开发在内的一系列工作。

参考链接

  1. Microsoft Learn, Run a cloud flow on a schedule。关于创建已计划云端流程的步骤、在 Recurrence 触发器的时区栏中指定开始时间应按哪个时区处理，以及开始时间的格式（YYYY-MM-DDTHH:MM:SSZ）的说明。 ↩ ↩2 ↩3

  2. Microsoft Learn, Schedule and run recurring workflows with the Recurrence trigger in Azure Logic Apps。关于未选择时区时开始时间会被解释为末尾带 Z 的 UTC、频率与间隔的指定方式、星期指定（weekDays）仅在频率为「周」时可用・时间指定（hours/minutes）仅在频率为「日」「周」时可用、不指定开始日期时间则保存时会立即触发第一次执行，以及在没有详细时间指定的情况下执行时间会因相对上一次执行计算而产生漂移的说明。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

  3. Microsoft Learn, Customize or format date and time values in a flow。关于 Power Automate 默认使用 UTC，以及组合使用 formatDateTime 与 convertTimeZone 来处理本地时间的方法的说明。 ↩

  4. Microsoft Learn, Default Time Zones。Windows 的时区名称一览，以及日本（UTC+09:00 大阪、札幌、东京）的时区名称为「Tokyo Standard Time」的说明。 ↩ ↩2

  5. Microsoft Learn, Reference guide to functions in expressions for workflows in Azure Logic Apps and Power Automate。表达式中可用的日期函数（utcNow、addDays、addToTime、startOfMonth、formatDateTime、dayOfWeek、convertTimeZone 等）与集合函数（union 等）的一览与语法，也是确认「不存在判定法定节假日的函数」这一说法的出处。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  6. 日本内阁府, 关于「国民节假日」。关于依据《国民节假日相关法律》制定的法定节假日一览、春分日・秋分日于前一年确定并公布、调休规定，以及提供自昭和30年至次年为止的法定节假日月日・名称 CSV 的说明。 ↩ ↩2

  7. Microsoft Learn, Use data operations。关于 Select、Filter array、Join、Create HTML table 等数据操作动作的用法，以及通过邮件发送 HTML 表格时需要启用 IsHtml 的说明。 ↩ ↩2 ↩3

  8. Microsoft Learn, Limits of automated, scheduled, and instant flows。关于重复间隔最小60秒・最大500天、触发器或操作持续失败的流程会在14天后关闭、90天内未被触发的流程可能被关闭（高级许可证・容量许可证所有者的流程除外，关闭前30天会通知所有者及共同所有者），以及持续被限流的流程会在14天后关闭的说明。 ↩ ↩2 ↩3

  9. Microsoft Learn, Missing runs or triggers history for a flow。关于流程的运行历史默认只保存28天的说明。 ↩ ↩2

  10. Microsoft Learn, Schedules for recurring workflow triggers in Azure Logic Apps。关于不选择时区时执行时间会因夏令时切换而偏移一小时、选择时区则日程会跟随季节变化，以及 Recurrence 触发器在停止期间错过的日程不会事后补跑、而是从下一个周期重新开始的说明。 ↩ ↩2 ↩3

  11. Microsoft Learn, Troubleshoot Power Automate trigger issues and errors。关于写在触发器输入中的表达式（utcNow() 等）会在流程保存时被计算并固定、不会在每次执行时重新计算，以及 Recurrence 触发器的流程是以创建者的连接来执行的说明。 ↩ ↩2

  12. Microsoft Learn, Expression cookbook for cloud flows。关于 utcNow() 始终返回 UTC、dayOfWeek() 的返回值为 0=星期日至6=星期六，以及用「大于5」来判定会漏掉星期日的说明。 ↩ ↩2 ↩3

  13. Microsoft Learn, Convert a time zone。关于 convertTimeZone 表达式的参数（时间戳・源时区・目标时区・格式），以及功能相同的「转换时区」操作的说明。 ↩ ↩2

  14. Microsoft Learn, In-depth analysis into Get items and Get files SharePoint actions。关于 Get items 的 OData 过滤查询（eq/ne/lt/gt 等、嵌入表达式）、默认获取件数为100件、可通过 Top Count 更改，以及超过5,000件的列表需要配置分页的说明。 ↩ ↩2 ↩3

  15. Microsoft Learn, Schema reference guide for trigger and action types in Azure Logic Apps。关于 Terminate 操作会停止执行并返回指定状态（Succeeded/Cancelled/Failed），以及不能放在 Foreach 或 Until 循环内的说明。 ↩

  16. Microsoft Learn, Share a cloud flow。关于共同所有者能够做的事（编辑流程、更新连接的凭据等），以及连接与创建者本人绑定的说明。 ↩

相关文章

共享相同标签的最新文章。可以围绕相近的主题进一步加深理解。

相关主题

与本文相近的主题页面。以本文为起点，可以进一步了解相关服务和其他文章。

与本主题相关的服务

本文与以下服务页面相关联，欢迎从最接近的入口查看。

常见问题

汇总了咨询这一主题时常见的问题。

如何让 Power Automate 的定时流程在日本时间每天早上9点运行？
在 Recurrence 触发器的时区栏中选择「(UTC+09:00) 大阪、札幌、东京」，并指定开始时间。如果不指定时区，开始时间会被当作末尾带 Z 的 UTC（协调世界时）来处理，因此按「9:00」的想法设置，实际会在日本时间18点运行。此外，表达式中的 utcNow() 也始终返回 UTC，所以在流程中使用「今天的日期」时，需要先用类似 convertTimeZone(utcNow(), 'UTC', 'Tokyo Standard Time', 'yyyy-MM-dd') 的方式转换为日本时间后再使用。
Power Automate 有判定日本法定节假日的功能吗？
并没有内置这样的功能。Recurrence 触发器的星期指定可以实现「仅平日」运行，但不会考虑法定节假日，表达式的函数列表中也没有返回法定节假日的函数。实务上的做法是自行准备一份保存法定节假日日期的主数据表（如 SharePoint 列表），在流程开头检索「今天是否在主数据表中」，如果不是营业日就终止流程。主数据表的更新源，可以使用内阁府公布的法定节假日 CSV 作为一手数据来源。
能不能只在每月末的营业日执行流程？
如果是「每月20日」这种固定日期，把开始日期时间设为目标日期、频率设为「月」，就可以以开始日期时间为基准，实现每月同一天、同一时间的执行。但另一方面，Recurrence 触发器没有可以直接指定「每月末」的选项，星期或时间的详细指定也只有在频率为「日」「周」时才能使用。像月末这样日期会变动的处理，应改为每天（或每个平日）都执行的流程，在开头用表达式判定「今天是不是月末」「今天是不是营业日」，不符合条件的日子就终止流程。月末判定可以用「如果今天的月份和明天的月份不同，那么今天就是月末」这样的表达式来写。「月末如果是周末或法定节假日，就提前到前一个营业日执行」，也可以在同样的结构中加入对法定节假日主数据表的判定来实现。
定期执行的流程在不知不觉间被关闭了。为什么会这样？
Power Automate 有几种会让流程自动关闭的条件。触发器或操作持续失败的流程会在14天后关闭，持续被限流（超出限制）的流程同样会在14天后关闭。此外，90天内一次都没有被触发过的流程也可能被关闭（所有者持有高级许可证或容量许可证的情况除外，并会在关闭前30天通知所有者及共同所有者）。由于定期执行的流程即使停止运行也很少有人察觉，所以从一开始就把失败通知和运行记录纳入设计是很重要的。

作者简介

本文作者的个人简介页面。

Go Komura

小村软件有限公司 代表

以 Windows 软件开发、技术咨询与故障排查为中心，擅长难以复现的故障调查，以及既有资产仍在运行的项目。

联系我们
返回博客列表