小村軟體有限公司
聯絡我們
選單

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
  • 多人共用使用者帳戶的服務帳戶，官方最佳實務並不推薦使用，任務關鍵型流程則官方推薦由服務主體擁有。不過中小企業在設定與授權方面存在門檻，本文第 5 章將整理更貼近實際的使用區分方式。478
  • 對策的第一步不是技術，而是盤點。先用管理中心和 Get-AdminFlow 列出公司內部到底有哪些流程，從建立一份最基本的流程台帳(名稱・目的・擁有者・連接・影響業務)開始。9

2. 流程的屬人化是如何發生的

Power Automate 的屬人化，並非出於惡意或懈怠，而是善意不斷累積的結果。典型的經過是這樣的。

  1. 現場熟悉的人，為了讓自己的工作更輕鬆而建立流程。像「把 Forms 的回覆轉寫到 Excel」這種程度的小工具。
  2. 因為方便，周圍的人也跟著搭上這股風潮。「那個通知也發給我們課吧」「訂單也能幫忙保存嗎？」這類需求不斷聚集，流程隨之增加、成長。
  3. 不知不覺間滲透進業務的核心。訂單的第一線聯絡、請款單的保存、核准的傳遞這類「一旦停止業務就會停滯」的處理，就這樣靠那個人個人帳戶下的流程運轉起來。
  4. 在沒有人知道內容的情況下穩定運作。因為沒有理由去動一個正常運作中的東西，交接與文件都沒有被建立。「因為在運作所以不能動」，就這樣直接變成「沒有人能動」。

到這裡的構圖，和開發負責人離職後留下沒有原始碼也沒有規格書的系統，是同一回事。不過 Power Automate 有兩點比舊系統更棘手。第一，建立的地方是個人的「我的流程」，除了本人以外根本看不到它的存在。與伺服器上會留下執行檔的系統不同，流程若不進行盤點，甚至連清單都不會出現。第二，流程的執行依賴於建立者的帳戶與連接。離職處理將帳戶停用・刪除的瞬間，影響就會顯現出來。下一章將準確確認這個行為。

先說明一個用語 ── 什麼是「解決方案對應流程」

由於後面的章節會反覆出現，這裡先掌握清楚。解決方案是把流程與其零件(連接參照、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 的授權 ── Microsoft 365 能免費用到什麼程度、何時需要 Premium」中整理)。

郵件持續以本人名義寄出的問題

容易被忽略的是通知的「名義」。由於「傳送電子郵件 (V2)」動作是從所連接的使用者信箱寄出，只要流程持續運作，通知郵件就會持續以建立者個人的名義寄出。在職期間頂多是「為什麼每天早上都是那個人寄來的郵件？」，但離職後隨著帳戶停用，寄送本身也會失敗。反過來說，若共同擁有者只把連接替換成自己的，這次就會變成以那個人的名義寄出所有通知。

Microsoft 的指引建議，應避免以個人名義寄送已定型化為業務的通知，而使用共用寄件者。若是 Outlook，可以用「從共用信箱傳送電子郵件 (V2)」動作，從共用信箱(例如 noreply-flow@example.co.jp)寄出，寄件記錄也會留在共用信箱的寄件備份資料夾中(寄送需要有信箱的存取權限)。若是傳送給 Teams 的通知，「以 Flow 機器人身分張貼」系列的動作可以發揮同樣的作用。同時加上「這封郵件由 Power Automate 自動寄出，如有疑問請洽 ◯◯」這樣的簽名，即使負責人更換，收件方也不會感到困惑。56

4. 離職前該做的事・離職後能做的事

離職前 ── 只要有 2 週就來得及

一旦確定離職或調動，就依下列 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 的授權 ── Microsoft 365 能免費用到什麼程度、何時需要 Premium」中整理過。

在此基礎上，比較各個選項。

觀點 個人帳戶 服務帳戶(共用的使用者帳戶) 服務主體
離職・調動的影響 直接衝擊(連接・授權・名義全部受影響) 不受影響。但建立者離職時需要變更密碼 不受影響(不綁定於個人)7
導入的工夫 無。建立後即可使用 僅需建立帳戶並指派授權 Entra ID 應用程式註冊+建立應用程式使用者。需要 IT 端的專業知識8
密碼・MFA 由本人管理 以共用為前提是弱點。難以追蹤是誰變更的，密碼管理本身就是風險。設定 MFA 後，誰持有驗證方式又是另一個維運問題4 無密碼共用。但需要管理密鑰/憑證
授權 以本人的授權執行 需要 1 人份的使用者授權。多人共用憑證來使用進階功能，可能構成授權違規(多工化)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 個流程 1 列，只保留以下欄位。

欄位 填寫內容
流程名稱 實際的顯示名稱(依後述的命名規則)
目的 「取代了哪項業務的哪個作業」用 1～2 句話說明
觸發條件 啟動條件(每天早上 7 點／收到 Forms 回覆時／收到郵件時等)
擁有者・共同擁有者 主要負責人與次要負責人。離職・調動時要看這裡
連接 使用的連接器，以及連接是以誰的帳戶名義建立的
影響業務 停止運作會造成什麼困擾。若有人工替代方案請簡短說明
授權 是否使用進階連接器

重點在於「連接是誰的名義」這一欄。擁有者可以從管理畫面得知，但連接的名義不開啟流程就看不到，因此是最值得寫進台帳裡的資訊。

命名規則與「說明」欄

Microsoft 的程式設計指引建議，為流程的零件取具描述性且一致的名稱，將命名規則文件化並共用，並在動作上加註相當於程式碼註解的備忘。13 實務上，只要把流程名稱統一成「[部門] 業務名稱 - 處理內容」(例如：「[業務] FAX 訂單 - 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. 判斷表 ── 這個流程是誰的資產

最後，是個別流程該用什麼層級來管理的界線。嚴格管理所有流程並不現實，因此依「停止運作會讓誰困擾」分成 3 個階段。

狀況 定位 最低限度要做的事
只有本人使用。停止運作也只是本人回到手動作業 個人的效率化工具 只需登記到台帳。管理交給本人
部門內多人依賴其結果。停止會讓業務停滯數小時～1 天 團隊的資產 共同擁有者 2 名以上、確認連接的名義、通知改用共用信箱、整理台帳與說明欄
直接關係到受訂・請款・付款等核心業務。停止會影響往來廠商 公司的基礎設施 解決方案化+執行帳戶/服務主體的設計+失敗時通知。若流程複雜度已達極限，考慮由 IT 部門或外部委託重新製作
建立者已經不在，沒有人能說明內容 黑箱 動手前先進行盤點與交接(第 4 章)。復原規格之後，再判斷要延續使用還是重新製作

面對淪落到最底層狀態的流程，處理方式和開頭提到的沒有原始碼也沒有規格書的系統交接是一樣的。不要貿然重新製作，而是先觀察觸發條件・連接・輸出目的地，把「在做什麼」寫進台帳，從這裡開始。幸運的是，流程和沒有原始碼的 EXE 不同，內容全部都看得到。只要能成為共同擁有者，解讀定義本身並不困難。

另外，也有「這個處理究竟是否該繼續放在 Power Automate 上」這個問題。容易成為屬人化溫床的複雜流程，改用 PowerShell 指令碼、工作排程器，或是業務系統端的功能來處理，有時反而能納入 Git 版本管理與程式碼審查，更容易交接。這樣的使用區分，已在「Power Automate 與 PowerShell、工作排程器的使用區分」中整理過。

9. 總結

  • 流程綁定在建立者的帳戶與連接上。即使因離職而帳戶消失，流程本身仍會保留，但執行歷程記錄會自動刪除，使用離職者名義連接的動作會失敗，進階流程則會在 14 天的緩衝期後停用。1124
  • 離職前的話，只要按照新增共同擁有者→(若為解決方案對應流程)變更擁有者→替換連接→改為共用信箱名義的順序，2 週就能完成交接。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 的「以 Flow 機器人身分張貼」系列動作，以及加入標示自動寄送與聯絡方式簽名的實踐說明。 ↩ ↩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 軟體開發、技術諮詢與故障調查為中心，在難以重現的故障調查與既有資產仍在運作的專案上具有優勢。

聯絡我們
回到部落格一覽