Power Automate 的错误处理与重试设计 ── 防止「原本正常运行的流程不知不觉停止了」

「每天早上都会运行的汇总流程，其实从上周开始就已经停止了」「订单登记流程把同一份数据处理了两次，台账里出现了重复记录」。我们经常从开始使用 Power Automate 构建并运营流程的企业那里收到这类咨询。构建流程本身很简单，但流程停止运行这件事却没有任何人注意到——这是一种常见的模式。

如果只考虑正常路径，Power Automate 的流程只需几个小时就能搭建完成。但连接的服务会出现暂时性故障，身份验证会过期，超出预期的数据也一定会出现。没有设计「失败时会发生什么」的流程，会在不知不觉间不断累积失败，最坏的情况下会在 14 天后被自动关闭¹。本文将整理经得起生产环境考验的错误处理设计模式，内容涵盖流程失败的分类、标准重试的确切规范、基于范围(Scope)构建的 Try-Catch-Finally 模式、发现失败的机制，直至重新执行与幂等性。关于 Power Automate 整体的使用场景划分，以及 UI 自动化(桌面流程)一侧的错误处理，已经在《用 Power Automate 实现业务自动化 ── 云端流程与桌面流程的使用场景划分及错误处理设计》中讨论过，因此本文将聚焦于对云端流程的深入剖析。

1. 结论先行

• 可以把失败分成四类来考虑：「暂时性故障」「数据引起」「权限/身份验证过期」「规格变更」。标准重试只能解决第一类，其余三类都需要检测与修正的机制²。
• 标准重试策略只有在请求超时，或者以 408、429、5xx 响应失败时才会生效。默认采用指数退避，重试次数根据许可证层级(性能配置文件)不同，最多为 2 次或 12 次³¹。
• 错误处理的基本形态是通过范围(Scope)与「运行后配置」(Configure run after)构建的 Try-Catch-Finally。运行条件可以从「成功时・失败时・已跳过时・已超时」这四种状态中选择³⁴。
• 在 Catch 中处理完失败后，最后要用 Terminate 操作把该次运行记录为「失败」。如果忘记这一步，运行历史记录中会显示为成功，失败就会被悄悄掩盖⁴³。
• 默认的失败通知邮件仅限于「已知有修复方法的失败」，并且附带 28 天的冷却期，如果完全依赖它，漏洞会相当多。应当把从 Catch 代码块中自行发送通知视为必需项⁵。
• 运行历史记录默认只能查看28 天以内的内容。持续失败的流程会在14 天后被自动关闭。「一个月后才发现流程早就停止了」在规范上是完全可能发生的⁶¹。
• 为应对重新执行(重新提交)与重复触发，从一开始就应引入即使运行两次也安全的幂等设计(已处理标志、用 upsert 取代「创建」、触发条件)⁷⁸。

2. 流程是如何失败的 ── 失败的四种分类

从「如何失败」的分类入手来设计错误处理，会更容易理清思路。Microsoft 的官方指南也要求将自动化视为必然会失败的对象，需要预先设想连接服务的维护、API 变更、密码变更、瞬时网络故障等情况²。在实务中，按下面这四种分类来思考，应对方式几乎可以直接确定下来。

其中在实务中最棘手的是权限・身份验证过期。因为失败的不只是流程中的操作，就连触发器本身也会开始失败。触发器以 4xx 系错误失败的典型示例，就是连接所使用的密码发生变更(过期)——这一点在官方故障排查文档中也有提及。触发器一旦失败，流程根本不会启动，运行历史记录中甚至不会留下「失败」这一行记录，导致发现问题的时间进一步推迟⁹。由于连接是与创建它的个人用户绑定的，负责人离职或调动也可能引发连接集体失效的事故。关于这方面的组织性对策，在《Power Automate 的人员依赖对策 ── 所有者・连接・交接的设计》中有详细说明。

还有一点需要知道的是，放任失败不管会导致流程本身被关闭。触发器或操作持续失败的流程会在 14 天后被自动关闭，持续被节流限制的流程同样会在 14 天后关闭。90 天内一次都没有被触发过的流程，如果所有者没有持有高级版或容量许可证，也可能会被关闭¹。此外，由于违反 DLP 策略或反复失败，流程有时也会进入「中断(suspended)」状态¹⁰。「原本正常运行的流程不知不觉停止了」，其中有一部分原因并非故障，而是这项规范本身导致的。

3. 理解标准重试

Power Automate(底层基于 Azure Logic Apps)的操作从一开始就内置了重试策略。首先准确掌握这项规范，才能判断「是否应该追加重试设置」以及「重试是否根本无法解决问题」。

什么会被重试、何时会被重试

重试策略只在操作(或触发器)的请求超时，或以 408(请求超时)・429(请求过多＝节流限制)・5xx(服务器错误)响应失败时才会生效³。默认策略是指数退避(在重试的同时按指数方式延长间隔)，Power Automate 中的默认重试次数与间隔，会因流程的性能配置文件(performance profile)(实质上取决于许可证层级)而不同¹。

也就是说，即便是同一份流程定义，「面对暂时性故障时的韧性」也会因所有者的许可证而不同。性能配置文件不仅影响重试次数，也会影响每日请求数量上限，因此关于许可证层级的思路，也可以参考《Power Automate 的许可证与标准/高级连接器的边界》一文。

重试策略可以在操作的设置中进行修改。类型共有默认・无・固定间隔・指数间隔四种，可以明确指定次数与间隔。配置上限为次数 90 次・最小间隔 5 秒・最大延迟 1 天³¹。Microsoft 的编码指南中，针对从暂时性故障中恢复的场景，推荐使用指数间隔而非固定间隔，目的是避免以过短的间隔持续请求，从而妨碍对方服务自身的恢复⁴。

重试能解决的问题・无法解决的问题

需要注意的是，重试本身同样会消耗请求数量(Power Platform 请求)。无论成功还是失败，操作的执行都会计入请求数量，重试与分页请求也是如此¹。针对 429 而一味增加重试次数的调整，有时反而会让节流限制进一步恶化，因此在加厚重试之前，应先考虑「能否减少调用次数本身」。

4. Try-Catch-Finally 模式 ── 范围(Scope)与运行后配置

无法通过重试解决的失败，需要在流程内部捕获并处理。Power Automate 并没有 try-catch 这样的语法，但可以通过组合范围(Scope)与「运行后配置」(Configure run after)来搭建出相同的结构。这也是 Microsoft 编码指南中推荐的标准做法⁴。

支撑起整个机制的基础就是运行后配置。每个操作在完成时都会具有成功(Succeeded)・失败(Failed)・跳过(Skipped)・超时(TimedOut)四种状态之一，后续操作在默认情况下只会在「上一个操作成功时」执行。这个条件可以按操作逐一修改，从而搭建出在「失败时」「超时时」执行的分支³。

把这一机制应用到范围(Scope)上，就构成了 Try-Catch-Finally。由于范围会把其中所包含的全部操作的结果汇总为一个整体状态，因此「只要 Try 范围内的任何位置发生失败，就执行 Catch 范围」这种结构，相比逐个操作单独设置条件，维护起来要轻松得多³⁴。

flowchart TD
    Trigger[触发器] --> Try[[Try 范围<br/>把主要处理都放在这里]]
    Try -- 成功 --> Fin
    Try -- 失败 / 超时 --> Catch[[Catch 范围<br/>运行条件: 失败或超时时]]
    Catch --> Extract[用 result 函数 + 数组筛选<br/>提取失败的操作与原因]
    Extract --> Notify[通过 Teams / 邮件通知负责人<br/>流程名称・失败步骤・错误详情・运行 URL]
    Notify --> Fin[[Finally 范围<br/>运行条件: 成功・失败・跳过・超时全部]]
    Fin --> Cleanup[收尾处理・更新台账的状态列]
    Cleanup --> Judge{是否经过了 Catch}
    Judge -- 是 --> Term[Terminate<br/>状态: Failed，结束运行]
    Judge -- 否 --> Done([正常结束])

搭建时有以下四个要点。

• Catch 范围的运行条件要同时勾选「失败时」和「超时时」。要去掉默认勾选的「成功时」。如果只选择「失败时」，等待审批或延迟操作产生的超时就会被漏掉³。
• 在 Catch 中提取失败的具体内容。result('Try 范围名称') 函数会以数组形式返回范围内各操作的结果(状态・输入输出・错误正文)，因此通过「筛选数组」把状态限定为Failed 或 TimedOut，就能把失败的操作名称与错误消息放入通知中³⁴。如果只用 Failed 来筛选，当经由超时进入 Catch 时，提取结果就会变成空的，导致通知中恰恰缺失了最关键的失败步骤。同时，从 workflow() 函数中取出运行 ID，并据此拼装出指向运行历史记录的直达链接 URL，能让排查工作一下子轻松许多⁴。
• Finally 范围的运行条件要选中全部四种状态。无论成功还是失败都必须执行的收尾处理(删除临时文件、更新台账的状态列等)放在这里。
• 失败的运行，最后要用 Terminate 操作将其结束为「失败」。这是最容易被遗忘的一点。如果 Catch 正常执行完毕，那么整个流程运行就会以最后一个操作成功结束而告终，运行历史记录中会记为「成功」。也就是说，如果只是发送通知就结束，运行历史记录中就看不到失败，从而在监控和后续统计中被遗漏。用 Terminate 将状态设置为 Failed 并附上错误消息后再结束，运行历史记录中也会保留为失败⁴³。不过，不能把 Terminate 直接放在 Catch 范围的末尾。因为 Terminate 会在那一刻立即结束整个运行，导致后续的 Finally 范围不会被执行，恰恰跳过了错误发生时最需要的收尾处理。如图所示，应让 Catch 只设置失败标志(变量)并止步于发送通知，在经过 Finally 的收尾处理之后再判断该标志，只有在失败时才通过 Terminate 结束运行，按这样的顺序来安排。

另外，运行后配置在审批流程的超时分支(催办・升级)中同样是核心组件。具体的搭建方法在《用 Power Automate 构建审批流程 ── 把纸质与邮件形式的审批・申请电子化》中有说明。

5. 发现失败的机制 ── 通知与可视化

即便搭建了错误处理，如果没有人注意到失败，也是毫无意义的。「发现失败的机制」不应依赖默认通知，而要采用多层设计。

正确理解默认的失败通知邮件

Power Automate 具备在失败时发送邮件通知的机制，但如果不了解其规范就一味依赖，会漏洞百出。通知共有两种⁵。

• 单次运行失败警报: 会在运行失败后立即发送，但只有在被判定为连接失效・节流限制・已知连接器错误等「已知有修复方法的失败」时才会发送。一般性的操作失败不会触发发送。收件人为所有者与共同所有者(不包括仅限运行的用户)，不会发送给管理员。此外，一旦发送过一次，同一流程就会进入28 天的冷却期，在此期间发生的失败不会再收到额外的警报。单次运行警报也并非在所有流程中默认开启，需要在流程设置中加以确认⁵。
• 每周失败摘要: 每周会发送一次跨环境的失败汇总。单次运行警报不会发送的一般性失败也会被包含在其中⁵。

除此之外，针对特定错误，还会向所有者发送附带修复步骤的「修复提示」邮件(也可以按流程逐一关闭)⁷。总结来说，默认通知是一种「能够注意到第一次的连接失效，但业务数据引起的失败以及第二次及以后的失败很容易被漏掉」的机制。对于重要的流程，请将第 4 章中从 Catch 代码块发出的自定义通知视为必需项。

从 Catch 设计通知 ── 通知流程本身也会失败的情况

自定义通知同样也有设计要点。

• 不要将收件人设为个人。如果发给负责人个人，一旦该人员外出或离职，就没有人能收到通知了。官方文档也推荐发送到共享邮箱或 Teams 频道¹⁰。
• 让通知路径与主处理分开。常见的事故是「Outlook 连接中断导致流程失败，而失败通知同样使用这条 Outlook 连接，因此也发不出去」这种连带崩溃。当失败原因是身份验证过期时，使用同一连接的通知操作也会同时失败。将通知改为 Teams 发帖等与主处理不同的连接器・不同连接，或者拆分成专门用于通知的小型流程并单独调用，都可以降低连带崩溃的风险。即便如此，「通知的通知」也不可能无限地叠加下去，因此把接下来的定期检查作为最后一道防线。
• 通知中要包含排查所需的全部信息。流程名称、失败的操作名称、错误消息、指向运行历史记录的直达链接。如果缺少这些信息，即使收到通知，也只能知道「有什么东西失败了」而已，很容易被搁置不管⁴。

可视化与定期检查

• 流程检查器(Flow Checker): 会在保存之前检测流程定义中的错误与警告。养成在完成搭建后检查一次的习惯¹¹。
• 定期检查运行历史记录: 流程的运行历史记录默认只能显示28 天以内的内容⁶。纳入解决方案(Solution)的流程可以将运行历史记录的元数据保留在 Dataverse 中，但默认保留期同样是 28 天，延长保留期属于管理员一侧的设置¹²。对于生产环境中的流程，建议每周检查一次，检查内容不仅限于失败，还应包括「处于已取消状态的运行」(有时由并发控制引起)以及「运行次数骤减」(触发器未正常工作的迹象)¹⁰。
• 管理员的统一监控: 如果要查看包括不会发送单次运行警报邮件的失败在内的全部记录，Power Platform 管理中心的 Monitor(监控)功能最为全面，可以按流程或按环境确认失败件数与错误详情⁵。

对于定期执行的流程，还需要监控「是否真的启动过」这一点。包含营业日判断与月末处理的定期执行设计，在《Power Automate 的定期执行流程与营业日设计》中有说明。

6. 重新执行与幂等性 ── 打造「即使运行两次也不会出问题」的设计

应对失败并不是发现问题就结束了。「把失败的部分重新执行一遍」的操作，与「即使重新执行也不会出问题」的设计，二者需要配套使用。

重新提交(Resubmit)的规范

失败的运行可以从运行历史记录中通过重新提交(Resubmit)来重新执行。这是用相同的触发数据重新运行的操作：如果是暂时性故障(500/502 等)，可以直接重新提交；如果原因是流程定义有误，修正并保存之后再重新提交，就会按照修正后的定义重新执行⁷。从运行历史记录的列表中，一次最多可以批量重新提交 20 条记录，可用于大量失败时的恢复。对于手动启动(即时触发器)的流程，自己的运行随时都可以重新提交，但重新提交其他用户启动的运行，需要管理员通过租户设置进行授权¹³。

这里需要特别注意的是，重新提交会把流程从头开始重新执行一遍。如果对一个在 10 个步骤中的第 8 步失败的运行进行重新提交，原本已经成功的第 1～7 步也会再执行一次。「邮件明明已经发送过了却又发了一遍」「台账里出现了两行相同的记录」这类事故正是由此产生的。

幂等性 ── 即使重复执行也安全的设计

因此，需要从一开始就引入无论用相同的输入执行多少次，结果都保持一致(幂等)的设计。这不仅对重新提交有效，对触发器的重复触发与并行执行同样有效，是错误设计的核心所在。

• 保留已处理标志。给 SharePoint 列表之类的台账加上「状态」列(未处理/处理中/已处理)，在流程的开头确认状态，若已处理则就此结束，处理完成后再更新状态。这样一来，即使重新提交也不会导致重复处理。不过，这个标志只有在连更新顺序也一并确定下来之后才能真正生效。对于发送邮件、登记到核心系统这类会产生外部副作用的操作，应在执行前先将状态更新为「处理中」，完成后再改为「已处理」。在副作用发生之后・标志更新之前失败的运行，会一直停留在「处理中」状态，处于无法判断副作用是否已经完成的状态。如果机械地对这一行进行重新提交，可能会造成重复发送，因此应把「处理中」的行排除在自动重新执行的对象之外，改为由人核对实际的发送结果・登记结果之后，再手动把状态改回「已处理」或「未处理」。只有停留在「未处理」状态的行，才可以放心地重新执行。
• 使用「若存在则更新，若不存在则创建」(upsert)，而不是单纯的「创建」。用具有唯一性的键(订单编号、申请 ID 等)检索已有的行，命中则更新，未命中则创建，做成这样的分支。无条件的「创建项目」，每重新执行一次都会累积出重复的行。反过来说，没有唯一键的数据是无法做到幂等的，因此在台账设计阶段就确定好键列，是这一切的前提条件。
• 用触发条件阻止不必要的启动。诸如「在项目被创建或修改时」触发的流程，因为自身的写回操作而再次触发自己这种重复触发的情况，应该用触发条件(trigger conditions)来阻止，而不是靠后段的条件分支。不满足触发条件的事件根本不会产生运行，因此既不消耗运行次数，也不消耗请求数量⁸。

有一点需要注意。像已处理标志或 upsert 这样「先确认再写入」的方式，对重新提交这种顺序性的重做是有效的，但单独使用并不能提供原子性的保护。如果重复的触发事件几乎同时启动了两次，就可能出现两次运行都读取到「未处理」状态，然后双方都继续处理下去的竞态问题。要在可能出现并行触发的流程中确实地防止重复，需要结合下一节的用并发控制把并行度设为 1 来实现串行化，或者在存储端使用能够强制唯一键约束的机制(例如数据库的唯一约束)，让重复的创建在写入时直接失败，这两种设计需要配合使用。

并发控制(Concurrency Control)与顺序之间的权衡

与重复执行并列的另一个问题是「并发」与「顺序」。默认情况下，如果满足触发条件的事件同时大量发生，流程会不限数量地并行运行¹。当多个运行同时对台账的同一行进行读写时，可能会出现读取到旧值后再覆盖写入的不一致问题(脏读)¹⁴。

打开触发器设置中的并发控制(Concurrency Control)，就可以将并行运行数(并行度)指定为 1 到 100 之间的数值。把并行度设为 1，运行就会变成一次一个，从而更接近按顺序处理¹¹⁴。不过，这个开关有几个分量不轻的注意事项。

• 一旦开启就无法恢复。要关闭它，唯一的办法是删除触发器后重新创建¹。由于并发控制是不可逆的，因此建议只在操作数量较少的流程中启用(如有必要可以拆分为子流程)¹⁴。
• 会产生漏掉事件的风险。开启并发控制后，能够排队等待的运行数上限为「10 + 并行度」，在达到这个上限期间到达的触发会由连接器一侧进行重试，但如果超出上限的状态持续太久，就有可能永远无法进入运行。官方文档明确指出，对于需要确保所有触发都能进入运行的流程，应保持并发控制处于关闭状态¹。如果运行历史记录中充斥着已取消状态的记录，原因有可能就出在这项设置上¹⁰。

也就是说，「遵守顺序」与「不漏掉事件」是一对权衡关系。把并行度设为 1 进行串行化，对于流量较小、顺序很重要的处理(例如台账的连号编号)是有效的，但不应该轻易用在高峰期会涌入大量事件的处理上。如果既需要严格的顺序保证，又需要确保零遗漏，那就如第 8 章所述，进入了应该在 Power Automate 之外进行设计的领域。

7. 投入生产环境前的设计核对清单

在把新流程投入生产环境之前，至少应确认到以下这些内容。

也许有人会觉得「居然有 12 项之多」，但其中一半以上都是只需要在最初思考一次就够了的事项。反过来说，跳过这些步骤就把流程投入生产环境，之后再想「事后补上」，再加上不敢轻易触碰正在运行中的系统这种心理，往往都会在没有真正落实的情况下迎来事故。

8. Power Automate 应该做到什么程度

把错误处理不断深入探究下去，就会看到超出 Power Automate 守备范围的需求。下面列举一些划分界限的参考标准。

从判断的直觉上来说，大致可以理解为「只要还能用口头说明失败时的恢复步骤，就属于 Power Automate 的范畴；一旦不画图就无法说明清楚，就已经进入了开发领域」。尤其是需要补偿事务的业务(已经登记到 A 公司系统，但在 B 公司系统失败了，那么是否要撤销 A 那边的登记?)，其复杂程度远超流程外表看起来的样子，仅凭 Terminate 和通知是无法妥善处理的。包括与任务计划程序、PowerShell 的使用场景划分在内的判断标准，已经整理在《Power Automate 与 PowerShell・任务计划程序的使用场景划分》一文中。

9. 总结

「原本正常运行的流程不知不觉停止了」，这并非运气不好，几乎都是设计层面的问题。流程终究一定会失败。在失败的四种分类中，重试能够照顾到的只有暂时性故障；数据引起、身份验证过期、规格变更这三类，只能依靠 Try-Catch 捕获、Terminate 记录、自定义通知，以及每周的运行历史记录检查这一整套多层机制来兜底。默认的失败通知邮件是一种有条件、附带 28 天冷却期的有限机制，依赖它来运营必然会出现漏网之鱼。

而应对失败的真正核心，比起通知，其实是幂等性。只要用已处理标志与 upsert 打造出「即使重复执行也不会出问题」的形态，无论是重新提交还是触发器重复，都不再是需要害怕的事情，恢复工作也只需要「挑出失败的部分重新提交」即可完成。反过来，对于需要补偿事务或严格顺序保证的业务，不要勉强在 Power Automate 中硬做，将其切分到开发领域，从长远来看反而更划算。恰恰应该在流程开始运行的那一天，把这份核对清单完整地过一遍。

相关文章

• 用 Power Automate 实现业务自动化 ── 云端流程与桌面流程的使用场景划分及错误处理设计
• Power Automate 的定期执行流程与营业日设计
• 用 Power Automate 构建审批流程 ── 把纸质与邮件形式的审批・申请电子化
• Power Automate 的人员依赖对策 ── 所有者・连接・交接的设计
• Power Automate 与 PowerShell・任务计划程序的使用场景划分

相关咨询领域

合同会社小村软件(合同会社小村ソフト)不仅提供 Power Automate 流程错误处理・运维设计方面的评审，还能将流程本身无法满足的顺序保证・事务需求进行系统化实现。

• 技术咨询・设计评审
• Windows 应用开发
• 联系我们

参考链接

相关文章

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

相关主题

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

与本主题相关的服务

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

常见问题

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

如果 Power Automate 的流程失败了，会自动收到通知邮件吗？

只会在有限的情况下收到。单次运行失败警报邮件的机制是：当失败被判定为连接失效、节流限制等「已知有修复方法的失败」时，才会发送给所有者与共同所有者，一般性的操作失败并不会触发发送。而且一旦发送过一次，同一流程就会进入 28 天的冷却期，在此期间不会再收到额外的警报。单次运行失败警报也并非在所有流程中都默认开启。要确保能够可靠地察觉失败，建议在设计中加入从 Catch 代码块自行发送 Teams 或邮件通知的机制。

Power Automate 的标准重试会执行几次、以怎样的间隔进行？

当操作的请求超时，或以 408、429、5xx 系响应失败时，默认会以指数方式延长间隔进行自动重试。次数会因流程的性能配置文件(实质上取决于许可证层级)而不同：在 Microsoft 365 许可证等低配置文件下最多为 2 次，在 Power Automate Premium 或 Process 许可证等中・高配置文件下最多为 12 次。可以在操作的设置中将重试策略更改为「无・固定间隔・指数间隔」，次数最多可以设置到 90 次。像 400 或 404 这类由数据・配置引起的错误，不属于重试的对象。

该如何重新执行(重新提交)失败的流程运行？

从运行历史记录中打开失败的运行，选择「重新提交」，就可以用相同的触发数据重新执行一次。如果原因是流程定义有误，修正流程并保存后再重新提交，就会按照修正后的内容重新执行。从运行历史记录的列表中，一次最多可以批量重新提交 20 条记录。需要注意的是，由于重新提交会把流程从头开始重新执行，对于中途已经成功了一部分的运行，那些已经成功的处理也会再执行一次。因此需要提前做好即使重复执行结果也不会出问题的幂等设计(已处理标志、优先采用更新而非创建的写入方式)。

流程会不会在不知不觉中被禁用？

会的。触发器或操作持续失败的流程会在 14 天后被自动关闭。持续处于节流限制(超出限额)状态的流程同样会在 14 天后被关闭。此外，90 天内一次都没有被触发过的流程，如果所有者没有持有高级许可证或容量许可证，也可能会被关闭。由于放任失败不管会直接导致流程停止，因此把发现失败的机制，以及对运行历史记录(默认 28 天)的定期检查纳入日常运维之中，是非常重要的一环。

作者简介

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

Go Komura

小村软件有限公司 代表

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