用 Power Automate 打造核准流程 ── 將紙本與電子郵件的簽呈、申請電子化

「把簽呈印出來、蓋章、傳到隔壁部門，等它送回來已經是一星期後」「把 Excel 申請書當附件寄出去，核准就靠回信裡的『OK』兩個字」。已導入 Microsoft 365 的公司經常前來諮詢，希望能想想辦法解決這類申請・核准業務。

Power Automate 有一套稱為核准（Approvals）的專用機制，通常只要在 Teams 或 Outlook 上按下核准按鈕，就能在不增加額外費用的授權範圍內建立核准流程。不過，第一個流程能動起來，與能夠放心地當作業務長期運作，兩者之間存在距離。核准的記錄會留存在哪裡？核准者放著不管會發生什麼事？承辦人離職後，流程要由誰來修？本文將整理核准流程的基本組成、實務上容易踩雷的設計要點，以及該由 Power Automate 負責到什麼範圍為止的界線。

1. 先講結論

• Power Automate 的核准，基本上就是 「開始並等待核准」動作。核准的種類可以從「需要所有人核准」「最先回應」「自訂回應（等待所有人／等待 1 人）」「依序核准」共 5 種之中選擇。¹
• 核准者可以在 Teams、Outlook、Power Automate 入口網站、行動應用程式中任何一處回應。幾乎不需要讓核准者特地學習一個新畫面的操作方式。²³
• 申請的受理窗口，現實可行的選項是 Microsoft Forms／SharePoint 清單／Teams 的核准應用程式這 3 種。若想事後彙整、統計，以 SharePoint 清單為主軸是標準做法。
• 流程的執行歷程預設只能看到 28 天，單次執行最長 30 天就會逾時。 核准的稽核軌跡不要仰賴執行歷程，一開始就要把結果寫回 SharePoint 清單等處的設計納入其中。⁴⁵
• 流程擁有者的離職、調動，是核准流程最大的運作風險。共同擁有者的設定與連線的處理方式，要在流程開始運作的當天就先完成。⁶
• 若想把條件分支眾多的多層核准、代理決行，或稽核要求嚴格的簽核規範原封不動地實作出來，Power Automate 就會維護不了。這種情況屬於工作流程系統或委外開發的範疇。

2. 紙本・郵件簽呈的問題出在哪裡

紙本簽呈或郵件附加 Excel 的核准之所以令人痛苦，與其說是手續本身麻煩，不如說是「看不見狀態」。從承接的諮詢案例來看，共通的問題大致有以下 3 個。

• 不知道現在卡在哪裡。簽呈放在誰的桌上、郵件埋在哪個收件匣裡，申請人本人根本看不見。催辦只能靠口頭或電話，被催辦的一方心情也不會好。
• 記錄分散。核准的稽核軌跡分散在紙本檔案櫃與個人信箱之中。要在稽核或事後查詢時追查「那件申請是誰在何時核准的」，就得去翻找別人的信箱。承辦人一旦離職，連同信箱一起消失。
• 追不到退回紀錄。若拒絕或修改要求是靠口頭或郵件進行，就會搞不清楚是針對哪個版本的申請書所提出的指摘。重新送出修改版之後，又要從頭開始傳閱一次。

這些問題，只要「把申請的狀態與記錄集中在一處」，幾乎都能解決。而且只要已經導入 Microsoft 365，存放的地方（SharePoint）、通知的管道（Teams／Outlook）、自動化的工具（Power Automate），其實都已經在手邊了。

3. Power Automate 核准的基本組成

「開始並等待核准」動作

核准流程的核心，是核准（Approvals）連接器的 「開始並等待核准（Start and wait for an approval）」 動作。只要指定核准要求的標題、詳細內容、核准者，流程就會在此暫停，等待核准者回應後，才會進入下一個動作。¹

核准的種類共有 5 種。¹

使用自訂回應，就能不侷限於「核准」「拒絕」二選一，而是定義出「核准」「退回」「保留」這類選項。這會成為後面要說明的退回迴圈的組成部件。

另外，要使用核准功能，需要 Microsoft Dataverse 的資料庫。核准要求與回應的記錄會保存在 Dataverse 中，在預設環境中，第一次建立核准流程時就會自動準備好，因此通常不需要特別意識到它的存在也能開始使用。核准連接器屬於標準連接器，所以能用能使用標準連接器的授權（Office 365 等）建立核准流程。¹

Dataverse 是什麼 ── 什麼時候需要留意它

這裡第一次出現的 Dataverse（資料庫），是 Power Platform 共通的資料儲存基礎架構。簡單來說，它是準備在自家 Microsoft 365 租用戶內的雲端資料庫，用來存放 Power Apps 應用程式與流程所處理的資料。核准功能就建立在它之上，「向誰、在何時要求核准，誰又做出了什麼回應」，會以記錄的形式寫入 Dataverse 的資料表中。

日常的建立與運作中，幾乎不需要特別意識到 Dataverse 的存在，但以下 3 種場合會讓它浮上檯面。

• 在新環境中第一次使用核准功能時。若是預設環境會自動準備好，但在為部門新建立的環境中，就需要確認是否已有 Dataverse 資料庫。¹
• 核准歷史累積起來的時候。核准歷史會消耗環境的儲存空間，可能因容量考量而成為刪除的對象。這正是稽核軌跡不該仰賴執行歷程、也不該仰賴 Dataverse 的原因（詳見下一章）。⁷
• 想直接讀寫核准記錄的時候。若構建成用 Dataverse 連接器直接操作資料表的架構，該連接器屬於進階層級，就會牽涉到追加授權的問題。⁸

換句話說，界線就在於「普通地使用核准功能不需要追加授權，但一旦開始直接碰觸 Dataverse 本身，情況就不一樣了」。

核准者要從哪裡回應

核准要求會透過電子郵件與 Power Automate 行動應用程式送達核准者。³ 在 Outlook 中會收到排版過的核准郵件，可以直接從那裡回應。⁹ 寄給個人使用者的核准也會通知到 Teams，可以從 Teams 的聊天或核准應用程式進行核准、拒絕、輸入留言。² 不需要讓人「為了核准而特地登入專用網站」，這正是核准流程能夠推廣普及的最大推力。

有一點需要留意。若核准對象設為 Microsoft 365 群組，就不會發送 Teams 通知。只有寄給個人使用者的核准，才會收到 Teams 通知。¹⁰

流程整體樣貌

以採購申請為例，整體會呈現這樣的形狀。

flowchart TD
    Submit[申請人輸入<br/>透過 Forms 送出或登錄到 SharePoint 清單] --> Trigger[雲端流程啟動<br/>新回應・新增項目觸發程序]
    Trigger --> Record[將申請內容記錄到 SharePoint 清單<br/>狀態－等待核准]
    Record --> Approval[開始並等待核准<br/>向核准者送出要求]
    Approval -- Teams / Outlook / 行動裝置 --> Response{回應}
    Response -- 核准 --> UpdateOK[將清單狀態更新為「已核准」<br/>把核准者・日期時間・留言記錄到欄位]
    Response -- 拒絕/退回 --> UpdateNG[將狀態更新為「退回」<br/>把理由通知申請人]
    Response -- 逾時 --> Remind[催辦通知 / 上呈]
    UpdateOK --> NotifyOK[通知申請人結果]
    UpdateNG --> Resubmit[申請人修改後重新申請]
    Resubmit -- 以觸發條件<br/>僅在「重新申請」時啟動 --> Trigger

重點在於，於核准動作的前後都夾入「記錄」這個步驟。理由會在第 5 章說明。

4. 申請的受理窗口該如何設計

核准流程好不好用，與其說取決於核准端，不如說是由申請端的輸入受理窗口所決定。現實可行的選項有 3 個。

判斷的參考標準如下。

• 若單純只想把每次臨時的核准電子化，不必建立流程，用 Teams 的核准應用程式就夠了。核准應用程式是可以直接從聊天當場送出核准要求的功能，雖然運作在 Power Automate 的基礎架構之上，但不需要建立流程。¹¹
• 若是取代申請書，以 Forms 作為受理窗口，由流程接收回應後轉交核准，是最快的做法。系統也提供了把 Forms 的回應內容帶入核准要求的範本。¹³
• 若想作為申請台帳管理，就以 SharePoint 清單為主軸。即使以 Forms 作為入口，只要在流程一開始就把回應轉錄到清單中，就能透過狀態欄位（等待核准／已核准／退回）與檢視，讓任何人都能看到「現在卡在哪裡」。開頭提到的紙本・郵件簽呈課題的答案，實質上就在這裡。

若想以小規模的方式開始，「用 Forms 受理、記錄到 SharePoint 清單、核准結果也寫回清單」的架構，能同時兼顧輸入的便利性與台帳管理，是比較好處理的方式。

5. 實務上有效的設計要點

核准記錄該留在哪裡 ── 不要仰賴執行歷程

這是最重要的設計判斷。流程的執行歷程，預設只會顯示 28 天。⁴ 若是納入解決方案的流程，可以把執行歷程的中繼資料保留在 Dataverse 中，但這邊的預設保留期同樣是 28 天，是由管理員調整保留期限的機制。¹⁴

換句話說，靠執行歷程事後查「誰在何時核准」這種運作方式，一個月就會破功。核准要求・回應的記錄本身雖然會保存在 Dataverse 中¹⁵，但每次稽核因應或日常查詢都去翻 Dataverse 的資料表並不現實，而且核准歷史會消耗環境的儲存空間，有時也會因容量考量而成為刪除的對象。⁷

實務上，一定要在核准動作結束後緊接著加入把結果・核准者・回應日期時間・留言寫回 SharePoint 清單欄位的步驟。「開始並等待核准」動作會把回應、核准者、留言作為輸出回傳¹⁵，因此只要原封不動地記錄到欄位即可。申請與核准記錄會對齊在同一份清單的同一列，保留期限則可依清單的營運方式，保留多久都可以。

有一點需要留意。像「需要所有人核准」或自訂回應（所有人）這類多位核准者的種類，回應（Responses）會以人數份的陣列形式回傳。³ 若把這些依序覆寫到同一組欄位，就只會留下最後一筆回應，因此多位核准者的記錄，應該設計成每個回應各自往歷史用清單新增一列，或是先把所有人的回應整理成一段文字後，再記錄到欄位。

逾時與提醒 ── 無法建立「沒有期限的核准」

雲端流程單次執行最長為 30 天。這 30 天內也包含了核准等待這類保留中的步驟，一旦超過 30 天，保留中的步驟就會逾時。⁵ 若核准者放著不管，流程就會默默地以失敗告終。若不了解這一點就開始運作，就會發生「明明已經申請了卻什麼都沒發生」這種最傷信任的事故。

對策分為兩個階段。

1. 在核准動作明確設定逾時時間。 在動作的設定中，以 ISO 8601 格式（例如 P3D 代表 3 天）指定逾時時間，並在 執行條件設定 中準備「逾時時」的分支。¹⁶ 這裡要留意的是，逾時的當下，原本的核准等待就已經結束。之後即使核准者做出回應，也不會流向這次執行的後續步驟（例如結果的寫回）。也就是說，逾時分支不是「一邊繼續等待一邊催辦」的地方，而是「先打斷一次、再採取下一步行動」的地方。若要催辦，就在逾時分支發送通知的同時，重新發出新的核准要求。
2. 可能超過 30 天的核准，把流程拆成兩個。 官方指引的做法，是用「建立核准（v2）」動作只送出核准要求，第一個流程就此結束，回應之後的處理則由另一個流程進行。由於核准記錄存放在 Dataverse 中，即使第一個流程的執行已經結束，回應仍然可以被處理。若想在不打斷等待的情況下組出更靈活的催辦機制，這種雙流程架構也更容易做出來。¹⁷ 另外，第二個流程的啟動方式仍有設計空間；若構建成用 Dataverse 連接器的觸發程序直接抓取核准資料表的變更，請留意 Dataverse 連接器屬於進階授權的對象（核准連接器本身的動作仍在標準範圍內¹）。⁸

逾時與分支的設定步驟

這部分光用文字說明不容易理解，這裡依序列出在設計工具上的操作。

1. 從「開始並等待核准」動作卡片右上角的「…」開啟 設定（Settings），在 逾時（Timeout） 欄位輸入 ISO 8601 格式的期間。3 天就填 P3D，12 小時就填 PT12H。若留空，就會一直等到流程執行期間的上限（30 天）。
2. 在核准動作下方，放置 1 個逾時時要執行的處理動作（例如催辦通知）。
3. 從該動作卡片右上角的「…」開啟 執行條件設定（Configure run after），針對前一個核准動作，只勾選「已逾時」。因為預設是「已成功完成」，請不要忘記取消勾選這一項。
4. 核准通過時的處理（寫回結果・通知申請人），則作為核准動作的另一個分支並排放置，這邊維持「已成功完成」不變。透過執行條件設定分岐之後，在設計工具上會並列顯示 2 個分支。

「3 天催辦，7 天呈報上級」的做法

這應該是大家最想做出來的部分，這裡具體示範串接 2〜3 段的架構。第 1 段等待 3 天，若無回應就催辦並重新發給同一位主管，再過 4 天後轉給上一層核准者。

flowchart TD
    A1[開始並等待核准 第1段<br/>核准者－直屬主管<br/>設定的逾時 P3D] --> Q1{是否有回應}
    Q1 -- 核准・拒絕 --> Rec[將結果寫回 SharePoint 清單<br/>通知申請人]
    Q1 -- 3天內 無回應 --> R1[發送催辦通知<br/>執行條件設定－已逾時]
    R1 --> A2[開始並等待核准 第2段<br/>核准者－同一位主管<br/>設定的逾時 P4D]
    A2 --> Q2{是否有回應}
    Q2 -- 核准・拒絕 --> Rec
    Q2 -- 再過4天 無回應 --> R2[發送上呈通知<br/>執行條件設定－已逾時]
    R2 --> A3[開始並等待核准 第3段<br/>核准者－上一層核准者<br/>未設定逾時]
    A3 --> Rec

製作時的要點有 3 個。

• 第 2 段、第 3 段是「新的核准要求」。 第 1 段的要求已經在 3 天後結束，因此會以另一筆要求的形式，送達核准者的 Teams 或 Outlook。在要求標題加上「【催辦】」「【呈報上級】」，並在內文中放入申請日與經過天數，收到的人就能理解目前的狀況。
• 把逾時時間的總和控制在流程 30 天以內。 上面的例子第 1 段用了 3 天、第 2 段用了 4 天，共用掉 7 天，因此第 3 段剩下的餘裕不到 23 天。段數增加得愈多，第 3 段的餘裕就愈少。
• 若想把結果的寫回統一在一處，就使用變數。 核准的結果每一段都是不同動作的輸出，若照原樣書寫，寫回的步驟就會增加到 3 處。在流程開頭先初始化字串變數（例如 核准結果）與 核准者，在每一段的核准動作之後各放置 1 個「設定變數」，最後統一寫回清單一次，之後的維護會輕鬆許多。

把「逾時→催辦→重新要求」用 Do until 迴圈捲起來的做法也做得出來，但 Do until 另外還有一個迴圈本身的上限（預設 60 次・1 小時），若要在裡面放入核准等待這種長時間的動作，若不透過「變更限制」明確延長迴圈的逾時時間，第 1 輪結束後就不會進入第 2 輪。⁵¹⁸ 這個「變更限制（Change limits）」是位於 Do until 動作卡片內的連結，開啟後可以指定 計數（Count） 與 逾時（Timeout） 這 2 項。計數是反覆次數（預設 60），逾時是以 ISO 8601 書寫整個迴圈限制時間的欄位（預設 PT1H）。若想讓等待 3 天的核准跑 3 輪，就把計數設為 3，逾時設為 P10D 這樣「比預期的總輪替時間更長的值」。不過就算延長這裡的值，流程整體的 30 天上限也不會跟著延長。

若是中小企業的簽呈，現實可行的做法，是先訂出「3 天催辦、7 天呈報主管」這類的內部規則，再用重新要求迴圈或雙流程架構把它實作出來。

不在時的重新指派

核准者長期不在的情況一定會發生。收到核准要求的本人，可以從 Power Automate 入口網站的核准清單，把要求重新指派（Reassign）給其他人。另一方面，若要由發出要求的一方重新處理，步驟則是取消要求、變更核准者後再重新執行。⁹ 要留意的是，在本文這種自動啟動的流程中，這會是流程擁有者一方的工作，而不是申請人的工作。因為核准要求是從流程連線所使用的帳戶送出的，變更核准者需要流程的編輯權限。「核准者請假時要由誰來修流程」，必須與下一章共同擁有者的內容一併事先決定好。

不過，重新指派的前提是「由收到要求的本人親自操作」，因此對突發的請假等情況起不了作用。作為長期性的因應措施，比較安全的做法，是不把核准者固定在單一一人，而是用分號分隔指定多人，設計成「最先回應」型，或是改成寄給群組。⁹ 由於寄給群組有不會發送 Teams 通知的限制¹⁰，若重視通知的確實性，就選擇指定多人的做法。

拒絕時的退回迴圈

紙本簽呈中最難追蹤的「退回→修改→重新申請」，只要設計中具備狀態欄位，就能直接了當地表達出來。基本形式如下。

• 用自訂回應定義「核准」「退回」¹
• 若為退回，就把清單的狀態欄位設為「退回」，把核准者的留言記錄到欄位並通知申請人
• 申請人修改清單項目，把狀態改為「重新申請」（或是從 Forms 重新送出）
• 以項目更新作為觸發程序，流程再次執行，重新進入核准

這種形式有一點需要留意，就是流程自己寫回的動作，會讓流程再次啟動。若原封不動地使用「項目建立或變更時」的觸發程序，流程把狀態欄位更新為「等待核准」或「已核准」的瞬間，這次更新本身就會滿足觸發條件，引發重複的核准要求或無限迴圈。雲端流程可以觸發自己本身，Power Automate 在儲存時也會對可能發生無限迴圈提出警告。¹⁹ 對策不是在後段用條件分支捨棄，而是在觸發程序這一側，用觸發條件（trigger conditions）寫成「只有在狀態欄位為『重新申請』（或新建立）時才啟動」。不滿足觸發條件的更新，根本不會發生流程執行，因此也不會消耗執行次數。²⁰

觸發條件的設定方式，是從觸發程序卡片右上角的「…」開啟 設定（Settings），在 觸發條件（Trigger Conditions） 中逐行寫入以 @ 開頭的運算式。若只想在 SharePoint 清單的選項欄位 ApprovalStatus 為「重新申請」時才啟動，就會像這樣。

@equals(triggerOutputs()?['body/ApprovalStatus/Value'], '重新申請')

若也想在新建立時（狀態欄位為空）啟動，就用 or 把兩者綁在一起。

@or(equals(triggerOutputs()?['body/ApprovalStatus/Value'], '重新申請'), empty(triggerOutputs()?['body/ApprovalStatus/Value']))

撰寫時要掌握的重點有 3 個。

• @ 只在開頭寫一次。 內部巢狀的 equals、empty 不需要加上它。
• 選項欄位要指定到 /Value。 因為選項欄位回傳的是物件而不是字串，若只用 body/ApprovalStatus 比對是不會相符的。若是單行文字欄位則不需要 /Value。
• 避免在欄位名稱中使用中文。 SharePoint 若在欄位名稱使用中文，內部名稱就會變成類似 _x72b6__x614b_ 這種編碼字串，即使在運算式中直接寫顯示名稱也不會相符。先用英數字的名稱建立流程要參照的欄位，之後再把顯示名稱改成中文，就能避免在這類運算式上消耗心力。內部名稱可以在清單設定的欄位詳細頁面網址（Field= 後方）確認。

修改記錄會留在清單的版本歷程中，因此「是針對哪個版本的指摘」混淆的問題也能解決。雖然也可以在流程內組出 Do until 迴圈、在一次執行中反覆進行退回，但 30 天的執行期間限制同樣會把退回往返的時間算進去，因此每次退回就結束執行、以重新申請開始新的執行這種設計比較安全。

6. 運作與治理 ── 不要讓流程成為「製作者個人的東西」

核准流程會深入業務的核心，一旦變成只有特定人員才懂的黑箱，影響就會很大。至少要在流程開始運作的第一天，就完成以下 2 點。

• 設定共同擁有者。 流程的擁有者，能做到確認執行歷程、編輯・停止流程，甚至更新連線的認證資訊。若一直只有建立者 1 人，一旦這個人離職或調動，流程就會變成沒有人能修的東西。請把資訊系統的承辦人員或接任人選加入為共同擁有者。另外，也有一種功能可以把 SharePoint 清單本身設為共同擁有者，讓「擁有清單編輯權限的人＝能編輯流程的人」保持一致⁶，但若在本文這種所有申請人都會寫入的受理清單上這麼做，就會變成把流程的編輯權限交給了所有申請人。核准流程請不要使用這個做法，共同擁有者要限定在負責運作的承辦人員個人，或管理員專用的群組。
• 事先理解連線的處理方式。 流程所使用的連線（對 SharePoint 或 Outlook 的驗證），會綁定在建立它的使用者身上，共用出去的連線也只能在該流程內使用。而且共同擁有者無法變更其他擁有者所建立的連線認證資訊。⁶ 核准結果的通知郵件持續從「已離職者的帳戶」寄出、帳戶停用的同時流程就停止運作，這類事故就是從這裡發生的。通知與寫入所要使用的帳戶該怎麼安排，是在建立流程之前就該決定好的論點。

另外，即使要讓其他部門也使用這個流程，也不需要把流程共用給申請的人。以本文的架構來說，只要能在受理窗口（Forms 或 SharePoint 清單）輸入，流程就會自動啟動。共用的對象要限縮在參與編輯・運作的人，共同擁有者則以必要最小限度為原則。²¹

有關授權、環境隔離、DLP 原則這類 Power Automate 整體的治理，已經在另一篇文章「用 Power Automate 自動化業務 ── 雲端流程與桌面流程的分工，以及錯誤處理設計」中整理過。核准流程也是雲端流程的一種，因此同樣的思路可以直接套用。

7. Power Automate 該做到什麼地步

Power Automate 的核准功能很強大，但並不是能把簽核規範原封不動實作出來的工具。以下列出判斷界線的參考標準。

判斷的感覺大致是這樣：「當流程的分支畫在紙上、已經放不進 A4 大小的紙張時，就已經開始超出 Power Automate 的守備範圍了」。與其硬撐著把流程養大，不如只把核准路徑的判斷邏輯搬到外部（Dataverse 的資料表或另一套系統），或是判斷改用專用系統，結果通常反而比較省錢。

此外，核准流程的電子化，也經常成為重新檢視與公司外部之間紙本・傳真往來的入口。內部的簽呈電子化之後，接下來可以考慮的候選項目，就是傳真接單或請款單的往來。這方面的內容，我們在「把 FAX 收單搬到網路上 ── 雙軌並行期的設計與分階段轉移實務」與「什麼是 EDI？如何讓企業間的訂購作業更輕鬆 ── 從傳真、電子郵件、手動輸入邁向資料連動」中處理過。

總結

紙本與郵件簽呈真正的問題，並不是麻煩本身，而是「看不見狀態・記錄分散・追不到退回紀錄」這 3 點。Power Automate 的核准流程，透過「把申請與核准記錄集中到 SharePoint 清單，核准的操作則在 Teams／Outlook 完成」的形式，解決了這 3 個問題。而且大多數情況下不需要額外投資新系統就能開始，對已經導入 Microsoft 365 的公司來說，這是一大優勢。

另一方面，若不了解執行歷程 28 天、執行期間 30 天這些限制就動手製作，做出來的就會是「稽核軌跡會消失」「申請默默失敗」的核准流程。結果的寫回、逾時分支、多位核准者、共同擁有者──只要一開始就把這 4 點納入設計，核准流程就能長期安心地運作下去。而當你開始想把簽核規範的複雜度原封不動實作出來時，那就是該考慮專用系統或委外開發的時機了。

相關文章

• 用 Power Automate 自動化業務 ── 雲端流程與桌面流程的分工，以及錯誤處理設計
• 把 FAX 收單搬到網路上 ── 雙軌並行期的設計與分階段轉移實務
• 什麼是 EDI？如何讓企業間的訂購作業更輕鬆 ── 從傳真、電子郵件、手動輸入邁向資料連動
• 什麼是數位發票（Digital Invoice）？──與「把請款單 PDF 寄送 email」有何不同

相關諮詢領域

合同會社小村軟體，可提供從善用 Microsoft 365 的業務流程電子化諮詢，到 Power Automate 難以應付的核准・報表需求系統化在內的服務。

• 技術諮詢・設計審查
• Windows 應用程式開發
• 聯絡我們

參考連結

相關文章

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

相關主題

與本文相近的主題頁面。以本文為起點，可進一步連到相關服務與其他文章。

與本主題相關的服務

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

常見問題

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

Power Automate 的核准流程只靠 Microsoft 365 的授權就能製作嗎？

可以。核准（Approvals）連接器屬於標準連接器，因此只要擁有能使用標準連接器的授權（如 Office 365 等），就能建立核准流程。不過核准資料的儲存位置需要 Microsoft Dataverse 的資料庫，在預設環境中，第一次建立核准流程時會自動準備好。與 SharePoint 清單、Forms、Teams、Outlook 的組合，也都能在標準連接器的範圍內完成配置。

核准者若放著不回應會發生什麼事？

雲端流程單次執行最長為 30 天，等待核准這類保留中的步驟，超過 30 天同樣會逾時。因此無法建立『沒有期限的核准』。實務上會在核准動作明確設定逾時時間，並在『執行條件設定』中準備『逾時時』的分支。逾時之後，原本的核准等待就已結束，之後核准者的回應不會再流向後續步驟，因此這個分支的設計，應該是在發送催辦通知的同時重新發出新的核准要求（依重複次數呈報給上一層核准者）。若需要等待超過 30 天，就把流程拆成兩個：一個流程用『建立核准（v2）』動作只負責送出核准要求，另一個流程負責處理回應。

核准的記錄會留存在哪裡？可以用於稽核嗎？

核准要求與回應會以記錄的形式保存在 Microsoft Dataverse 中，而流程本身的執行歷程預設只會顯示 28 天。若稽核或事後查詢仰賴執行歷程，是很危險的做法。實務上建議的設計，是在流程最後把核准結果、核准者、核准日期時間、留言寫回 SharePoint 清單的欄位，讓申請資料與核准記錄能在同一處一覽無遺。

核准者不在或離職時該怎麼辦？

收到核准要求的本人，可以從 Power Automate 的核准清單，將要求重新指派（Reassign）給其他人。提出要求的一方無法重新指派，但可以取消要求、變更流程的核准者後再重新執行。若要因應長期不在的情況，不要把核准者固定在單一一人，而是設計成同時發送給多名核准者或群組，會比較不容易卡住。為了因應流程擁有者本人離職的情況，一開始就設定共同擁有者也同樣重要。

作者檔案

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

Go Komura

小村軟體有限公司 代表

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