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

Power Automate 的人员依赖对策 ── 让创建者离职后流程也不会停止

· · Power Automate, 人员依赖, 交接, 运维保守, 治理, Microsoft 365, 业务自动化, 技术咨询

「公司里有位精通 Power Automate 的员工，把公司内各处的业务都自动化了。可是这个人下个月就要离职，没有人知道究竟哪些流程在做什么」── 最近这类咨询明显增多。也有已经离职之后，才在「上个月开始订单通知邮件就收不到了，却没有人能修」这个阶段才找上门来的情况。

此前我们在《接手了没有源代码也没有文档的系统 ── 在不中断运行的前提下开展运维保守的实务步骤》一文中，讨论过创建者已不在场的系统该如何交接。Power Automate 的流程由于可以无代码搭建，这种情况反而更容易发生，而且它不像可执行文件那样能保证「一直留在原地」。这是因为流程与创建者的账户及连接(connection)紧密绑定，账户一旦被禁用或删除，损坏的方式就会发生变化。本文将一边通过 Microsoft 的官方文档确认所有者消失后流程会发生什么这一事实关系，一边按中小企业的实务顺序，整理离职前应该做的事、离职后能够做的事，以及从源头上防止人员依赖所需的盘点与执行账户设计。

1. 先说结论

  • 流程的创建者即为所有者，执行时使用的连接(对 SharePoint、Outlook 等的身份验证)绑定在创建者本人的账户上。共享的连接只能在该流程内部使用，即使是共同所有者，也无法更改他人创建的连接凭据。1
  • 所有者离职后，只要还留有共同所有者，流程本身就会继续运行。不过使用离职者连接的操作会开始失败，因此需要替换连接。12
  • 没有任何有效所有者的流程会变成「孤立流程(orphaned flow)」。管理员可以在 Power Platform 管理中心的环境页面(资源→流程)中找到它们，并通过「共享」添加新的所有者。也可以用 PowerShell(Get-AdminFlow、Set-AdminFlowOwnerRole)进行批量处理。2
  • 离职前的做法分两步走：「添加共同所有者」和「变更所有者」。所有者的替换(在职期间的交接)只能在解决方案对应流程上进行，非解决方案流程需要先加入解决方案，或通过导出/导入的方式重新制作。34
  • 通知邮件会持续以本人名义发送的问题，只要改用共享邮箱发送(「从共享邮箱发送电子邮件(V2)」操作)，就不会受离职影响。Microsoft 的指南也建议，定型化的通知应使用共享发件人而非个人名义。56
  • 多人共用同一用户账户的服务账户，官方最佳实践并不推荐使用，对于关键业务流程，官方推荐的做法是由服务主体(service principal)持有。不过由于中小企业在设置与许可证方面存在门槛，本文第 5 章将整理更贴合实际的使用区分方式。478
  • 对策的第一步不是技术，而是盘点。先用管理中心和 Get-AdminFlow 列出公司内到底有哪些流程，从建立一份最基本的流程台账(名称・目的・所有者・连接・受影响业务)开始。9

2. 流程的人员依赖是如何产生的

Power Automate 的人员依赖，并非出于恶意或懈怠，而是善意不断累积的结果。典型的经过是这样的。

  1. 熟悉业务的现场人员，为了让自己的工作更轻松而制作了流程。规模很小，大概是「把 Forms 的回答转录到 Excel」这种程度。
  2. 因为方便，周围的人也开始跟进。「那个通知也发给我们科一份」「订购单能不能也帮忙保存一下?」，需求不断汇集，流程随之增加、成长。
  3. 不知不觉间就渗透进了业务的核心。诸如接单的初次联络、发票的保存、审批的传阅这类「一旦停止业务就会受阻」的处理，开始由这个人的个人账户下的流程来运行。
  4. 在没有人了解其内部构造的情况下稳定运行。因为没有理由去触碰正常运作的东西，所以既不会有交接，也不会有文档。「因为在正常运行所以不能碰」，就这样原封不动地变成了「谁都碰不了」。

到这里为止的结构，和开发人员离职后留下没有源码也没有文档的系统是一样的。不过 Power Automate 相比传统遗留系统，有两点更棘手。第一，制作的位置是个人的「我的流程(My Flows)」，除了本人之外谁都看不到它的存在。与会在服务器上留下可执行文件的系统不同，流程如果不进行盘点，连清单上都不会出现。第二，流程的执行依赖创建者的账户与连接。在离职处理中把账户禁用・删除的那一刻，影响就会显现出来。下一章将准确确认这一行为。

先解释一个术语 ── 什么是「解决方案对应流程」

由于后面的章节会反复出现这个词，这里先说明清楚。解决方案(solution)是用来把流程及其组成部件(连接引用、Dataverse 表、应用等)打包搬运的容器。使用它需要一个带有 Dataverse 的环境，而在解决方案内制作(或事后加入解决方案)的流程，被称为解决方案对应流程(solution-aware flow)。10

在交接的语境下起作用的，是下面这些差异。

  普通流程(非解决方案) 解决方案对应流程
变更所有者 无法当场变更。因为所有者是流程识别信息的一部分3 可以。所有者・共同所有者・管理员可以从详情页面变更3
连接的持有方式 直接引用连接本身 可以用连接引用这种易于替换的形式持有10
环境间的迁移 需通过导出/导入重新制作 可以整体迁移10
前提条件 无 需要带有 Dataverse 的环境10

「为什么解决方案对应流程可以变更所有者」这个疑问，答案就在这张表的第一行。普通流程的所有者被嵌入到了流程自身的识别信息之中，因此事后无法替换。而解决方案对应流程把这种绑定关系切离开来，因此可以替换所有者。3 也就是说，对人员依赖最有效的对策，就是从一开始就把重要的流程放入解决方案中。是否引入解决方案的判断标准，将在第 7 章讨论。

3. 账户消失后流程会怎样

流程本身不会消失，但会变成「孤立流程」

首先作为前提，即使把离职者的账户从 Microsoft Entra ID 中删除，该人员创建的流程也不会被自动删除。流程与连接被归类为「需要管理员手动确认・删除的对象」，不会擅自消失；但另一方面，运行历史会随账户删除而被自动删除。如果依赖过去的运行记录作为证据留存，需要特别留意这一点。11

即便流程还留在原地，一个没有任何有效所有者的流程，也会进入被称为孤立流程(orphaned flow)的状态。Microsoft 的支持文档把孤立流程定义为「没有有效所有者的流程」，并明确指出，如果使用的是绑定在已离职用户账户上的连接，流程就有可能失败。2

连接绑定在本人的账户上

这是最要害的地方。流程各操作所使用的连接(对 SharePoint、Outlook、Teams 等的身份验证)，是靠创建者本人的凭据来运行的。关于共享流程的创建者离职时的情况，官方 FAQ 做了如下整理。1

  • 只要还留有共同所有者等有效所有者，流程本身就会继续运行
  • 但使用离职者名义连接的操作有可能失败，因此需要更新连接凭据(实际做法是在流程编辑界面中，把各操作的连接替换为另一个账户的连接)

此外，共享的连接只能在该流程内部使用，即便是共同所有者，也无法更改其他所有者创建的连接凭据。1 也就是说，「已经添加了共同所有者所以没问题」只对了一半，只有把离职者的连接从流程中彻底清除(在各个操作中替换为自己的连接并保存)之后，交接才算真正完成。

被许可证连带波及 ── 14 天后被关闭的情况

使用高级连接器等功能的流程，是靠所有者的许可证运行的。根据官方许可证 FAQ，如果所有者因离职等原因失去了许可证的支撑，高级流程会被降级为性能下降的状态，并在通知全体所有者后，如果没有应对措施，将在 14 天后被关闭。4 这是一种「隐约感觉变慢了」两周之后就会停止的、带有时限的行为。如果流程只使用标准连接器，这个问题就不太容易发生，但哪些流程使用了高级功能，是应该通过盘点来掌握的信息(标准/高级的边界，我们在《Power Automate 的许可证与标准/高级连接器的边界》中做了整理)。

邮件持续以本人名义发送的问题

容易被忽视的是通知的「名义」。由于「发送电子邮件(V2)」操作是从所连接用户的邮箱发出的，只要流程还在运行，通知邮件就会持续以创建者个人的名义发送。在职期间顶多是「为什么每天早上都是那个人发来的邮件？」这种程度的疑惑，但离职后随着账户被禁用，发送本身也会失败。反过来，如果共同所有者只把连接替换成自己的，这次就会变成全部通知都以那个人的名义发送。

Microsoft 的指南建议，避免以个人名义发送已经定型化的业务通知，而应使用共享发件人。如果是 Outlook，可以用「从共享邮箱发送电子邮件(V2)」操作，从共享邮箱(例如 noreply-flow@example.co.jp)发送，发送记录也会保留在共享邮箱的已发送文件夹中(发送前需要拥有该邮箱的访问权限)。如果是发往 Teams 的通知，「以流程机器人身份发帖」系列的操作可以起到同样的作用。同时加上一句「本邮件由 Power Automate 自动发送，如有问题请联系 ◯◯」的署名，即使负责人更换，接收方也不会感到困惑。56

4. 离职前应做的事、离职后能做的事

离职前 ── 只要有两周时间就来得及

一旦确定离职或调动，就按以下 6 个步骤推进。整体流程如下图所示(编号与下方各步骤一一对应)。

是否确定离职/调动① 列出并分类所有流程② 添加共同所有者是否为解决方案对应流程?③ 从详情页面变更所有者③ 先加入解决方案再变更或重新制作④ 替换各操作的连接⑤ 将通知发送源改为共享邮箱⑥ 测试离职者账户被禁用后是否仍能运行
  1. 将流程列出并分类。和本人一起打开「我的流程」画面，把它们分为「用于业务的」「个人效率工具」「实验残留」三类。此时顺便做出第 6 章流程台账的初版，是最有效率的做法。
  2. 添加共同所有者。把接任者与信息系统负责人(如果没有，则是拥有管理员权限的人)添加为流程的所有者。共同所有者能够查看运行历史、编辑・停止・删除流程，甚至添加所有者。1 需要注意的是，添加共同所有者只是最低限度的应急措施，官方推荐日常的共享应尽量停留在「仅限运行(run-only)」的范围内。7
  3. 变更所有者。如果是解决方案对应流程，可以从流程的详情画面把所有者变更为接任者(或服务账户)。变更后，原所有者与新所有者都会成为共同所有者，按计划执行・自动执行的流程会开始使用新所有者的许可证运行(生效最长需要 7 天；打开流程并保存则会立即生效)。3 非解决方案流程如第 2 章所述无法变更所有者，如果有可用的 Dataverse 环境，就先加入解决方案再变更；如果没有，就用导出/导入或「另存为」的方式，在新所有者名下重新制作。34
  4. 替换连接。如上一章所述，跳过这一步交接就不算完成。在流程的编辑画面中，把各操作的连接切换为新账户的连接并保存。把离职者从所有者中移除时，同样需要更新使用了该人凭据的连接。1
  5. 迁移通知的发件人。使用个人名义「发送电子邮件(V2)」的流程，按第 3 章所述切换为从共享邮箱发送。如果不预先修正这一点，交接之后就会变成全部通知都以接任者的名义发出。56
  6. 进行测试。如果条件允许，在离职者账户被禁用的状态下(或者利用本人休假等不会操作的时段)完整运行一轮，确认在与离职后相同的条件下能否正常运作。

离职后 ── 管理员能做的事

即便已经离职、所有者已不存在，也仍有办法可循。

  • 在管理中心找到孤立流程。画面的操作路径如下。2

    1. 登录 Power Platform 管理中心
    2. 从左侧菜单的「环境」(Environments)中选择目标环境
    3. 在环境详情页面打开「资源」(Resources)→「流程」(Flows)
    4. 查看列表中的「所有者」(Owners)列。这一列为空的流程就是孤立流程

    也就是说，「寻找所有者列为空的行」是这个画面唯一的目的。在流程数量较多的环境中，按这一列排序，或者用后文介绍的 PowerShell 机械化地筛查出来，会更加可靠。

  • 通过「共享」添加新的所有者。从列表中选择目标流程，用「共享」(Share)添加新所有者的账户并保存。2 另外，如果管理员想要修改流程内容，前提同样是先把自己添加为所有者或共同所有者。3
  • 数量较多时用 PowerShell 批量处理。用管理模块(Microsoft.PowerApps.Administration.PowerShell)的 Get-AdminFlow -CreatedBy <离职者的对象 ID> 列出离职者创建的流程，再用 Set-AdminFlowOwnerRole -RoleName CanEdit 授予共同所有者权限。当前权限可以用 Get-AdminFlowOwnerRole 确认。2
  • 重新创建连接。交接所有者之后，把离职者名义的连接替换为新账户的连接。如果离职者的账户已经被删除，原本的连接就无法恢复，因此需要新建连接并重新分配给各个操作。1

补充说明一点，仅就审批流程而言，还存在「等待审批的请求一直分配给离职者」这另一种卡壳方式。关于审批者一侧的重新分配与升级设计，我们在《用 Power Automate 搭建审批流程》的第 5～6 章中有过讨论，请参考该文。

5. 执行账户的设计 ── 个人账户・服务账户・服务主体

为了不再重复交接引发的混乱，从根本上说，应当在一开始就决定好「业务流程要以谁的名义运行」。

先只对比较表中出现的「Process 许可证」做一下说明。Power Automate 的许可证大致分为两类：用户许可证分配给「人」，而Process 许可证则是分配给「流程(或执行机器)」本身的容量许可证。12 一旦分配给云端流程，无论拥有并执行该流程的用户持有什么许可证，都可以使用高级连接器与自定义连接器(分配的前提条件是该流程已加入解决方案)。12

服务主体不是人，所以无法持有用户许可证。因此就变成了「如果要让使用高级功能的流程由服务主体持有，就需要给流程本身配上 Process 许可证」。反过来，只使用标准连接器的流程则不需要。8 标准/高级本身的边界，我们在《Power Automate 的许可证与标准/高级连接器的边界》中做了整理。

在此基础上，比较一下各个选项。

观点 个人账户 服务账户(共用的用户账户) 服务主体
离职・调动的影响 直接受冲击(连接・许可证・名义全部受影响) 不受影响。但创建者离职时需要变更密码 不受影响(不绑定于个人)7
引入的成本 无，创建后即可直接使用 仅需创建账户与分配许可证 需要 Entra ID 应用注册 + 创建应用程序用户。需要 IT 一侧的专业知识8
密码・MFA 由本人管理 共享是其前提，这也是弱点所在。难以追踪谁做了变更，密码管理本身就是风险。设置 MFA 后，还会出现「认证手段由谁持有」这一运维问题4 无需共享密码。但需要管理机密信息/证书
许可证 以本人的许可证运行 需要一份用户许可证。多人共用凭据来使用高级功能，可能构成许可证违规(多重化)4 无法持有用户许可证。使用高级功能的流程需要 Process 许可证(仅使用标准连接器则不需要)8
官方定位 面向个人生产力 官方最佳实践并不推荐(存在安全风险)4 推荐用于关键业务流程78

在实务中的使用区分标准大致如下。

  • 个人效率工具保持个人账户即可。如果试图对所有内容都进行严格管理，现场的自动化本身反而会萎缩。
  • 部门依赖的业务流程，至少要把通知的发件人改为共享邮箱5，共同所有者设置为 2 人以上。如果要建立用于执行的服务账户，应把权限压缩到必要的最小范围，并把能够访问凭据的人限定为几个人。Microsoft 自己也建议，与其使用服务账户，不如使用服务主体4，但在以标准连接器为中心的中小规模运维中，「专用账户 + 严格的密码管理」在很多场景下仍是现实可行的解法。
  • 关系到全公司核心业务的流程(与接单・开票・付款直接相关的流程)，值得考虑改为服务主体所有。由于所有者不再是人，因此不受离职影响，也能防止因所有者被剥夺许可证而导致流程停止的事故。8 不过服务主体存在无法成为共同所有者(只能作为所有者使用)、高级功能需要 Process 许可证等限制，走到这一步，就已经到了应该让 IT 部门或外部专家参与设计的阶段了。8

另外，即便建立了服务账户，也应避免把流程的创建以及各种小修改全都用该名义完成，而应采用创建者用自己的账户来创建，只把所有权与执行归到服务账户这样的方式，这样才能保持「谁在何时做了变更」的可追溯性。

6. 盘点与文档 ── 首先要知道「有什么」

人员依赖对策的出发点，是作为一个组织去掌握公司内到底有哪些流程。这和交接黑箱化系统时，最先要做可执行文件与任务的盘点是一样的道理，流程同样也有盘点的固定套路。

获取流程清单

  • 通过管理中心: 在 Power Platform 管理中心的环境页面打开「资源」→「流程」，就可以查看该环境内带所有者信息的流程列表。孤立流程的发现也是在这里进行。2
  • 通过 PowerShell: 管理用命令行工具 Get-AdminFlow，环境管理员可以获取自己管辖下的全部环境，全局管理员则可以获取租户内的全部流程。用 Get-AdminFlow | Export-Csv -Path '.\FlowExport.csv' 就能直接作为 CSV 台账的原始素材，也可以用 Get-AdminFlowWithHttpAction 只筛选出使用 HTTP 操作的流程(很可能与外部系统有对接)。9 如果不熟悉 PowerShell，也可以参考《PowerShell 命令基础 ── 应先掌握的操作与安全使用方法》一文。

最基本的流程台账

台账不要做得太复杂，这才是能够长期坚持下去的诀窍。用 SharePoint 列表或 Excel，一个流程占一行，只保留以下几列即可。

列 填写内容
流程名称 实际显示的名称(与后文的命名规则保持一致)
目的 用 1～2 句话说明「替代了哪项业务的哪个环节」
触发条件 启动条件(每天早上 7 点/Forms 回答时/收到邮件时等)
所有者・共同所有者 主负责人与副负责人。离职・调动时要查看这一列
连接 使用的连接器，以及连接是以谁的账户名义建立的
受影响业务 停止后会造成什么困扰。如果有手工替代方案，简单写一句
许可证 是否使用了高级连接器

关键在于「连接是以谁的名义建立」这一列。所有者可以在管理画面上看到，但连接的名义不打开流程就无从得知，因此这是最值得写进台账里的信息。

命名规则与「说明」栏

Microsoft 的编码指南建议，给流程的组成部件起有说明性且一致的名称，把命名规则形成文档并加以共享，并给操作加上相当于代码注释的备注。13 在实务中，只要把流程名统一为「[部门] 业务名 - 处理内容」(例如「[营业] 传真订单 - 保存 PDF 与通知负责人」)这样的格式，清单的可读性就会大幅改观。另外，流程的详情画面上有说明(Description)栏，也可以让 Copilot 生成草稿14，如果让流程本身也带有与台账「目的」一栏相同的内容，就能在台账过时时起到一层保险作用。

一旦建立台账，下一个问题也会浮现出来：当流程因错误而停止时，谁会注意到。失败时的通知与重试设计，我们在《Power Automate 的错误处理与重试设计》中做了详细讨论。

7. 环境与解决方案 ── 从「全部放进默认环境」迈出一步

Power Platform 中有一种叫做「环境」的分区，不做任何指定而创建的流程，都会进入默认环境(default environment)。默认环境是租户内全体用户都能访问的地方，只要拥有 Microsoft 365 许可证的员工，谁都可以在这里创建应用或流程。作为提升个人生产力的试验场，这样固然没问题，但 Microsoft 自己的指南也指出，默认环境很容易因创建者离职而堆积无所有者的资源，并建议应把广泛共享或在业务上变得重要的流程迁移到专用环境中。15

中小企业没有必要一开始就搭建正规的环境隔离(开发・测试・生产)。不过下面这两点，即使在规模还小的阶段，也值得留意。

  • 进入业务核心的流程要放入解决方案。解决方案是把流程及其组成部件打包搬运的容器，放入其中的流程(解决方案对应流程)可以当场变更所有者，可以用「连接引用」这种易于替换的形式持有连接，还能使用版本历史。310 正如第 4 章所见，这在离职时的交接便利性上有天壤之别。使用它需要带有 Dataverse 的环境。10
  • 至少确认一次 DLP 策略。把连接器分类为业务用/非业务用并限制其组合方式的数据丢失防护(DLP)策略，是防止野生流程把公司内部数据泄露到外部服务这类事故的安全网。16 关于治理整体的思路，我们在《用 Power Automate 实现业务自动化》的第 9 章有所提及。

环境隔离・ALM(开发→测试→生产的流水线)・借助 CoE Starter Kit 实现全公司统一管控，这些话题都在更远的地方，等流程数量达到几十个规模之后再考虑也来得及。首先是台账与解决方案化，其次才是环境。

8. 判断表 ── 这个流程是谁的资产

最后，来划定每个流程应该按哪个级别来管理的界线。对所有流程都进行严格管理并不现实，因此按照「停止运行后谁会困扰」分成三个阶段。

状况 定位 最低限度应做的事
只有本人使用。停止也只是本人回到手工操作 个人效率工具 只需登记进台账。管理交给本人
部门内多人依赖其结果。停止会让业务滞后数小时到一天 团队的资产 共同所有者 2 人以上、确认连接的名义、通知使用共享邮箱、完善台账与说明栏
与接单・开票・付款等核心业务直接相关。停止会影响到客户 公司的基础设施 解决方案化 + 执行账户/服务主体的设计 + 失败通知。若流程复杂度已达极限，考虑由 IT 部门或外包重新制作
创建者已经不在，没有人能说明其内容 黑箱 触碰之前先进行盘点与交接(第 4 章)。恢复出规格后，再判断是延续使用还是重新制作

对于已经沦落到最底层状态的流程，应对方式与开头提到的没有源代码也没有文档的系统的交接相同。不要急于重新制作，而应先观察触发条件・连接・输出目标，把「在做什么」写进台账开始做起。幸运的是，流程与没有源代码的 EXE 不同，其内容是完全可见的。只要能成为共同所有者，解读其定义本身并不困难。

此外，还有一个问题是「这项处理本来就应该继续放在 Power Automate 里吗」。容易成为人员依赖温床的复杂流程，改用 PowerShell 脚本、任务计划程序，或者业务系统一侧的功能来实现，有时反而能够纳入 Git 管理与代码评审，从而更容易交接。这方面的使用区分，我们在《Power Automate 与 PowerShell・任务计划程序的使用场景划分》中做了整理。

9. 总结

  • 流程绑定在创建者的账户与连接上。即使因离职而账户消失，流程本身依然会保留，但运行历史会被自动删除，使用离职者名义连接的操作会失败，高级流程会在 14 天的宽限期后被关闭。1124
  • 如果是在离职前，按照添加共同所有者→(若为解决方案对应流程)变更所有者→替换连接→将名义改为共享邮箱这样的顺序，只要有两周时间就能完成交接。31
  • 即使已经离职，也可以通过管理中心的「资源→流程」或 PowerShell(Get-AdminFlow/Set-AdminFlowOwnerRole)发现孤立流程，并重新分配所有者。不过连接的重新创建是无法避免的。2
  • 根本性的对策是：通过流程台账进行盘点、制定命名规则与说明栏、把通知名义改为共享、以及把重要流程的执行主体从个人身上分离出来的设计(服务账户要谨慎使用，核心业务用服务主体)。1367
  • 针对每个流程，判断它究竟属于「个人的工具」「团队的资产」还是「公司的基础设施」，并让管理的力度与之相匹配。我们认为，这才是既不会让现场的自动化萎缩，又能防止人员依赖的现实做法。

即便创建者本人目前并没有调动或离职的计划，我们也建议把本文第 4 章之前的内容当作一次「防灾演练」来实际操作一遍。如果在流程盘点、交接设计，或者判断某项处理是否应该放在 Power Automate 上而感到犹豫，欢迎随时向我们咨询。

相关文章

相关咨询领域

合同会社小村软件不仅承接因负责人离职、调动而变得无人能碰的自动化・业务系统的交接调查，还提供 Power Automate 的运维设计评审，直至把流程已无法承载的处理进行系统化开发。

参考链接

  1. Microsoft Learn, Share a cloud flow。关于共同所有者能做的事(查看运行历史、编辑・停止・删除流程、添加所有者)、共享的连接只能在该流程内使用、无法更改其他所有者创建的连接凭据、创建者离职后只要还有有效所有者流程就会继续运行、但使用离职者连接的操作可能失败因而需要更改连接(Modify a connection)、以及移除所有者时需要更新连接凭据等内容。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8

  2. Microsoft Learn, Manage orphaned flows when the owner leaves the organization。关于孤立流程(没有有效所有者的流程)的定义、使用绑定在离职用户账户上的连接的流程可能失败、在 Power Platform 管理中心(环境→资源→流程)中发现并通过「共享」添加所有者、以及用 Get-AdminFlowOwnerRole・Set-AdminFlowOwnerRole・Get-AdminFlow -CreatedBy 进行批量处理等内容。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9

  3. Microsoft Learn, Change the owner of a cloud flow。关于解决方案对应流程的所有者可以由所有者・共同所有者・管理员变更、变更后新旧所有者都会成为共同所有者、按计划/自动执行的流程会以新所有者的许可证运行且生效最长需要 7 天(保存则立即生效)、非解决方案流程因所有者是流程识别信息的一部分而无法当场变更所有者、所有者可以指定为用作服务账户的用户账户、以及管理员要变更流程必须先把自己添加为所有者・共同所有者等内容。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9

  4. Microsoft Learn, Power Automate licensing FAQ。关于所有者离职时的应对方式(解决方案对应流程变更所有者、非解决方案流程加入解决方案或导出/导入)、不处理时流程会先性能下降再于 14 天后被关闭，以及在 Multiplexing 一节中，多人共用的用户账户型服务账户不被作为最佳实践推荐(变更者难以追踪・密码管理存在风险・建议最小权限并限定访问者)、多人共用凭据来使用高级功能可能构成许可证上的多重化、以及推荐改用服务主体等内容。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9

  5. Microsoft Learn, Create flows for popular email scenarios。关于用「从共享邮箱发送电子邮件(V2)」操作可以从共享邮箱发送、事前需要拥有该邮箱的访问权限、以及发送的邮件会保留在共享邮箱的已发送文件夹中等内容。 ↩ ↩2 ↩3 ↩4

  6. Microsoft Learn, Formalizing messages and alerts。关于建议已定型化的通知使用共享发件人而非个人名义发送、Teams 的「以流程机器人身份发帖」系列操作、以及加入表明是自动发送并附带联系方式的署名这一实践等内容。 ↩ ↩2 ↩3 ↩4

  7. Microsoft Learn, Understand flow ownership and access。关于流程的所有者可以选择用户账户或服务主体、服务主体所有的优点(不受离职影响的稳定性・安全性・可审计性)、建议重要流程使用服务主体、以及共同所有者应保持必要最小限度且共享原则上应采用仅限运行(run-only)方式等内容。 ↩ ↩2 ↩3 ↩4 ↩5

  8. Microsoft Learn, Support for service principal owned flows。关于服务主体的应用程序用户可以拥有并执行流程、推荐用于希望避免受所有者离职或许可证被剥夺影响的关键业务流程、服务主体无法成为共同所有者、以及因无法持有用户许可证而使用高级功能的流程需要 Process 许可证(仅使用标准连接器的流程除外)等内容。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

  9. Microsoft Learn, PowerShell support for Power Apps and Power Automate。关于管理模块(Microsoft.PowerApps.Administration.PowerShell)的 Get-AdminFlow(全局管理员可获取整个租户的流程)、Get-AdminFlowOwnerRole、通过 Export-Csv 输出 CSV、Add-AdminFlowsToSolution、Get-AdminFlowWithHttpAction 等内容。 ↩ ↩2

  10. Microsoft Learn, Understand the benefits of using solution-aware cloud flows。关于解决方案对应流程的优点(易于在环境间迁移、可以用可替换的连接引用取代直接连接、拥有版本历史)，以及解决方案以 Dataverse 为前提等内容。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  11. Microsoft Learn, Respond to personal data deletion requests (Microsoft Entra ID)。关于即使把用户从 Microsoft Entra ID 中删除，流程与连接也不会被自动删除，而是需要管理员手动确认・删除，同时运行历史会被自动删除等内容。 ↩ ↩2

  12. Microsoft Learn, Types of Power Automate licenses。关于 Power Automate 的许可证分为用户许可证(分配给人)与容量许可证(分配给云端流程、机器等自动化对象)、Power Automate Process 属于容量许可证、分配给云端流程后无论所有者或触发用户持有什么许可证都能使用高级・自定义连接器、分配 Process 许可证需要流程已加入解决方案、以及适合不想让每个共同所有者都持有用户许可证却仍要维持流程运行的组织等内容。 ↩ ↩2

  13. Microsoft Learn, Use consistent naming for flow components。关于给流程的组成部件起具有说明性且有意义的名称、把命名规则形成文档并加以共享、以及给操作加上注释(备注)以留存意图等内容。 ↩ ↩2

  14. Microsoft Learn, Generate flow description using AI。关于流程详情画面的「说明」可以编辑、以及由 Copilot 自动生成说明文字的功能已经正式发布等内容。 ↩

  15. Microsoft Learn, Manage and govern the default Power Platform environment。关于组织内全体员工都能访问默认环境、因创建者离职而容易堆积无所有者的流程・应用因而应建立孤立资源的整理流程、以及建议把广泛使用或在业务上变得重要的流程与应用从默认环境迁移到专用环境等内容。 ↩

  16. Microsoft Learn, Data policies。关于通过把连接器分类为业务用/非业务用/阻止，并限制其组合方式的数据丢失防护(DLP)策略进行治理等内容。 ↩

相关文章

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

相关主题

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

与本主题相关的服务

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

常见问题

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

创建 Power Automate 流程的负责人离职后，流程会变成怎样？
即使删除了离职者的账户，流程本身也不会自动消失，只要还留有共同所有者，就会继续运行。不过，流程内的连接(对 SharePoint、Outlook 等的身份验证)绑定在创建者本人的账户上，因此使用离职者连接的操作会随账户被禁用・删除而开始失败。此外，没有任何有效所有者的流程会变成「孤立流程」，使用高级功能的流程一旦所有者失去许可证支撑，性能就会下降，如果不加以处理，将在 14 天后被禁用。离职前添加共同所有者并替换连接非常重要。
管理员能够接手离职者创建的流程吗？
可以。在 Power Platform 管理中心选择环境，打开「资源」→「流程」，就能确认没有所有者的孤立流程，并通过「共享」添加新的所有者。如果流程数量较多，也可以用管理用 PowerShell 模块的 Get-AdminFlow 获取列表，再用 Set-AdminFlowOwnerRole 批量添加共同所有者。不过即便接手了所有者身份，离职者名义的连接原样是无法运作的，因此还需要另外把流程内各操作的连接替换为新账户的连接。
只要预先添加了共同所有者，作为离职对策就足够了吗？
并不足够。共同所有者虽然能够编辑・停止流程，甚至添加所有者，但无法更改他人创建的连接凭据，共享的连接也只能在该流程内部使用。使用离职者连接的操作，只有等共同所有者把它替换成自己的连接之后，才能继续运行下去。此外，通知邮件持续以离职者名义发送的问题依然存在，因此需要与「发送改用共享邮箱」「关系到核心业务的流程改用执行专用账户或服务主体持有」这类设计配套考虑。
应该为流程的执行创建一个共用的服务账户吗？
这可以作为一个选项，但 Microsoft 并没有把多人共用用户账户的服务账户作为最佳实践来推荐。因为密码由多人共享，难以追踪是谁做了修改，密码管理本身也会成为风险。如果要使用，应把权限压缩到必要的最小范围，并限定能够访问的人数。对于关键业务流程，官方推荐使用不依赖个人账户的服务主体持有方式，但请注意，设置需要 IT 一侧的专业知识，并且如果使用高级功能，还需要 Process 许可证。

作者简介

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

Go Komura

小村软件有限公司 代表

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

联系我们
返回博客列表