用 Power Automate 自動化業務 ── 雲端流程與桌面流程的分工，以及錯誤處理設計

「把共用資料夾裡累積的 CSV，每天早上整理成 Excel 寄給主管」「從多個業務系統手動複製貼上數值來彙總」。最近常收到想用 Power Automate 把這類作業自動化的諮詢。

最初的小型流程，通常幾十分鐘就能跑起來。麻煩的是接下來的階段。正式上線運作一段時間後，開始偶爾因錯誤而停止；只要目標系統的畫面版面稍有變動，流程就壞掉；密碼該放在哪裡遲遲沒有定案，就先直接寫進輸入變數裡暫用。明明有「能動的流程」，一旦出事卻沒有人能修——我見過好幾個案子陷入這種狀態。

Power Automate 學習成本低，能以無程式碼／低程式碼的方式快速上手。正因為這種輕鬆感，它也是一種容易把設計往後拖、就這樣直接送上正式環境運作的工具。本文將依實務上容易踩雷的順序，依序整理雲端流程與桌面流程的差異、與 PowerShell、VBA 之間的角色分工、錯誤處理、讓 UI 自動化穩定下來的思路、認證資訊的處理方式、治理與維運，以及判斷何時該超出 Power Automate 範疇的時機。

1. 先講結論

• Power Automate 大致分為 雲端流程（透過連接器串接雲端服務）與 桌面流程（自動化 Windows 畫面操作與桌面應用程式的 RPA）兩大系統。首先判斷需要哪一種，是最初的設計決策。
• 如果只是想自動化「PC 上的固定作業」，比起 Power Automate Desktop，PowerShell 往往才是優先候選。只要不是非得點擊或輸入畫面，PowerShell 通常更容易維護，也更容易納入版本管理。
• 選擇 Power Automate 最有價值的情境，是需要操作缺乏 API 整合的既有系統畫面，或是想用 Microsoft 365 的連接器（Outlook、SharePoint、Teams 等）快速建立通知、核准流程的時候。
• 要送上正式運作，就必須從一開始就把錯誤處理（On Block Error）、UI 選取器的穩定化、認證資訊的安全管理，以及以 DLP 原則進行治理這四點納入設計。事後補救是事故的根源。¹²
• 無人執行（unattended）需要與有人執行（attended）不同的授權與前提條件。如果把授權設計往後拖，就會發生驗證環境能動、正式環境卻動不起來的情況。³⁴

2. Power Automate 的整體概觀

Power Automate 與其說是單一產品，更像是把多種自動化手段整合在一起的平台。

flowchart TB
    PA[Power Automate]
    PA --> Cloud[雲端流程]
    PA --> Desktop[桌面流程 / RPA]
    PA --> Process[流程探勘]
    PA --> Builder[AI Builder]

    Cloud --> Auto[自動化流程<br/>事件觸發]
    Cloud --> Sched[排程流程<br/>定期執行]
    Cloud --> Instant[即時流程<br/>手動・按鈕啟動]
    Cloud --> Connectors[連接器<br/>SharePoint / Outlook / Teams / SQL 等]

    Desktop --> Attended[有人執行<br/>在使用者眼前執行]
    Desktop --> Unattended[無人執行<br/>於伺服器/專用PC執行]
    Desktop --> UIAuto[UI自動化<br/>畫面操作・既有應用程式整合]

• 雲端流程是透過連接器把雲端服務彼此串接起來的機制。依觸發方式不同，可分為自動化流程（事件發生時）、排程流程（定期執行）、即時流程（手動啟動）。
• 桌面流程是直接操作 Windows 上應用程式與畫面的 RPA（Robotic Process Automation，機器人流程自動化）。可以由雲端流程呼叫執行，也可以單獨執行。⁵
• 桌面流程還可再分為由人在畫面前操作執行的有人執行（attended），以及在專用 PC 或伺服器上不需人員介入即可執行的無人執行（unattended）。⁴

無人執行所謂的「專用機器」，並不是指沒被鎖定就沒問題。在 Windows 10/11 上，無論是否是用來連線的使用者，只要任何人的工作階段仍處於鎖定狀態，無人執行就會失敗。Windows Server 的範圍稍窄一些，只要用來連線的同一使用者的鎖定工作階段仍存在，就無法執行。維護作業或其他管理員透過 RDP 連線之後，常常只做「鎖定」或「中斷連線」就結束，但務必確保所有人都確實「登出」。⁶

接受諮詢時，我會先從「這是雲端服務彼此串接的問題，還是操作畫面的問題」開始切分。光是這樣做，後續的判斷就會清晰許多。

3. 雲端流程、桌面流程、PowerShell、VBA 的分工

同樣是「自動化」，各自擅長的領域卻相當不同。

實務上常見的誤解，是把「想自動化」直接等同於「總之先用 Power Automate」。用 Power Automate Desktop 去 UI 操作一個已經提供 API 的系統，本來就是直接從 PowerShell 或 .NET 呼叫 API 會更穩定的場景。反過來，若必須操作沒有 API 的舊業務系統或 Win32 應用程式的畫面，桌面流程的 UI 自動化就是現實可行的選項。

補充：關於 Excel 與 VBA 的限制與替換思路，另一篇文章「什麼是 VBA - 限制、未來走向、該被取代的情境與務實的遷移模式」也有整理，其中也談到把 Office Scripts 與 Power Automate 組合使用來處理 Microsoft 365 業務流程的模式。⁷

4. 理解授權

Power Automate 的授權大致分為以使用者為單位的授權，以及以流程為單位（Process）的授權。³

這裡容易搞混的地方在於，授權的判斷依據不是「誰建立的」，而是「如何執行」。自動化流程與排程流程會以流程擁有者的授權情境執行，而以按鈕啟動的即時流程，則會以呼叫者的授權情境執行。若要以無人執行為前提來設計，就必須在驗證階段先確認授權需求，否則會在正式環境遷移前卡關。另外，以前的「無人執行附加元件（Unattended RPA add-on）」目前已列為過往版本，改由 Power Automate Process 授權取代。既有的無人執行附加元件已被提升為與 Process 授權同等的待遇，但新指派時要使用 Process 授權。³⁸⁴

要留意的是，只有 Process / Hosted Process 授權，並不能取代使用者授權。要把 Process 授權指派給機器（無人執行所需），前提是該機器已由持有 Power Automate Premium 授權的使用者完成註冊。此外，若要從雲端流程呼叫有人執行或無人執行的桌面流程，執行時使用的連線使用者也必須擁有 Premium 授權（或含有桌面流程權利的其他授權）。若只確保了 Process 容量，卻忽略了運作所需的使用者授權，就會在功能測試階段卡住。³

5. 實務設計 ── 彙總共用資料夾的 CSV，製作 Excel 報告書並寄送郵件

以常見的「每日報表製作」為具體範例。

想達成的事

1. 收集共用資料夾中當日的 CSV
2. 彙總內容並寫入 Excel 報告書範本
3. 將報告書儲存到指定資料夾
4. 以郵件通知相關人員
5. 失敗時通知負責人，並將原因記錄到日誌中

flowchart TD
    Start([排程啟動 06:30]) --> Block[[On Block Error: 彙總處理]]
    Block --> List[List files in folder<br/>取得當日CSV]
    List --> Check{有目標檔案?}
    Check -- 沒有 --> NoticeEmpty[記錄無目標並結束]
    Check -- 有 --> Read[Read from CSV file<br/>逐一檔案迴圈]
    Read --> Agg[彙總數值・累加變數]
    Agg --> Excel[Launch Excel<br/>開啟範本]
    Excel --> Write[Write to Excel worksheet<br/>寫入彙總結果]
    Write --> Save[儲存並關閉 Excel]
    Save --> Mail[Send an email<br/>將報告書寄送給負責人]
    Mail --> Log[將執行結果追加到日誌檔]
    Log --> End([正常結束])
    Block -. 發生錯誤 .-> Handler[錯誤處理器]
    Handler --> CloseExcel[若 Excel 仍開著就關閉]
    CloseExcel --> LogErr[將錯誤內容記錄到日誌]
    LogErr --> Notify[寄送失敗通知信給管理員]
    Notify --> End2([記錄為異常結束])

主要動作與角色如下。

不要把整個流程做成一長串巨大的動作序列，而是拆成「取得檔案」「彙總」「寫入 Excel」「通知」「記錄日誌」這樣的子流程，之後修改或單獨重新執行都會更容易。由雲端流程負責排程啟動，實際處理則交給被呼叫的桌面流程，這種架構在維運上也比較好處理。⁵

6. 設計錯誤處理

Power Automate Desktop 提供 On Block Error 動作，可以以區塊（Block）為單位統一設定錯誤處理。不需要為每個動作分別設定「發生錯誤時的行為」，而是能把共同的錯誤處理套用到區塊內包含的所有動作上。¹

[On Block Error] 彙總處理區塊
  ├─ List files in folder
  ├─ Read from CSV file（迴圈）
  ├─ Launch Excel / Write to Excel worksheet
  └─ Save Excel / Close Excel

[錯誤處理器]
  ├─ 用 Get last error 動作把錯誤內容（名稱・發生位置・對應動作・詳細訊息）取得為變數
  ├─ 若 Excel 執行實例仍開著就關閉它（越是失敗時越不能省略後續清理）
  ├─ 用 Write text to file（Append）記錄到日誌
  ├─ 用 Send an email（V2）通知管理員
  └─ 選擇「從區塊最後重新開始」或「停止流程執行」

這裡有幾點需要掌握。

• 個別動作的錯誤處理，優先於區塊單位的錯誤處理，所以只想改變特定動作行為時就個別設定，其餘則統一交給 On Block Error 處理，這樣分工比較清楚。¹
• 使用「Retry action if an error occurs」，可針對暫時性錯誤（如網路延遲、檔案鎖定等），按指定次數與間隔自動重試。若把所有錯誤都設為重試對象會白白浪費時間，因此要區分該重試的錯誤與不該重試的錯誤（如資料不一致等）。¹
• 若要在錯誤處理器中參照剛才發生的錯誤內容，需要明確放置Get last error 動作。這個動作會回傳一個具有名稱・位置・對應動作・所屬子流程・詳細內容・訊息這 6 個屬性的變數，並不會自動以隱含變數的方式提供。取得後用「Clear error」選項清除，可避免之後誤用同一個錯誤值。¹
• 日誌不能只記錄「成功／失敗」，還要保留處理筆數、目標檔名、錯誤訊息。事後要調查「為什麼停下來」，唯一的線索就在日誌裡。
• 作為區塊的後續處理，要明確選擇「從區塊最後重新開始」還是「停止流程執行」。若讓 Excel 執行實例保持開啟狀態就停止，下次執行時就會殘留舊的行程，引發事故，因此發生錯誤時反而更要意識到後續清理（關閉實例）。¹¹

如果習慣 PowerShell 的 try/catch/finally，可以把 On Block Error 的「區塊」想成類似 try、錯誤處理器想成 catch、後續清理的處理序列想成 finally，這樣設計起來會更容易理解。

7. 讓 UI 自動化穩定下來

桌面流程變得不穩定的最大原因，多半出在「UI 元素的識別方式（選取器）」上。

• 預設情況下，UI 元素選取器（UI element picker）會把畫面元素記錄為 選取器（屬性的組合）。若其中包含容易受應用程式版本升級、顯示內容變化影響的脆弱屬性（如連續編號索引、動態 ID 等），即使畫面外觀相同，流程也會壞掉。¹²
• 把會變動的屬性從 Equals 改成 Contains 或正規表達式，並把依賴前一個動作結果的值改為變數化，就能做出更動態、更不容易壞掉的選取器。¹²
• 事先設定多個選取器，當第一個選取器失敗時，就會自動退回使用下一個選取器。針對重要的操作準備備用選取器，能提升穩定性。¹²
• 選取器壞掉時，可以用 Repair selector 功能自動產生修復候選方案。在手動從頭重做之前，值得先試試這個功能。¹²
• 畫面切換與應用程式啟動之間存在時間差。不要只依賴固定的 Wait，要搭配「等待視窗」「等待直到找到 UI 元素」這類條件式等待動作，同時也要設定當找不到 UI 元素時的自動重試。¹³
• 對於怎麼都無法穩定下來的自動化對象（虛擬化畫面、版面經常變動的畫面等），不要死守 UI 操作，應先確認是否有 API、檔案整合、資料庫存取等更穩定的整合方式可用。

讓 UI 自動化第一次動起來本身並不難。半年後是否還能不壞地持續運作，幾乎完全取決於選取器的建立方式。

8. 安全處理認證資訊

業務自動化中最容易發生事故的，就是認證資訊（密碼、API 金鑰、連線字串等）的處理。

• 避免把密碼或連線資訊直接以數值寫進流程的輸入變數中。使用Get credential 動作，可以從以 Azure Key Vault 或 CyberArk 作為後端機密庫的「Power Automate 認證資訊」中安全取得認證資訊，取得的值會被標記為機密資訊，也不會留在流程的執行日誌裡。¹⁴¹⁵
• 若把 Azure Key Vault 當作機密的儲存位置，就能在 Power Automate 端把連接 Key Vault 的資訊集中管理在一處，不必讓認證資訊分散到每個流程中。¹⁵
• 無人執行用的帳戶，應準備一個使用範圍限縮到必要最小限度的專用帳戶，不要跟人員日常使用的帳戶共用。帳戶擁有的權限越廣，流程的缺陷或設定錯誤所波及的範圍也就越大。
• 若以「先讓它動起來」為理由，暫時把密碼以明文寫進輸入變數並就此進行驗證，這種做法很容易就這樣一直殘留到正式環境。從驗證階段起就養成使用 Get credential 動作的習慣會更安全。

9. 治理與維運

當個人或團隊各自建立的流程逐漸增多，接下來就需要組織層級的統一管理。

• 資料防遺失（DLP）原則是把流程或應用程式可用的連接器分類為「僅限業務資料」「不可用於業務資料」「封鎖」等類別，避免業務資料用連接器與不可用於業務資料的連接器在同一個流程內組合使用的機制。這是防止組織資料在無意間外流到外部服務、最應優先建立的治理措施。¹⁶
• 桌面流程的動作，也能在同樣的 DLP 原則框架下分類與封鎖，但這項功能預設並未啟用。必須在 Power Platform 管理中心的租用戶設定中，一次性開啟「Show desktop flow actions in DLP policies」，而且這項設定之後無法還原。啟用之後，也只有在原則中明確分類過的模組與動作才會受到控管，因此要注意「建立了 DLP 原則」並不等於「整個桌面流程都已受到統一管理」。²
• 無人執行用的機器，應以機器群組的方式集中管理，並明確掌握哪個流程會在哪台機器上執行。
• 執行紀錄可以從 Power Automate 的管理畫面／執行歷程中查看。若把失敗時的警示（Teams 通知或郵件通知）內建到流程本身的處理中，就不需要有人手動去查看，也能察覺異常。
• 若想從雲端流程存取企業內部網路中的資料庫或檔案共用等雲端無法直接存取的地端資源，可以使用地端資料閘道。閘道不需要在雲端側開放接收埠，僅透過對外連線方向就能安全地橋接資料。¹⁷
• 把驗證用與正式用的環境分開，依環境切分桌面流程與連線資訊，可以避免驗證中的變更影響到正式環境的流程。

10. Power Automate 的極限與升級判斷基準

Power Automate 雖然強大，但並非萬能。遇到下列狀況時，應考慮切換為 PowerShell 或 .NET 應用程式。

當你覺得「用 Power Automate 做出來的東西長大到過於複雜」時，比起硬撐著繼續擴充流程，把核心處理抽出到 .NET 或 PowerShell，讓 Power Automate 只專心負責觸發與通知的架構，結果往往更容易維護。用 PowerShell 進行日誌調查、封存自動化的實際案例，另一篇文章「PowerShell 腳本應用 ── 安全地自動化日誌調查、封存與報表化」中也有介紹。

11. 結語

Power Automate 到踏出第一步為止，簡單得令人驚訝。然而這種輕鬆感反過來看，也意味著「即使省略設計也能先動起來」。上線之後的流程能否長期維護下去，幾乎完全取決於最初做了多少看似不起眼的判斷。

該用雲端流程還是桌面流程，哪些處理適合交給 PowerShell 或 .NET。先把這個判斷做好，之後的返工就會大幅減少。錯誤處理、UI 選取器、認證資訊、授權、DLP 原則，這些「一開始就內建進去」都遠比「先動起來再修正」的成本低得多。而當流程長大變複雜時，能否不硬撐擴充、而是把處理轉移到 .NET 或 PowerShell，也左右著這套自動化能否長久使用下去。

「先能動起來的流程」與「能安心託付的流程」之間，就存在著這麼多的設計差距。越是牽涉到既有業務系統或 Excel / VBA 資產的自動化，最初的設計判斷就越會大幅左右後續的維護成本。

相關文章

• 什麼是 VBA - 限制、未來走向、該被取代的情境與務實的遷移模式
• PowerShell 腳本應用 ── 安全地自動化日誌調查、封存與報表化
• Excel 報表輸出該怎麼做 - COM 自動化 / Open XML / 範本方式的判斷表

相關諮詢領域

合同會社小村軟體提供在保留既有 Excel / VBA / Windows 業務資產的前提下，逐步進行自動化與現代化的諮詢，以及包含 Power Automate 的自動化基礎架構設計審查。

• 既有資產活用・遷移支援
• 技術諮詢・設計審查
• Windows 應用程式開發
• 聯絡我們

參考連結

相關文章

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

相關主題

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

與本主題相關的服務

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

常見問題

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

雲端流程與桌面流程該如何分工？

雲端流程是透過連接器把雲端服務彼此串接起來的機制，適合核准流程、通知、SaaS 整合，以及 Microsoft 365 周邊的業務流程。桌面流程則是直接操作 Windows 上應用程式或畫面的 RPA，是沒有 API 的舊業務系統，或需要操作 Win32 應用程式畫面時的現實選擇。接受相關諮詢時，先切分「這是雲端服務互相串接的問題，還是操作畫面的問題」，會讓後續判斷清晰許多。

Power Automate 和 PowerShell 該用哪一個？

如果只是想自動化 PC 上的固定作業，且不是非得點擊或輸入畫面不可，PowerShell 通常更容易維護，也更容易納入 Git 版本管理。已經提供 API 的系統，用 UI 操作本來就不如直接呼叫 PowerShell 或 `.NET` 的 API 來得穩定。數十萬行規模的資料處理、需要自動測試的複雜邏輯，以及高頻率的常駐處理，也都適合交給 PowerShell 或 `.NET`。當流程變得太複雜時，把核心處理抽出來，讓 Power Automate 只專心處理觸發與通知，會讓整體更容易維護。

Power Automate 的無人執行需要什麼授權？

無人執行需要與有人執行不同的授權，要用把授權綁定在流程或機器上的 Power Automate Process 授權。以前的無人執行附加元件現已列為過往版本，改由 Process 授權取代。此外，只有 Process 授權並不能取代使用者授權，機器的註冊仍需要一位持有 Power Automate Premium 授權的使用者。再者，在 Windows 10/11 上，只要有任何人的工作階段仍處於鎖定狀態，無人執行就會失敗，因此必須讓所有人都登出。

桌面流程的 UI 自動化為什麼會不穩定？

最大的原因多半出在 UI 元素的識別方式（選取器）上。只要包含連續編號索引或動態 ID 這類容易變動的屬性，即使畫面外觀相同，流程也會壞掉。對策是把會變動的屬性從 Equals 改成 Contains 或正規表達式，設定多個選取器做備援，壞掉時再用 Repair selector 功能產生修復候選。不能只依賴固定的 Wait，也要搭配條件式等待的動作。半年後是否還能穩定運作，幾乎完全取決於選取器的建立方式。

作者檔案

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

Go Komura

小村軟體有限公司 代表

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