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

用 Power Automate 搭建审批流程 ── 将纸质与邮件签核、申请电子化

· 更新日期: · · Power Automate, 审批流程, 云端流程, Microsoft 365, Teams, SharePoint, Forms, 业务自动化, 签核, 技术咨询

「把签核单打印出来，盖上印章，传给隔壁部门，等它转回来已经是一周之后」「把 Excel 申请表作为附件用邮件发送，审批就是回信里的一句『OK』」。我们经常收到已导入 Microsoft 365 的公司提出这类希望改善申请与审批业务的咨询。

Power Automate 提供了名为审批（Approvals）的专用机制，很多情况下，只需在 Teams 或 Outlook 中点击审批按钮的审批流程，就能在不产生额外费用的许可证范围内搭建起来。不过，「最初的流程能跑起来」和「作为业务能够放心地长期运转」之间，还有一段距离。审批记录会保存在哪里？审批人放着不管会怎样？负责人离职后，谁来修复流程？本文将梳理审批流程的基本组成部件、实务中容易踩坑的设计要点，以及应该由 Power Automate 承担到何种程度的边界划分。

1. 先说结论

  • Power Automate 的审批以 「开始并等待审批」操作 为基础。审批的类型可以从「需要所有人批准」「最先响应」「自定义响应（全部人 / 一人）」「顺序审批」这 5 种中选择。1
  • 审批人可以从 Teams、Outlook、Power Automate 门户、移动应用 中的任意一处进行响应。几乎不需要让审批人为了审批而专门学习一个新界面的用法。23
  • 申请的入口，现实中可选的方案是 Microsoft Forms / SharePoint 列表 / Teams 的审批应用 这三种。如果之后想要汇总列表和统计，以 SharePoint 列表为核心是常规做法。
  • 流程的执行历史默认只能查看 28 天，单次运行最长 30 天就会超时。不要把审批的证据依赖于执行历史，而应从一开始就设计成把结果写回 SharePoint 列表等位置。45
  • 流程所有者离职、调岗是审批流程运维中最大的风险。应在流程开始运行的当天就完成 共同所有者的设置和连接的处理方式。6
  • 如果想把条件分支繁多的多级审批、代理决裁，或审计要求严格的签核规程原样实现，Power Automate 就会变得难以维护。这种情况属于工作流系统或受托开发的范畴。

2. 纸质与邮件签核究竟存在什么问题

纸质签核单和邮件附带 Excel 的审批之所以令人头疼，与其说是花费的功夫本身，不如说是「看不见状态」。在接受咨询时，共通的问题基本可以归纳为以下三点。

  • 不知道现在卡在哪里。签核单放在谁的桌上、邮件被埋没在哪个收件箱里，申请人本人根本看不到。催促只能靠口头或电话，被催促的一方心情也不会好。
  • 记录分散。审批的凭证分散在纸质文件柜和个人邮箱里。要在审计或事后查询时调查「那份申请到底是谁、什么时候批准的」，就得去翻别人的邮箱。一旦负责人离职，邮箱也会跟着一起消失。
  • 退回情况难以追溯。如果驳回或修改要求是通过口头或邮件进行的，就会分不清是针对哪一版申请表提出的意见。重新发送修改版之后，又要从头开始传阅一遍。

这些问题，通过「把申请的状态和记录汇集到一处」基本就能解决。而如果已经导入了 Microsoft 365，存放的地方（SharePoint）、通知渠道（Teams/Outlook）和自动化手段（Power Automate）其实已经在手边了。

3. Power Automate 审批的基本组成部件

「开始并等待审批」操作

审批流程的核心，是审批（Approvals）连接器的 「开始并等待审批（Start and wait for an approval）」 操作。指定审批请求的标题、详情与审批人之后，流程会在此处暂停，等待审批人响应之后才会进入下一个操作。1

审批的类型共有 5 种。1

审批类型 行为
批准/拒绝 - 需要所有人批准 所有人都批准，或有一人拒绝时即完成
批准/拒绝 - 最先响应 有一人批准或拒绝时即完成
自定义响应 - 等待所有响应 自行定义响应选项，全员响应后完成
自定义响应 - 等待一个响应 自行定义响应选项，一人响应后完成
顺序审批 按指定顺序依次向每个人请求批准

使用自定义响应，就可以不局限于「批准」「驳回」两个选项，而是定义出「批准」「退回」「保留」这样的选项。这将成为后文提到的退回循环的组成部件。

另外，要使用审批功能，需要用到 Microsoft Dataverse 数据库。审批请求和响应的记录会保存在 Dataverse 中，在默认环境下，这会在首次创建审批流程时自动准备好，因此通常不需要特别在意就能开始使用。审批连接器属于标准连接器，因此只要拥有可以使用标准连接器的许可证（如 Office 365 等），就能创建审批流程。1

审批人从哪里响应

审批人会通过邮件和 Power Automate 移动应用收到审批请求。3 在 Outlook 中，会收到经过排版的审批邮件，可以直接从中响应。7 发送给个人用户的审批还会在 Teams 中收到通知，可以从 Teams 的聊天或审批应用中批准、驳回或输入评论。2 不存在「为了审批还要专门登录某个网站」这道门槛，正是审批流程能够真正落地的最大推动力。

有一点需要注意。如果把审批对象设为 Microsoft 365 组，Teams 通知就不会发送。只有发送给个人用户的审批，才会收到 Teams 通知。8

流程整体结构

以采购申请为例，整体流程大致如下。

Teams / Outlook / 移动端批准驳回/退回超时通过触发条件仅在「重新申请」时启动申请人输入提交 Forms / 登记到 SharePoint 列表云端流程启动新响应・新增项目触发器将申请内容记录到 SharePoint 列表状态：等待审批开始并等待审批向审批人发送请求响应将列表状态更新为「已批准」把审批人・日期时间・评论记录到列中将状态更新为「已退回」向申请人通知原因催办通知 / 升级上报向申请人通知结果申请人修改后重新申请

关键在于，在审批操作的前后都插入了「记录」这一步骤。原因会在第 5 章说明。

4. 如何设计申请的入口

审批流程好不好用，与其说是取决于审批一方，不如说是取决于 申请一方的输入入口。现实中可选的方案有三种。

视角 Microsoft Forms SharePoint 列表 Teams 的审批应用
输入的便捷性 表单形式最简单，也便于从手机输入 列表的输入表单。列数一多会略显繁琐 直接从 Teams 聊天・应用发起，甚至无需创建流程9
申请的列表・状态管理 较弱（有响应列表，但没有状态列） 较强，列・视图・状态管理正是它的本行 仅有应用内的发送/接收列表
与流程的联动 用触发器「提交新响应时」加操作「获取响应详细信息」这一组合来联动10 通过项目创建・更新触发器联动，是审批教程中的常规配置3 通过模板功能实现定型化，流程侧的灵活性较低
附件 可通过文件上传问题实现 自然地结合项目附件・文档库使用 审批请求可以附加文件
适用情况 申请项目少，优先考虑输入的便捷性；替换现有 Excel 申请表的第一步 想保留为申请台账、件数多、之后想汇总统计 不到需要定型化程度的临时审批（例如日常的上级确认）

判断的大致标准如下。

  • 如果 只是想把临时性的审批电子化，不必创建流程，用 Teams 的审批应用就足够了。审批应用是一项可以直接从聊天中当场发送审批请求的功能，虽然运行在 Power Automate 的底层平台上，但不需要创建流程。9
  • 如果是 替换申请表，以 Forms 作为入口，用流程接收响应并转入审批，是最快捷的方式。系统还提供了可以把 Forms 的响应内容嵌入审批请求的模板。11
  • 如果 想作为申请台账来管理，就以 SharePoint 列表为核心。即使以 Forms 作为入口，只要在流程的最开始就把响应转录到列表中，状态列（等待审批/已批准/已退回）和视图就能让任何人都看清「现在卡在哪里」。开头提到的纸质与邮件签核的问题，答案实质上就在这里。

如果想从小规模开始，「用 Forms 接收、记录到 SharePoint 列表，审批结果也写回列表」这种结构，能同时兼顾输入的便捷性与台账管理，比较容易操作。

5. 在实务中真正有效的设计要点

审批记录留在哪里 ── 不要依赖执行历史

这是最重要的设计判断。流程的执行历史，默认只会显示 28 天。4 如果流程被纳入解决方案（Solution），可以把执行历史的元数据保留在 Dataverse 中，但这一侧的默认保留期同样是 28 天，是一种由管理员调整保留期限的机制。12

也就是说，靠事后翻查执行历史来确认「谁在什么时候批准的」这种运营方式，一个月就会破功。审批请求与响应的记录本身会保存在 Dataverse 中13，但每次应对审计或日常查询都要去查看 Dataverse 的表并不现实，而且审批历史会消耗环境的存储空间，有时也会因为容量原因而被删除。14

在实务中，务必加入 紧跟在审批操作之后、把结果・审批人・响应日期时间・评论写回 SharePoint 列表列中 的这一步骤。「开始并等待审批」操作会把响应、审批人、评论作为输出返回13，只需将其原样记录到列中即可。这样一来，申请与审批记录就会汇集在同一份列表的同一行上，保留期限则完全取决于列表的运营方式，可以保留数年之久。

有一点需要注意。在「需要所有人批准」或自定义响应（全部人）这类多个审批人的类型中，响应（Responses）会以对应人数的数组形式返回。3 如果把它依次覆盖写入一组列中，最终就只会残留最后一次响应，因此对于多个审批人的记录，应当为每一条响应向历史用列表追加一行，或者把所有人的响应整理成一段文本之后再记录到列中。

超时与提醒 ── 无法创建「没有期限的审批」

云端流程单次运行最长为 30 天。这 30 天中包含等待审批这类挂起中的步骤，一旦超过 30 天，挂起中的步骤就会超时。5 只要审批人放着不管，流程就会默默地以失败告终。如果在不了解这一点的情况下就开始运营，就会发生「明明提交了申请却什么都没发生」这种最容易破坏信任的事故。

对策分为两个阶段。

  1. 给审批操作设置明确的超时时间。在操作的设置中以 ISO 8601 格式（例如 P3D 表示 3 天）指定超时，并在「配置运行后条件」中准备好「超时时」这一分支。15 这里需要注意的是，一旦超时，原本的等待审批就已经结束。此后即使审批人再响应，也不会流入这次运行的后续步骤（例如结果写回等）。也就是说，超时分支并不是「一边继续等待一边催办」的地方，而是「先中断一次、再采取下一步行动」的地方。如果要催办，就应该在超时分支中发送通知的同时 重新发起新的审批请求。如果只是「3 天催办一次，7 天上报给上级」这种程度的层级，最简单也最可靠的做法，是把带超时设置的审批操作串联排列 2～3 段（第 2 段带催办功能重新发起请求，第 3 段发送给上级负责人）。也可以用 Do Until 循环把「超时 → 催办 → 重新请求」包裹起来，但 Do Until 本身另有循环上限（默认 60 次・1 小时），如果在其中放入等待审批这类耗时较长的操作，除非用「更改限制」明确延长循环的超时时间，否则第一轮结束后第二轮及以后就不会开始。516
  2. 对于可能超过 30 天的审批，把流程拆分为两个。官方文档中介绍了这样一种配置：用「创建审批(v2)」操作只发送审批请求，第一个流程就此结束，对响应的后续处理交给另一个流程完成。由于审批记录保存在 Dataverse 中，即使原本的流程已经运行结束，响应仍然可以被处理。如果想在不打断等待的前提下灵活地组织催办，这种两段式结构也更容易实现。17 另外，第二个流程的启动方式还有设计空间，如果采用直接用 Dataverse 连接器的触发器捕捉审批表变化的配置，需要注意 Dataverse 连接器属于高级许可证的范畴（审批连接器本身的操作仍在标准范围内1）。18

对于中小企业的签核而言，现实的做法是先确定「3 天催办一次，7 天上报给上级」这类内部规则，然后用重新请求循环或两段式结构来实现它。

不在时的重新分配

审批人长期不在的情况一定会发生。收到审批请求的本人，可以从 Power Automate 门户的审批列表中把请求 重新分配（Reassign） 给其他人。而发起请求的一方要重新调整，则需要走取消请求、变更审批人、再次执行这一套流程。7 需要注意的是，在本文这种自动启动的流程中，这会变成 流程所有者一方的工作，而不是申请人的工作。因为审批请求是从流程连接所使用的账户发出的，变更审批人也需要流程的编辑权限。「审批人休假时由谁来修复流程」这个问题，需要和下一章共同所有者的内容放在一起提前决定好。

不过，重新分配的前提是「收到请求的本人能够进行操作」，因此对突发性的休假等情况无能为力。作为长期性的准备措施，比起把审批人固定为单独一人，用分号分隔指定多个人、采用「最先响应」类型，或者设计为发送给一个组，会更安全。7 由于发送给组存在 Teams 通知不会发送的限制8，如果重视通知的可靠性，应选择指定多个人的方式。

驳回时的退回循环

在纸质签核中最难追溯的「退回 → 修改 → 重新申请」，只要设计中带有状态列，就能顺畅地表达出来。基本形式如下。

  • 用自定义响应定义「批准」「退回」1
  • 退回时，把列表的状态列设为「已退回」，将审批人的评论记录到列中并通知申请人
  • 申请人修改列表中的项目，并将状态改为「重新申请」（或从 Forms 重新提交）
  • 以项目更新为触发器，流程再次运行，转入审批

在这种结构中，有一点需要注意：流程自身的写回操作，会导致流程重新启动。如果保留「创建或修改项目时」这个触发器不变，那么流程把状态列更新为「等待审批」或「已批准」的瞬间，这次更新本身就会满足触发条件，从而引发重复的审批请求或无限循环。云端流程可以触发自身，Power Automate 在保存时也会对可能出现无限循环发出警告。19 对策不是在后段的条件分支中把这种情况丢弃，而是要 用触发条件（trigger conditions）在触发器一侧写明「仅当状态列为『重新申请』（或新建）时才启动」。不满足触发条件的更新不会引发流程执行本身，因此也不会消耗执行次数。20

由于修改历史会保留在列表的版本历史中，「意见针对的是哪一版」这类问题混淆的情况也随之解决。也可以在流程内组建 Do Until 循环，在一次执行内完成退回的往返，但由于 30 天的执行期限限制也会把退回往返的时间算在内，因此 每次退回都结束执行，重新申请时再开始新的执行 这种设计更为安全。

6. 运维与治理 ── 不要让流程变成「创建者个人的东西」

审批流程会深入业务的核心环节，一旦变得依赖特定个人，影响就会很大。至少要在正式运行的第一天完成以下两点。

  • 设置共同所有者。流程的所有者可以查看执行历史、编辑・停止流程，甚至更新连接的凭据信息。如果一直只有创建者一个人，一旦这个人离职或调岗，流程就会变成谁都无法修复的状态。应提前把信息系统负责人或候补接任者加为共同所有者。另外，也有一种功能可以把 SharePoint 列表本身设为共同所有者，让「拥有列表编辑权限的人 = 能够编辑流程的人」保持一致6，但如果像本文这样，把它用在 所有申请人都要写入的入口列表 上，就等于把流程的编辑权限交给了全体申请人。审批流程中请不要使用这种做法，共同所有者应限定为承担运维工作的个人负责人，或管理员专用的组。
  • 理解连接的处理方式。流程中使用的连接（对 SharePoint 或 Outlook 的身份验证）与创建它的用户绑定，共享的连接也只能在那一个流程内使用。此外，共同所有者无法变更其他所有者创建的连接的凭据信息。6 「审批结果的通知邮件一直从已离职人员的账户发出」「账户被禁用的同时流程也停止运行」这类事故，正是由此而来。通知和写入所使用的账户该如何处理，是应该在创建流程之前就决定好的议题。

另外，即使让其他部门也使用这个流程，也不需要把流程共享给申请人。在本文的结构中，只要能够在入口（Forms 或 SharePoint 列表）中输入内容，流程就会自动启动。共享的对象应仅限于参与编辑与运维的人员，共同所有者应控制在必要的最小范围内，这是基本原则。21

关于许可证、环境隔离、DLP 策略这类 Power Automate 整体的治理内容，我们在另一篇文章「用 Power Automate 实现业务自动化 ── 云端流程与桌面流程的分工，以及错误处理设计」中做了梳理。由于审批流程也是云端流程的一种，同样的思路可以直接套用。

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

Power Automate 的审批功能虽然强大，但它并不是用来原样实现签核规程的工具。下面列出划分边界的大致标准。

情况 判断
审批人为 1～3 级，路径由金额等简单条件决定 Power Automate 足以应对
审批路径根据组织层级、金额、案件类型的组合动态变化 条件分支容易爆炸式增长，应考虑工作流系统或受托开发
需求中包含代理决裁、职务代理，或需跟随组织改编而调整 仅靠 Power Automate 独立实现会相当繁重，属于专用系统的范畴
审计要求需要长期保存审批证据、防篡改、并支持全面检索 写回 SharePoint 是否足够取决于具体要求；要求严格时应考虑工作流系统/文档管理系统
必须还原申请表的版式（输出带盖章栏的表单） 需要在流程之外搭建表单生成机制，会涉及开发工作

凭直觉判断的话，大致可以这样看：「一旦把流程的分支画在纸上、一张 A4 纸都放不下的时候，就已经开始超出 Power Automate 的守备范围了」。与其硬把流程养大，不如只把审批路径的判定逻辑抽离到外部（Dataverse 的表或另一个系统），或者干脆转移到专用系统，往往结果上反而更省钱。

此外，审批流程的电子化，往往也会成为重新审视与公司外部之间纸质、传真往来的一个契机。一旦公司内部的签核实现了电子化，接下来传真接单或发票往来就会成为候选对象。这方面的内容，我们在「把传真订单迁移到 Web ── 双轨运行期的设计与分阶段迁移实务」和「什么是 EDI？如何让企业间的订购业务更轻松 ── 从传真、邮件、手动录入迈向数据对接」中有所介绍。

8. 总结

纸质与邮件签核真正的问题，并不在于花费的功夫，而在于「看不见状态・记录分散・退回情况难以追溯」。Power Automate 的审批流程，用「把申请与审批记录汇集到 SharePoint 列表，审批操作在 Teams/Outlook 中完成」的方式，解决了这三个问题。很多情况下无需额外的系统投资就能开始，这对已经导入 Microsoft 365 的公司来说也是一大优势。

另一方面，如果不了解执行历史 28 天、执行期限 30 天这些限制就动手搭建，就会做出「凭证会消失」「申请会默默失败」的审批流程。结果写回、超时分支、多个审批人、共同所有者——只要从一开始就把这 4 点纳入设计，审批流程就能长期放心地运转下去。而当你想把签核规程的复杂性原样实现出来时，就是该考虑专用系统或受托开发的时机了。

相关文章

相关咨询领域

合同会社小村软件(KomuraSoft LLC)承接从利用 Microsoft 365 实现业务流程电子化的咨询，到 Power Automate 无法覆盖的审批・报表需求系统化在内的相关工作。

参考资料

  1. Microsoft Learn, Get started with approvals。关于「开始并等待审批」操作、审批的 5 种类型(全员批准/最先响应/自定义响应/顺序审批)、作为前提条件的 Dataverse 数据库,以及审批连接器是标准连接器、可用 Office 365 等许可证创建的说明。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  2. Microsoft Learn, Respond to an approval from a chat or channel。关于可以从 Teams 的聊天・频道・审批应用中响应审批请求的说明。 ↩ ↩2

  3. Microsoft Learn, Create an approval flow that requires everyone to approve。关于以 SharePoint 列表项目的创建・更新为触发器的审批流程配置、审批请求会通过邮件和 Power Automate 移动应用送达,以及在「需要所有人批准」中一人拒绝即导致整体被拒绝的说明。 ↩ ↩2 ↩3 ↩4

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

  5. Microsoft Learn, Limits of automated, scheduled, and instant flows。关于云端流程的执行期限最长为 30 天,以及等待审批这类挂起中的步骤同样会在经过 30 天后超时的说明。 ↩ ↩2 ↩3

  6. Microsoft Learn, Share a cloud flow。关于共同所有者能够做的事情(查看执行历史、编辑流程、更新连接凭据、添加所有者)、共享的连接只能在该流程内使用、无法变更其他所有者创建的连接凭据,以及可以将 SharePoint 列表设为共同所有者的说明。 ↩ ↩2 ↩3

  7. Microsoft Learn, How to - Top scenarios with approval flows。关于收到审批请求的本人可以进行重新分配(Reassign)、发起请求的一方需取消请求并变更审批人、用分号分隔指定多个审批人,以及 Outlook 中审批邮件显示方式的说明。 ↩ ↩2 ↩3

  8. Microsoft Learn, Request approvals from Microsoft 365 groups。关于发送给组的审批的运作方式,以及 Teams 通知仅针对发送给个人用户的审批、组审批不会发送的说明。 ↩ ↩2

  9. Microsoft Learn, Approvals in Microsoft Teams。关于可以从 Teams 的审批应用直接创建审批请求而无需创建流程,以及其运行在 Power Automate 底层平台上的说明。 ↩ ↩2

  10. Microsoft Learn, Overview of flows with Microsoft Forms。关于 Forms 的触发器「提交新响应时」与操作「获取响应详细信息」的说明。 ↩

  11. Microsoft Learn, Common ways to use a form in a flow。关于把 Forms 的响应内容嵌入审批请求的模板,以及把响应转录到 Excel/列表的说明。 ↩

  12. Microsoft Learn, Manage cloud flow run history in Dataverse。关于纳入解决方案的流程的执行历史(FlowRun)会保存在 Dataverse 中、默认保留期为 28 天,以及管理员可以变更保留期限(TTL)的说明。 ↩

  13. Microsoft Learn, Differences between flow approval actions。关于审批操作会在 Dataverse 中创建记录、「开始并等待审批」会将响应・审批人・评论作为输出返回,以及「创建审批」与「等待审批」之间区别的说明。 ↩ ↩2

  14. Microsoft Learn, Free up storage space。关于流程的审批历史会消耗 Dataverse 的存储空间、可以通过删除来释放存储空间的说明。 ↩

  15. Microsoft Learn, Cloud flow error code reference。关于对审批・等待类操作设置明确超时(ISO 8601 格式)、「配置运行后条件」中的「超时时」分支,以及应对 30 天执行期限限制的说明。 ↩

  16. Microsoft Learn, Limits and configuration reference for Azure Logic Apps。关于 Until 循环默认上限为迭代 60 次・超时 1 小时(PT1H)、超时会按每一轮进行评估,超过后正在执行的一轮不会中止,但下一轮不会开始,以及可以通过「更改限制」变更该数值的说明。Power Automate 云端流程循环的默认迭代次数 60 次,在Limits of automated, scheduled, and instant flows中同样有记载。 ↩

  17. Microsoft Learn, Create and test an approval workflow with Power Automate。关于对可能超过 30 天的审批使用「创建审批(v2)」、把发送审批请求与处理响应拆分为两个流程的配置,以及取消审批请求的说明。 ↩

  18. Microsoft Learn, List of all Premium tier connectors。关于 Microsoft Dataverse 连接器被归类为高级层连接器的说明。 ↩

  19. Microsoft Learn, Avoid anti-patterns。关于云端流程可能触发自身而导致无限循环、保存时会显示警告,以及可通过触发条件或 Terminate 操作来规避的说明。 ↩

  20. Microsoft Learn, Customize your triggers with conditions。关于触发条件可以让不满足条件的事件不产生执行本身,而在后段条件分支中丢弃的方式仍会消耗执行次数和 API 请求的说明。 ↩

  21. Microsoft Learn, Understand flow ownership and access。关于共同所有者应仅在必要时添加、共享原则上应以仅执行权限进行的说明。 ↩

相关文章

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

相关主题

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

与本主题相关的服务

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

常见问题

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

仅凭 Microsoft 365 许可证就能创建 Power Automate 的审批流程吗？
可以。审批（Approvals）连接器属于标准连接器，因此只要拥有可以使用标准连接器的许可证（如 Office 365 等），就能创建审批流程。不过，审批数据的存储位置需要用到 Microsoft Dataverse 数据库，在默认环境中，这会在首次创建审批流程时自动准备好。与 SharePoint 列表、Forms、Teams、Outlook 的组合，同样可以在标准连接器的范围内完成配置。
如果审批人一直不响应会怎样？
云端流程单次运行最长为 30 天，等待审批这类挂起中的步骤，一旦超过 30 天也会超时。因此无法创建「不设期限的审批」。在实务中，需要给审批操作设置明确的超时时间，并在「配置运行后条件」中准备「超时时」这一分支。一旦超时，原本的等待审批就会结束，之后即使审批人再响应，也不会流入后续步骤，因此这个分支应当设计为发送催办通知的同时重新发起新的审批请求（可根据重试次数逐级上报给更高层级的负责人）。如果需要等待超过 30 天，则应拆分为两个流程：一个使用「创建审批(v2)」操作发送请求，另一个负责处理响应。
审批记录会保存在哪里？可以用于审计吗？
审批请求与响应会作为记录保存在 Microsoft Dataverse 中，而流程自身的执行历史默认只会显示 28 天。把审计或事后查询依赖于执行历史是很危险的。实务中，建议在流程的最后一步，把审批结果、审批人、审批日期时间、评论写回 SharePoint 列表的列中，让申请数据与审批记录可以在同一个地方汇总查看。
审批人不在或已离职时应该怎么办？
收到审批请求的本人，可以从 Power Automate 的审批列表中将请求重新分配（Reassign）给其他人。发起请求的一方无法直接重新分配，但可以取消请求、变更流程的审批人后重新执行。为应对长期不在的情况，与其把审批人固定为单独一人，不如设计成发送给多人或一个组，这样更不容易卡住。此外，为应对流程所有者本人离职的情况，从一开始就设置好共同所有者也同样重要。

作者简介

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

Go Komura

小村软件有限公司 代表

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

联系我们
返回博客列表