Power Automate 的流程失敗時，會自動收到通知郵件嗎？

只會在有限的情況下收到。以單次執行為單位的失敗警示郵件，是在判定為連線中斷、節流（throttling）等「有已知修復方法的失敗」時，才會發送給擁有者與共同擁有者，一般的動作失敗不會發送。而且一旦發送過一次，同一個流程會有 28 天的冷卻期，期間不會再收到額外的警示。以單次執行為單位的失敗警示，也並非在所有流程上都預設啟用。若要確實掌握失敗狀況，建議在 Catch 區塊中自行設計通知到 Teams 或 email 的機制。

Power Automate 的標準重試會執行幾次、間隔多久？

當動作的要求逾時，或以 408、429、5xx 系列的回應失敗時，預設會以指數方式逐漸拉長間隔並自動重試。次數依流程的效能設定檔（實質上等同於授權層級）而異，Microsoft 365 授權等低階設定檔最多重試 2 次，Power Automate Premium 或 Process 授權等中高階設定檔最多重試 12 次。可在動作設定中將重試原則改為「無、固定間隔、指數間隔」，次數最多可設定到 90 次。像 400 或 404 這種因資料、設定造成的錯誤，不會成為重試的對象。

要如何重新執行（重新提交）失敗的流程執行？

從執行記錄中開啟失敗的執行，選擇「重新提交」，即可用相同的觸發資料重新執行一次。若原因出在流程定義有誤，先修正流程並儲存後再重新提交，就會依修正後的內容重新執行。從執行記錄清單中，一次最多可以彙整重新提交 20 筆。要注意的是，重新提交會讓流程從頭重新執行一次，因此對於中途曾經成功過的執行，已經成功的處理也會再執行一次。必須事先做成即使重複執行也不會破壞結果的冪等設計（處理完成旗標、以更新優先於新增的寫入方式）。

流程有沒有可能在不知不覺間被停用？

有可能。觸發程序或動作持續失敗的流程，會在 14 天後自動被關閉。持續被節流（超過限制）的流程也同樣會在 14 天後被關閉。此外，90 天內完全沒有被觸發過的流程，若不是擁有進階授權或容量授權，也可能會被關閉。放任失敗不管會直接導致流程停止，因此在維運上納入察覺失敗的機制，以及定期確認執行記錄（預設 28 天）非常重要。

防止 Power Automate 流程停止的錯誤處理

「原本每天早上都會執行的彙總流程，其實從上週開始就已經停了」「訂單登錄流程把同一筆資料處理了兩次，帳冊裡出現了重複資料」。從開始建置並運用 Power Automate 流程的公司，經常會收到這類諮詢。建置本身很簡單，但流程停止時卻沒有人察覺，是常見的模式。

Power Automate 的流程，只要走正常路徑，數小時就能動起來。不過，連線的服務會暫時性中斷，驗證會過期，也一定會流入預期之外的資料。沒有針對「失敗時會發生什麼事」進行設計的流程，會默默累積失敗，最糟的情況下會在 14 天後被自動關閉¹。本文將從流程失敗的分類、標準重試的正確規格、以範圍（Scope）打造的 Try-Catch-Finally 模式、察覺失敗的機制，一路到重新執行與冪等性，整理出足以承受正式環境運作的錯誤處理設計模式。至於 Power Automate 整體的使用區分，以及 UI 自動化端（桌面流程）的錯誤處理，已在「用 Power Automate 自動化業務 ── 雲端流程與桌面流程的分工，以及錯誤處理設計」中討論過，本文聚焦於深入探討雲端流程。

1. 先講結論

失敗可分為「暫時性障礙」「資料所致」「權限、驗證過期」「規格變更」這四類來思考。標準重試能解決的只有第一類，剩下三類都需要偵測與修正的機制²。
標準的重試原則，只有在要求逾時，或以 408、429、5xx 回應失敗時才會運作。預設為指數退避（exponential backoff），次數依授權層級（效能設定檔）而異，最多 2 次或 12 次³¹。
錯誤處理的基本形式是範圍（Scope）+「執行條件設定」構成的 Try-Catch-Finally。「執行條件設定」可從「成功時、失敗時、被略過時、逾時時」這 4 種狀態中選擇³⁴。此功能在日文 UI 上顯示名稱為「執行条件の構成」，在英文 UI 與文件中則稱為「run after」。以下統一使用 UI 顯示名稱執行條件設定。
在 Catch 中處理完失敗後，最後要用Terminate 動作把該次執行記錄為「失敗」。若忘記這一步，執行記錄上會顯示為成功，失敗就這樣被吞掉了⁴³。
預設的失敗通知郵件僅限「有已知修復方法的失敗」，且附帶 28 天冷卻期，若完全依賴它，漏洞相當多。應將 Catch 區塊中的自訂通知視為必要項目⁵。
執行記錄預設只能看到28 天內的資料。持續失敗的流程會在14 天後自動關閉。「一個月後才發現流程早就停了」在規格上是完全可能發生的⁶¹。
為了應對重新執行（重新提交）與重複啟動，要從一開始就導入即使重複執行也安全的冪等設計（處理完成旗標、以 upsert 取代新增、觸發條件）⁷⁸。

2. 流程是如何失敗的 ── 失敗的 4 種分類

錯誤處理的設計，從「如何失敗」的分類著手會比較容易梳理。Microsoft 的指引也要求，自動化必須視為一定會失敗的東西，並事先設想連線服務的維護、API 的變更、密碼變更、瞬間性的網路故障等情況²。實務上以下列 4 種分類來思考，對應方式就會自然確立。

分類	典型範例	重試能否解決	因應方向
暫時性障礙	連線目標瞬斷、維護、節流（429）、伺服器錯誤（5xx）	多半可以解決	交給標準重試處理（第 3 章）
資料所致	預期外的空值、格式、參照目標不存在的 ID（400/404）	無法解決	以 Try-Catch 捕捉並通知（第 4 章）、輸入端驗證
權限、驗證過期	連線的有效期限過期、密碼變更、負責人離職、帳號停用	無法解決	需要重新驗證。偵測與通知（第 5 章）、連線持有方式的設計
規格變更	SharePoint 欄位名稱變更、連線目標 API 版本變更、表單項目變更	無法解決	需要修改流程。變更管理與通知

其中實務上最棘手的是權限、驗證過期。因為不只流程的動作會失敗，連觸發程序本身都會開始失敗。官方疑難排解也把連線所用密碼的變更（過期）列為觸發程序以 4xx 系錯誤失敗的典型範例。觸發程序一旦失敗，流程根本不會啟動，因此連執行記錄上都不會留下「失敗」這一列，會更難察覺⁹。連線與建立它的使用者個人綁定，因此也會發生負責人離職、調動時一次全部中斷的事故。這方面的組織性對策，在「Power Automate 的人員依賴對策 ── 讓建立者離職後流程也不會停止」中有詳細討論。

還有一件應該知道的事：放任失敗不管，流程本身會被強制停止。觸發程序或動作持續失敗的流程會在 14 天後自動關閉，持續被節流的流程也同樣會在 14 天後關閉。90 天內未曾被觸發的流程，若不是擁有進階授權或容量授權，也可能會被關閉¹。此外，DLP（Data Loss Prevention：資料遺失防護。由管理員限制連接器的可用性與組合，防止組織資料意外外流的防護機制。目前的官方名稱為「資料原則」）¹⁰政策違規，或反覆失敗，也可能導致流程進入「中斷（suspended）」狀態¹¹。DLP 政策的變更會立即生效，且會在毫無預警的情況下讓流程停止，因此當多個流程同時故障時，先懷疑是不是政策變更是常見的判斷準則¹¹。「原本運作正常的流程不知不覺停了」，有一部分並非障礙所致，而是這項規格造成的。

3. 理解標準重試

Power Automate（底層為 Azure Logic Apps）的動作，從一開始就內建了重試原則。先正確掌握這項規格，才能判斷「是否該追加重試設定」「重試是否無法解決問題」。

什麼情況、何時會重試

重試原則發動的條件，是動作（或觸發程序）的要求逾時，或以 408（要求逾時）、429（要求過多＝節流）、5xx（伺服器錯誤）的回應失敗時³。預設原則為指數退避（一邊指數性拉長間隔一邊重試），在 Power Automate 中預設的次數與間隔，依流程的效能設定檔（實質上等同於授權層級）而異¹。

效能設定檔	主要對應授權	預設重試
Low	Microsoft 365 方案、免費方案等	最多 2 次。以約 5 分鐘為單位逐漸拉長間隔，最後一次重試約間隔 10 分鐘
Medium / High	Power Automate Premium、Process 授權等	最多 12 次。從 7 秒起指數性拉長，最後一次重試約間隔 1 小時

也就是說，即使是同一個流程定義，「對暫時性障礙的耐受力」也會因擁有者的授權而不同。設定檔不僅影響重試次數，也會影響每日的要求數上限，關於授權層級的思考方式，可參考「Power Automate 的授權與標準／進階連接器的界線」。

重試原則可從動作設定中變更。種類共有預設、無、固定間隔、指數間隔4 種，可明確指定次數與間隔。設定上限為次數 90 次、最小間隔 5 秒、最大延遲 1 天³¹。Microsoft 的程式設計指引建議，若要從暫時性障礙中復原，應優先使用指數間隔而非固定間隔，理由是為了不以短間隔持續敲打對方，妨礙其恢復⁴。

重試能解決的、不能解決的

事象	重試是否能解決
連線目標瞬斷、逾時（408/5xx）	多半可以解決。維持預設即可
節流（429）	若間隔拉長可能解決。但持續性的 429 是設計問題（需要減少要求數）
資料不正確（400）、資源不存在（404）	無法解決。重試幾次都是同樣的錯誤
驗證錯誤（401/403）、連線中斷	無法解決。需要在流程之外進行重新驗證操作
業務層面的失敗（核准被駁回、庫存不足等）	本來就不是 HTTP 錯誤，不屬於重試對象。應以流程分支處理

要注意的是，重試也會消耗要求數（Power Platform 要求）。無論成功或失敗，動作的執行都會計入要求數，重試與分頁的要求也一樣¹。針對 429 增加重試次數的調整方式，有時反而會讓節流更嚴重，因此在加厚重試之前，應先檢討「能否減少呼叫次數本身」。

4. Try-Catch-Finally 模式 ── 範圍與執行條件設定

無法靠重試解決的失敗，要在流程中捕捉並處理。Power Automate 並沒有 try-catch 這種語法，但可以組合範圍（Scope）與執行條件設定（英文 UI 稱為 run after）來建構出相同的結構。這也是 Microsoft 程式設計指引中推薦的標準做法⁴。

支撐這套機制的基礎是執行條件設定。每個動作完成時，會擁有成功（Succeeded）、失敗（Failed）、略過（Skipped）、逾時（TimedOut）其中一種狀態，後續動作預設只會在「前一個動作成功時」執行。這項條件可以逐個動作變更，藉此建立在「失敗時」「逾時時」執行的分支³。

設定的位置，初次接觸時很難找到。在設計工具中開啟目標動作（或範圍）的「…」（三點選單），選擇「執行條件設定」，就會出現一個面板，針對緊鄰前一個的每個動作，並排顯示 4 種狀態的核取方塊¹¹。在此勾選需要的狀態即可。若要說有什麼要注意的地方，那就是必須至少選取一種狀態，因此取消預設的「成功時」，必須在勾選其他狀態之後進行，順序要對³。此外，執行條件設定並不限於「前一個動作」，也可以指定多個前置動作，並分別為每個動作指定狀態³。

把這套機制套用到範圍上，就會形成 Try-Catch-Finally。範圍會把所包含的所有動作結果彙整為單一狀態，因此「Try 範圍內只要有任何地方失敗，就執行 Catch 範圍」這種結構，比起逐一為每個動作設定條件，維護性壓倒性地高³⁴。

flowchart TD
    Trigger[觸發程序] --> Try[[Try 範圍<br/>把主要處理整合在此]]
    Try -- 成功 --> Fin
    Try -- 失敗/逾時 --> Catch[[Catch 範圍<br/>執行條件設定: 失敗、逾時時]]
    Catch --> Extract[以 result 函式+陣列篩選<br/>取出失敗的動作與原因]
    Extract --> Notify[以 Teams/email 通知負責人<br/>流程名稱、失敗步驟、錯誤詳情、執行 URL]
    Notify --> Fin[[Finally 範圍<br/>執行條件設定: 成功、失敗、略過、逾時全部]]
    Fin --> Cleanup[收尾處理，更新帳冊的狀態欄位]
    Cleanup --> Judge{是否經過 Catch}
    Judge -- 是 --> Term[Terminate<br/>狀態: Failed，結束執行]
    Judge -- 否 --> Done([正常結束])

組裝上的重點有 4 個。

Catch 範圍的執行條件設定要同時選擇「失敗時」與「逾時時」。取消預設的「成功時」。若只選失敗，等待核准或延遲動作的逾時就會漏接³。
在 Catch 中取出失敗的內容。result('Try 範圍名稱') 函式會以陣列傳回範圍下各動作的結果（狀態、輸入輸出、錯誤內容），只要用「陣列篩選」（Filter array）篩出狀態為Failed 或 TimedOut的項目，就能把失敗的動作名稱與錯誤訊息放進通知裡³⁴。若只用 Failed 篩選，經由逾時進入 Catch 時篩選結果會是空的，通知裡就會缺少關鍵的失敗步驟。同時再用 workflow() 函式取出執行 ID，組出指向執行記錄的直達連結 URL，調查工作會輕鬆許多（算式見下一節）⁴。
Finally 範圍的執行條件設定要選擇全部 4 種狀態。無論成功或失敗都一定要執行的收尾工作（刪除暫存檔、更新帳冊的狀態欄位等）放在這裡。
失敗的執行，最後要用 Terminate 動作以「失敗」結束。這是最容易被遺忘的一點。Catch 正常完成後，就整個流程執行而言，最後一個動作是以成功結束，執行記錄上會記為「成功」。也就是說，若只做了通知就結束，執行記錄上就看不到失敗，會從監控與後續統計中漏掉。用 Terminate 設定狀態為 Failed 並附上錯誤訊息後結束，執行記錄上也會留下失敗的紀錄⁴³。不過絕對不能把 Terminate 直接放在 Catch 範圍的末尾。Terminate 會在當下立即結束整個執行，導致後續的 Finally 範圍不會被執行，錯誤發生時最需要的收尾工作反而會被跳過。如圖所示，應在 Catch 中設定失敗旗標（變數）後只做到通知為止，通過 Finally 的收尾處理後再判斷該旗標，只有在失敗時才以 Terminate 結束，這樣的順序才正確。

順帶一提，執行條件設定也是核准流程逾時分支（催辦、升級）的核心元件。具體的組裝方式，在「用 Power Automate 建立核准流程 ── 把紙本與 email 的簽核、申請電子化」中有討論。

Catch 的內容 ── 用算式取出失敗的動作與執行 URL

這裡是實作上的關鍵，因此把算式也寫出來。假設 Try 範圍的名稱為 Try，「陣列篩選」（Filter array）的設定如下。條件要切換成「以進階模式編輯」，直接寫算式³⁴。

開始（From）:  @result('Try')
條件（進階模式）: @or(equals(item()['status'], 'Failed'), equals(item()['status'], 'TimedOut'))

從 result() 傳回的每一個項目中，可以取出以下的值。通知內文只要並列這 4 項，在打開執行記錄之前就能大致掌握狀況³。

想取得的資訊	算式
失敗的動作名稱	`item()['name']`
狀態（Failed / TimedOut）	`item()['status']`
錯誤代碼	`item()['code']`
回應內文（錯誤訊息）	`item()['outputs']['body']`

指向執行記錄的直達連結，要用 workflow() 函式組裝。這個函式會傳回一個物件，內含流程的 ID（name）、環境名稱（tags.environmentName）、流程的邏輯名稱（tags.logicAppName）、執行的 ID（run.name）等，因此 URL 的形式如下。

concat('https://make.powerautomate.com/environments/', workflow()?['tags']?['environmentName'],
       '/flows/', workflow()?['tags']?['logicAppName'],
       '/runs/', workflow()?['run']?['name'])

官方文件是以先用「剖析 JSON」（Parse JSON）解析 workflow() 的輸出，再用「作曲」（Compose）動作組裝 URL 的步驟來說明的⁴。無論用哪種方式，結果都相同，不過入口網站的 URL 有可能改變，組好之後請務必先點一次產生出來的連結，確認能開啟目標的執行記錄。同一份文件也提醒，若增加太多自訂的日誌輸出，會使動作數量與執行時間膨脹、反而造成反效果⁴。實務上，放進通知的資訊聚焦在「流程名稱、失敗動作、錯誤、執行 URL」這 4 項即可。

5. 察覺失敗的機制 ── 通知與可視化

即使組好了錯誤處理，如果沒有人察覺失敗，就毫無意義。「察覺的機制」不應依賴預設通知，而要以多層方式設計。

正確理解預設的失敗通知郵件

Power Automate 具備失敗時發送通知郵件的機制，但若不了解規格就依賴它，會有許多漏洞。通知共有 2 種⁵。

以單次執行為單位的失敗警示：在執行失敗後立即發送，但只有在被判定為連線中斷、節流、已知的連接器錯誤等「有已知修復方法的失敗」時才會發送。一般的動作失敗不會發送。收件人是擁有者與共同擁有者（不包含僅供執行用的使用者），也不會發送給管理員。而且一旦發送過一次，同一個流程會有28 天的冷卻期，期間內的失敗不會再收到額外的警示。以單次執行為單位的警示，也不是在所有流程上都預設啟用，需要在流程設定中確認⁵。
每週的失敗摘要：每週會發送一次跨環境的失敗彙整摘要。單次執行警示不會發送的一般性失敗，也會包含在這裡⁵。

除此之外，針對特定錯誤，會有附帶修復步驟的「修復提示」郵件發送給擁有者（也可以逐個流程關閉）⁷。整體而言，預設通知是一套「能察覺第一次的連線中斷，但業務資料所致的失敗或第二次以後的失敗容易漏接」的機制。在重要的流程上，應將第 4 章 Catch 區塊發出的自訂通知視為必要項目。

來自 Catch 的通知設計 ── 通知流程本身也會失敗的情況

自訂通知也有設計上的重點。

收件人不要設為個人。若寄給負責人個人，一旦本人不在或離職，就沒有人能收到。官方文件也建議寄到共用信箱或 Teams 頻道¹¹。
讓通知的路徑與主要處理分開。常見的事故是「Outlook 連線中斷導致流程失敗，而失敗通知也使用同一個 Outlook 連線，結果一起無法送出」的雙重失敗。因驗證過期導致的失敗，使用同一連線的通知動作也會同時失敗。將通知改用 Teams 貼文等與主要處理不同的連接器、不同的連線，或是拆分成專門負責通知的小型流程來呼叫，可以降低同時失敗的風險。即便如此，「通知的通知」也無法無限層層疊加，因此要以下述的定期確認作為最後一道防線。
通知要包含調查所需的全部資訊。流程名稱、失敗的動作名稱、錯誤訊息、指向執行記錄的直達連結。若缺少這些，即使收到通知，也只能知道「有東西失敗了」，容易被放著不管⁴。

可視化與定期確認

流程檢查工具：能在儲存前偵測流程定義中的錯誤與警告。養成建置完成後檢查一次的習慣¹²。
定期確認執行記錄：流程的執行記錄預設只顯示28 天內的資料⁶。納入解決方案的流程，可以把執行記錄的中繼資料留存在 Dataverse 中，但這部分的預設保留期一樣是 28 天，延長需要由管理員端設定¹³。對於正式環境的流程，建議每週確認一次，不只看失敗，還要包含「處於取消狀態的執行」（有時是同時執行控制造成的）與「執行次數驟減」（觸發程序未運作的徵兆）¹¹。
管理員的集中監控：若要查看包含未發送單次執行警示郵件在內的所有失敗，Power Platform 系統管理中心的 Monitor（監控）最為全面。可以依流程、依環境確認失敗件數與錯誤詳情⁵。

若是定期執行的流程，還需要監控「是否根本有啟動」。包含營業日判斷與月底處理在內的定期執行設計，在「Power Automate 的定期執行流程與營業日設計」中有討論。

6. 重新執行與冪等性 ── 打造「即使重複執行也不會壞掉」的機制

對失敗的因應，不能止於偵測。「把失敗的部分重做一次」的操作，與「即使重做也不會壞掉」的設計，必須成對存在。

重新提交（resubmit）的規格

失敗的執行，可以從執行記錄中用重新提交（Resubmit）重做一次。這是以相同的觸發資料重新執行的操作，若原因是暫時性障礙（500/502 等），可以直接重新提交；若原因出在流程定義有誤，先修正並儲存後再重新提交，就會依修正後的定義重新執行⁷。從執行記錄清單中，一次最多可以彙整重新提交 20 筆，可用於大量失敗時的復原。至於手動啟動（即時觸發程序）的流程，自己的執行隨時都可以重新提交，但要重新提交其他使用者啟動的執行，需要由管理員在租用戶設定中允許¹⁴。

這裡重要的是，重新提交會讓流程從頭重新執行一次。假設 10 個步驟中的第 8 步失敗，重新提交後，原本已經成功的第 1 到第 7 步也會再執行一次。「email 明明已經寄出過卻又寄了一次」「帳冊裡出現了兩筆一模一樣的資料」這類事故，就是由此而起。

冪等性 ── 即使重複執行也安全的設計

因此，要從一開始就導入無論執行幾次相同的輸入、結果都相同（冪等）的設計。這不只對重新提交有效，對觸發程序的重複啟動與並行執行也同樣有效，是錯誤設計的核心所在。

持有處理完成旗標。在 SharePoint 清單等帳冊上設置「狀態」欄位（未處理／處理中／已處理），流程一開始就確認狀態，若已處理就在此結束，處理完成後再更新狀態。這樣一來，即使重新提交也不會變成重複處理。不過旗標必須連更新的順序都確定下來才會真正發揮作用。像寄送 email、登錄到核心系統這類對外的副作用，要先在執行前把狀態更新為「處理中」，完成後再改為「已處理」。若在副作用之後、旗標更新之前失敗，該筆執行會停留在「處理中」，成為不清楚副作用是否已完成的狀態。若機械式地重新提交這一列，有可能造成重複發送，因此應把「處理中」的列排除在自動重新執行的對象之外，對照實際的發送結果、登錄結果後，再由人工把狀態改回「已處理」或「未處理」。可以放心重新執行的，只有停留在「未處理」的列。
不要用「新增」，而要用「有就更新、沒有就新增」（upsert）。以能唯一識別的鍵（訂單編號、申請 ID 等）搜尋既有列，若命中就更新、若沒有就新增，做成分支。無條件的「新增項目」，每次重新執行都會累積出重複的列。反過來說，沒有唯一鍵的資料就無法做到冪等，因此在帳冊設計階段就要先決定好鍵欄位，這是前提。
用觸發條件擋掉不必要的啟動。像「項目建立或變更時」這類觸發程序，因為流程自己把結果寫回去而導致自身重新啟動，這類多重啟動不應該靠後段的條件分支，而應該用觸發條件（trigger conditions）擋下來。不滿足觸發條件的事件，根本不會發生執行，因此也不會消耗執行次數與要求數⁸。

有一點要注意。處理完成旗標或 upsert 這種「先確認再寫入」的方式，對重新提交這類依序進行的重做有效，但單獨使用並非原子性的保護。若重複的觸發事件幾乎同時啟動兩次，就有可能發生兩邊都讀到「未處理」後、兩邊都繼續處理下去的競爭情況。對於可能發生並行啟動的流程，若要確實防止重複，請併用下一節的同時執行控制，把並行度設為 1 以序列化，或是在儲存端使用能強制唯一鍵限制的機制（如資料庫的唯一限制），讓重複的新增在寫入當下就失敗。

同時執行控制（concurrency control）與順序的取捨

與重複執行並列的問題，是「同時執行」與「順序」。預設情況下，只要滿足觸發條件的事件同時大量發生，流程就會並行執行任意多個¹。多個執行同時對帳冊的同一列進行讀寫，有可能發生讀到舊值後覆寫的不一致（髒讀）¹⁵。

把觸發程序設定中的同時執行控制（Concurrency Control）打開，就可以把並行執行數（並行度）指定為 1 到 100。若把並行度設為 1，執行就會一次一個，更接近依序處理¹¹⁵。不過，這個開關有幾個沉重的注意事項。

一旦開啟就無法還原。要恢復為關閉，只能刪除觸發程序後重新建立¹。由於同時執行控制不可逆，建議只套用在動作數量少的流程上（必要時可拆成子流程）¹⁵。
會產生漏接的風險。開啟同時執行控制時，能等待的執行數上限為「10＋並行度」，到達此上限時抵達的觸發程序雖然會在連接器端重試，但若超出上限的狀態持續太久，就有可能無法進入執行。對於希望所有觸發都確實進入執行的流程，官方文件明確建議維持同時執行控制關閉¹。若執行記錄中充滿取消狀態，原因有時就出在這項設定¹¹。

也就是說，「維持順序」與「不漏接」是互相取捨的。並行度設為 1 的序列化，對流量少、順序很重要的處理（如帳冊連號編號）有效，但不應該輕易用在尖峰時段會湧入大量事件的處理上。若順序與涵蓋率兩者都必須嚴格保證，就會進入第 8 章所述、應在 Power Automate 之外設計的領域。

7. 正式上線前的設計檢查清單

新流程要上正式環境前，至少要確認到這裡。理想上是第一天就全部到位，但為了降低導入門檻，分成「最低限度」（缺了這項就看不到事故）與「有餘裕再做」（上線後 1 個月內補齊即可）兩個層級。

#	分類	確認項目	相關章節
1	最低限度	針對失敗的 4 種分類（暫時性障礙／資料所致／驗證過期／規格變更），是否已設想過在這個流程中會發生什麼事	第 2 章
2	有餘裕再做	重試原則維持預設是否合適。若連線目標本來就會出現 429，能否減少要求數本身	第 3 章
3	最低限度	主要處理是否整合在 Try 範圍內。Catch 的執行條件設定是否同時選了「失敗」與「逾時」	第 4 章
4	最低限度	是否在 Finally 的收尾工作完成後，再依失敗旗標以 Terminate（狀態: Failed）結束，順序是否正確。是否有把失敗吞掉	第 4 章
5	最低限度	失敗通知是否自行組裝。收件人是否為共用信箱／Teams 頻道。是否與主要處理走不同路徑	第 5 章
6	有餘裕再做	通知中是否包含流程名稱、失敗動作、錯誤詳情、執行 URL	第 5 章
7	有餘裕再做	是否已決定由誰每週確認執行記錄（失敗、取消、執行次數驟減）	第 5 章
8	最低限度	即使被重新提交也安全嗎。是否用處理完成旗標或 upsert 做到冪等。是否有唯一鍵	第 6 章
9	最低限度	是否用觸發條件擋住了自我觸發或多重啟動	第 6 章
10	有餘裕再做	若要使用同時執行控制，是否理解其不可逆性與漏接風險	第 6 章
11	有餘裕再做	連線屬於誰。是否已設定共同擁有者，即使負責人不在也能重新驗證、修正	第 2 章
12	有餘裕再做	流程被自動關閉（連續失敗 14 天等）時，是否有能察覺的手段	第 2、5 章

看到有 12 項可能會覺得很多，但正式上線第一天需要的，只有「最低限度」的 6 項，而且過半是只需要考慮一次就好的項目。「有餘裕再做」的 6 項，也不代表可以放著不管，而是可以在開始運作後從容補齊的意思。反過來說，跳過這些直接上線的流程，之後想要「補做」，再加上不敢動已經在運作中的東西這種心理，往往就這樣被擱置，直到遇上事故。

8. Power Automate 該做到什麼程度

把錯誤處理徹底追究下去，就會看到超出 Power Automate 守備範圍的需求。以下列出判斷的參考標準。

情況	判斷
失敗時發送通知，由人確認後重新提交即可的業務	Power Automate 就足夠了。本文的模式已經夠用
依序更新多個系統，若中途失敗，需要把已更新的部分回滾（補償交易）	在流程中硬做容易變複雜。應整頓能統一接收處理的 API，或屬於委外開發的領域
同時要求順序保證、互斥控制、零漏接（如編號、庫存分配、會計對接等）	考量到同時執行控制的取捨（第 6 章），使用佇列或資料庫交易的開發領域較安全
必須有包含失敗行為在內的自動測試、變更歷程、審查	流程定義很難做單元測試。應轉向可用 Git 管理的 PowerShell 或 .NET
每次要處理數萬筆規模的資料，並且只想重新處理失敗的行	流程的迴圈不適合大量資料。需要批次處理的設計

判斷的感覺大致是：「只要還能用口頭說明失敗時的復原步驟，就用 Power Automate；一旦變成不畫圖就說不清楚，就進入開發領域」。尤其是需要補償交易的業務（A 公司系統已經登錄成功、B 公司系統失敗，那要不要把 A 也取消？），複雜度遠超過流程外觀所呈現的，光靠 Terminate 與通知是應付不來的。包含與工作排程器、PowerShell 的使用區分在內的判斷，已在「Power Automate 與 PowerShell、工作排程器的使用區分」中整理過。

9. 總結

「原本運作正常的流程不知不覺停了」，幾乎不是運氣不好，而是設計上的問題。流程一定會失敗。失敗的 4 種分類中，重試能照顧到的只有暫時性障礙，資料所致、驗證過期、規格變更，只能靠 Try-Catch 捕捉、Terminate 記錄、自訂通知，以及每週確認執行記錄這種多層機制來接住。預設的失敗通知郵件是有條件、附帶 28 天冷卻期的有限機制，依賴它來運作一定會發生漏接。

而應對失敗準備的核心，比起通知更是冪等性。用處理完成旗標與 upsert 做成「即使重複執行也不會壞掉」的形式，重新提交也好、觸發程序重複也好都不再可怕，復原只需要「挑出失敗的部分重新提交」即可。反過來說，需要補償交易或嚴格順序保證的業務，不要硬在 Power Automate 中建置，及早切出到開發領域，長期而言反而更划算。就在流程開始運作的那一天，不妨把這份檢查清單走一遍。

參考連結

Microsoft Learn, Limits of automated, scheduled, and instant flows. 關於預設重試原則依效能設定檔而異（Low 最多 2 次、約以 5 分鐘為單位；Medium/High 最多 12 次、從 7 秒到約 1 小時）、重試設定的上限（90 次、最小間隔 5 秒、最大延遲 1 天）、執行期間 30 天、持續失敗的流程／持續被節流的流程會在 14 天後關閉、90 天未被觸發的流程可能會被關閉、同時執行控制預設關閉且並行度為 1 到 100（開啟時預設為 25）、除非刪除觸發程序重建否則無法還原、等待執行數上限為「10＋並行度」且超出的觸發可能無法進入執行、包含重試與分頁在內的所有成功與失敗動作都會計入要求數等內容。 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹
Microsoft Learn, Reducing risk and planning for error handling. 關於自動化必定會失敗的前提、使用連接器時的失敗原因（維護導致的停止、軟體缺陷、API 版本變更）、所有自動化共通的失敗原因（密碼變更、瞬間性網路故障）、重試原則的存在等內容。 ↩ ↩²
Microsoft Learn, Handle workflow errors and exceptions in Azure Logic Apps. 關於重試原則以 408、429、5xx 回應與逾時為對象、預設為指數間隔原則、重試種類（預設／無／固定／指數）、執行條件設定（run after）的 4 種狀態（Succeeded/Failed/Skipped/TimedOut）、取消預設前必須先選擇其他狀態（必須永遠至少選取一種狀態）、可對多個前置動作分別指定狀態、範圍的狀態評估與 run after 的例外捕捉、以 result() 函式與陣列篩選抽取失敗動作（@result('範圍名稱') 與 @equals(item()['status'], 'Failed')）、result() 單一元素所具備的屬性（name、status、code、outputs、clientTrackingId 等）、分支若未以失敗結束則整體執行不會判定為失敗的狀態評估等內容。 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹² ↩¹³ ↩¹⁴
Microsoft Learn, Employ robust error handling. 關於以範圍構成 Try-Catch 模式、以執行條件設定建立失敗分支、在 Catch 範圍中以 Filter array 篩選 result()、建議使用指數重試、以 Terminate 動作設定狀態 Failed 讓執行以失敗結束、workflow() 函式傳回的 JSON 結構（name、tags.environmentName、tags.logicAppName、run 等）以及用 Parse JSON+Compose 動作組裝執行記錄 URL、過多自訂日誌會影響動作數量與效能的提醒、建議記錄錯誤日誌並發送通知等內容。 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹²
Microsoft Learn, Understand flow failure notifications. 關於以單次執行為單位的失敗警示僅限於「有已知修復方法的失敗」（連線中斷、節流等）、收件人為擁有者、共同擁有者而不含僅供執行用的使用者與管理員、同一流程有 28 天冷卻期、單次執行警示並非在所有流程上預設啟用、每週失敗摘要、可透過 Power Platform 系統管理中心的 Monitor 確認所有失敗等內容。 ↩ ↩² ↩³ ↩⁴ ↩⁵
Microsoft Learn, Missing runs or triggers history for a flow. 關於流程的執行記錄資料預設只保存 28 天、超過後就不會顯示在執行記錄頁面上等內容。 ↩ ↩²
Microsoft Learn, Troubleshoot a cloud flow. 關於修復提示（repair tips）郵件會發送給擁有者且可逐流程關閉、從 28 天的執行記錄中辨識失敗步驟的步驟、以 500/502 這類暫時性錯誤重新提交、修正流程並儲存後重新提交會依修正後的組態重新執行等內容。 ↩ ↩² ↩³
Microsoft Learn, Customize your triggers with conditions. 關於觸發條件會讓不滿足條件的事件根本不發生執行、以後段條件分支捨棄的方式仍會消耗執行次數與 API 要求等內容。 ↩ ↩²
Microsoft Learn, “There is a problem with the flow’s trigger” error shown in a flow’s run history. 關於觸發程序本身失敗會導致流程不會執行、4xx 系的觸發失敗屬於連線變更（密碼過期等）這類使用者應自行修正的問題、5xx 系則屬於暫時性系統問題等內容。 ↩
Microsoft Learn, Data policies. 關於資料原則（DLP 政策）是管理員用來控制連接器存取權限、降低組織資料意外外洩風險的防護機制、違反政策的應用程式與流程會進入中斷（suspended）或隔離狀態而無法運作等內容。 ↩
Microsoft Learn, Fix connection failures in cloud flows. 關於流程的中斷（suspended）狀態、利用執行條件設定建立失敗通知並行分支的操作步驟（從動作的「…」開啟「執行條件設定」，只選擇「失敗時」）、建議把重要流程的通知寄到共用信箱或 Teams 頻道、每週確認執行記錄（失敗、取消、執行次數驟減）、取消狀態的執行可能與同時執行設定有關、DLP 政策的變更會在毫無預警下立即生效並可能導致多個流程同時故障、服務主體連線不受密碼變更或離職影響等內容。 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶
Microsoft Learn, Tools to test your automation. 關於流程檢查工具在建立時偵測錯誤、修復提示、利用執行條件設定建立自訂錯誤通知等內容。 ↩
Microsoft Learn, Manage cloud flow run history in Dataverse. 關於解決方案對應流程的執行記錄會保存在 Dataverse 的 FlowRun 資料表中、預設保留期為 28 天且管理員可變更保留期等內容。 ↩
Microsoft Learn, Cancel or resubmit flow runs in bulk. 關於可從執行記錄一次最多重新提交、取消 20 筆、即時觸發程序中要重新提交其他使用者啟動的執行需要啟用租用戶設定（Power Automate flow run resubmission）等內容。 ↩
Microsoft Learn, Optimize Power Automate triggers. 關於觸發程序預設會同時並行執行所有滿足條件的執行、髒讀造成的不一致、同時執行控制預設為關閉、並行度設為 1 時一次只執行一個、對需要順序的處理有效、同時執行控制不可逆且建議套用在動作數少的流程（子流程）上等內容。 ↩ ↩² ↩³

共用相同標籤的最新文章。能以相近的主題延伸理解。

與本主題相關的服務

本文連結到以下服務頁面，歡迎從最接近的入口查看。

技術諮詢 & 設計審查

協助釐清設計方向、架構邊界、生命週期責任，以及既有 Windows 資產的處理方式。

查看服務聯絡我們

常見問題

整理諮詢這個主題時常見的問題。

Power Automate 的流程失敗時，會自動收到通知郵件嗎？: 只會在有限的情況下收到。以單次執行為單位的失敗警示郵件，是在判定為連線中斷、節流（throttling）等「有已知修復方法的失敗」時，才會發送給擁有者與共同擁有者，一般的動作失敗不會發送。而且一旦發送過一次，同一個流程會有 28 天的冷卻期，期間不會再收到額外的警示。以單次執行為單位的失敗警示，也並非在所有流程上都預設啟用。若要確實掌握失敗狀況，建議在 Catch 區塊中自行設計通知到 Teams 或 email 的機制。
Power Automate 的標準重試會執行幾次、間隔多久？: 當動作的要求逾時，或以 408、429、5xx 系列的回應失敗時，預設會以指數方式逐漸拉長間隔並自動重試。次數依流程的效能設定檔（實質上等同於授權層級）而異，Microsoft 365 授權等低階設定檔最多重試 2 次，Power Automate Premium 或 Process 授權等中高階設定檔最多重試 12 次。可在動作設定中將重試原則改為「無、固定間隔、指數間隔」，次數最多可設定到 90 次。像 400 或 404 這種因資料、設定造成的錯誤，不會成為重試的對象。
要如何重新執行（重新提交）失敗的流程執行？: 從執行記錄中開啟失敗的執行，選擇「重新提交」，即可用相同的觸發資料重新執行一次。若原因出在流程定義有誤，先修正流程並儲存後再重新提交，就會依修正後的內容重新執行。從執行記錄清單中，一次最多可以彙整重新提交 20 筆。要注意的是，重新提交會讓流程從頭重新執行一次，因此對於中途曾經成功過的執行，已經成功的處理也會再執行一次。必須事先做成即使重複執行也不會破壞結果的冪等設計（處理完成旗標、以更新優先於新增的寫入方式）。
流程有沒有可能在不知不覺間被停用？: 有可能。觸發程序或動作持續失敗的流程，會在 14 天後自動被關閉。持續被節流（超過限制）的流程也同樣會在 14 天後被關閉。此外，90 天內完全沒有被觸發過的流程，若不是擁有進階授權或容量授權，也可能會被關閉。放任失敗不管會直接導致流程停止，因此在維運上納入察覺失敗的機制，以及定期確認執行記錄（預設 28 天）非常重要。

作者檔案

本文作者的個人檔案頁面。

Go Komura

小村軟體有限公司代表

以 Windows 軟體開發、技術諮詢與故障調查為中心，在難以重現的故障調查與既有資產仍在運作的專案上具有優勢。

查看檔案聯絡我們

公開連結

ORCID GitHub LinkedIn X COM_BLAS COM_BigDecimal

Power Automate 的錯誤處理與重試設計 ── 防止「原本運作正常的流程不知不覺停了」