Power Automate 與 PowerShell + 工作排程器的分工 ── 不混用自動化工具，各就各位地串接

「會計伺服器上，PowerShell 的夜間批次作業已經運作將近 10 年。另一方面，最近現場的承辦人員開始用 Power Automate 建立申請流程與通知流程。明明同樣是『自動化』，做法和存放的地方卻完全不同，這兩套系統在公司內部愈來愈多，已經搞不清楚新的自動化該用哪一種來做，甚至不知道到底有沒有人掌握全貌」。最近常從已導入 Microsoft 365 的中小企業那裡聽到這類諮詢。

PowerShell + 工作排程器與 Power Automate，雖然都是「自動執行既定作業」的工具，但擅長的領域幾乎沒有重疊。正因為不重疊，硬要統一到其中一邊會很吃力，而不劃定界線就混用，只會拼湊出難以維護的東西。本文將先整理兩者性格上的差異，再說明該用哪一種來建置的判斷基準，以及混用時的串接模式。Power Automate 整體的設計方法在「用 Power Automate 自動化業務 ── 雲端流程與桌面流程的分工，以及錯誤處理設計」中討論，PowerShell 本身的入門則在「PowerShell 指令基礎 ── 該先學會的操作與安全使用方式」中討論，本文將聚焦在「該用哪一種的判斷」與「協作」。

1. 先講結論

• 判斷的第一基準是對象在哪裡。如果對象是本機檔案、共用資料夾、伺服器、作業系統，基本上用 PowerShell + 工作排程器；如果對象是 SharePoint、Outlook、Teams 等 Microsoft 365 上的資料與通知・核准，基本上用 Power Automate。
• PowerShell 的弱點是給人的通知。過去常用的 Send-MailMessage 已被官方正式標示為棄用（obsolete），PowerShell 內部沒有直接的替代方案。¹ 把通知・核准交給 Power Automate 通常更省成本。
• Power Automate 的弱點是觸及地端系統與處理大量資料。要從雲端流程觸及公司內部的檔案伺服器，需要內部部署資料閘道或桌面流程協作，兩者都不在 Microsoft 365 內建使用權的範圍內（屬於進階功能）。²³⁴
• 若要串接兩者，第一候選是由 PowerShell 把結果檔案放到 SharePoint，Power Automate 則用「當已建立檔案時（僅限屬性）」（英文介面為 When a file is created (properties only)）觸發程序偵測到後串接至通知・核准的鬆散耦合方式。⁵
• Power Automate for desktop 有「執行 PowerShell 指令碼」動作，可以從流程中呼叫既有的指令碼。不過從雲端流程呼叫是進階功能，也需要管理執行用的機器。⁶⁴
• 雲端流程的執行記錄預設只能檢視28 天內的資料。⁷ 需要留存憑證的處理，請用 PowerShell 端的記錄檔或寫回 SharePoint 清單的方式來保存。
• 最後，答案往往不在於技術本身，而是由能維護的人來做。只有製作者本人才能修改的自動化，無論用什麼工具，風險都是一樣的。

2. 兩種工具的性格

首先確認一下，兩者其實是活躍在不同場域的工具。

在此補充表中「變更管理」這一列。匯出流程的操作方式，是登入 Power Automate 入口網站，在左側導覽的「我的流程」>「雲端流程」中選擇要匯出的流程，再從選單的「匯出」旁的向下箭頭選擇「套件（.zip）」。取出的是 zip 套件，不像指令碼那樣適合逐行進行差異審閱。此外，能匯出的僅限流程的擁有者或共同擁有者。若想持續進行版本管理，Microsoft 建議的做法不是套件的匯出／匯入，而是使用 Dataverse 的解決方案來進行 ALM。⁸

重點在於，這張表的左右兩邊，「執行的地方」與「建置的人」都不一樣。PowerShell + 工作排程器在公司內部的機器上運作，由會寫程式碼的人建置，並以程式碼的形式管理。Power Automate 在雲端運作，即使是熟悉現場的人也能建置，不需要照看執行基礎架構。也就是說，這兩者的混雜並不只是工具重複，而是「資訊部門的自動化」與「現場的自動化」這兩種文化並存的結果。正因如此，只靠一聲令下把兩者統一到其中一邊，通常都會失敗。

3. 該用哪一種的判斷表

接到諮詢時，我會用「對象在哪裡」「由誰建置與維護」「是否需要給人的通知・核准」這三點來分辨。用具體的業務例子來看比較快，整理成判斷表如下。

縱向看這個表，可以發現「對象」這一欄幾乎是一對一決定工具的。例外是最後一列這種「處理在本機，通知在雲端」橫跨兩邊的情況，這正是第 6 章協作模式登場的地方。

反過來說，以下這些選擇方式之後會很吃力。

• 只因為想要通知，就把檔案處理也全部搬到 Power Automate。為了觸及地端而導入閘道或 RPA，會增加授權與管理對象（第 5 章）。
• 現場使用的 SharePoint 申請流程，由資訊部門用 PowerShell 來做。雖然做得出來，但用程式碼寫 SharePoint 寫入或 Teams 通知，費工卻回報不多，還會變成現場無法自行修改的獨門產物。
• 因為兩邊都做得出來，就讓各個承辦人自行分散選擇。這會直接連結到第 7 章提到的維護問題。只要事先定好「對象在這裡就用這個工具」這樣一條公司內部規則，混雜的無序程度就能大幅壓下來。

4. PowerShell 端的極限

郵件・Teams 通知很痛苦

當 PowerShell 的夜間批次被追加「執行完請用郵件通知」這樣的需求時，事情會突然變得困難。長年以來使用的 Send-MailMessage Cmdlet，因為無法保證與 SMTP 伺服器之間的安全連線，已被官方正式標示為棄用（obsolete），警告文字中明確寫著「PowerShell 內部沒有直接的替代方案」。官方提供的替代方案，是第三方的 MailKit 函式庫，或是給 Exchange Online 使用者的 Microsoft Graph PowerShell SDK（Send-MgUserMail）。¹

透過 Graph 發送雖然可行，但需要在 Microsoft Entra ID 進行應用程式註冊、授予權限（範圍）、管理憑證或密鑰，只為了一項通知就要背負相當多的準備工作。Teams 的通知也一樣，要直接從程式碼呼叫，驗證方面的門檻不低。這裡建議乾脆把通知交給 Power Automate負責。用標準連接器的 Outlook・Teams 動作，不需要額外的應用程式註冊，幾分鐘就能組出來。

在承辦人電腦上執行的「野生工作」

工作排程器自動化中常見的事故，是工作被設定在承辦人的電腦上，而不是伺服器上。電腦一關機下班，工作就不會執行；執行使用者的密碼變更或離職，工作也會悄悄停止。而且工作排程器是存在於各台機器本機上的東西，沒有地方可以一覽公司內部到底哪裡在跑什麼。

對策雖然樸實，但有三點：（1）定時執行的工作集中在固定的伺服器（若沒有，就集中在常駐開機的管理用電腦）上；（2）將工作清單與目的・負責人文件化；（3）把工作定義本身以 Register-ScheduledTask 等指令碼的形式保留下來，讓機器更換後仍能重現。⁹ 即使只把指令碼本體交給 Git 管理，若工作排程器端的設定（啟動時間・執行使用者・工作資料夾）仍靠手動操作，環境就無法重現。

憑證的保存

當指令碼要連接資料庫或外部服務時，密碼要放在哪裡的問題一定會出現。直接寫在 .ps1 中自不用說，PowerShell 的標準答案是 SecretManagement 模組＋SecretStore 擴充功能。可以把機密資訊加密保存在本機，再由指令碼透過 Get-Secret 取出。¹⁰ 從工作排程器進行無人執行時的架構（在自動化帳戶的內容中進行設定）也有官方文件說明。¹¹ 另外，這一系列模組目前處於「功能已完成」狀態，新功能開發已經結束，但安全性修正的支援仍會持續。¹⁰

另一方面，Power Automate 把連接器的連線（驗證）交由平台端保管，建置的人不需要意識到這個問題。這是 Power Automate 隱藏的優勢，反過來說，連線與流程擁有者的帳戶綁在一起，也會產生另一個管理上的問題。這一點在「Power Automate 的個人依賴對策 ── 讓建置者離職後流程也不會停擺」中討論過。

5. Power Automate 端的極限

觸及不到本機檔案・地端系統

雲端流程在 Microsoft 的雲端上運作，因此無法直接觸及公司內部網路的共用資料夾或地端資料庫。觸及的手段主要有兩種。

1. 內部部署資料閘道。在公司內部安裝常駐應用程式，作為雲端與地端之間的橋梁。不需要開放接收埠，只靠傳送方向的連線就能運作，安全性較高。¹² 透過閘道可以連接檔案系統或 SQL Server 等，但要使用閘道，需要對應的授權。²
2. 透過桌面流程（RPA）。從雲端流程呼叫在電腦上執行的桌面流程，把本機的處理交給它。這種「從雲端流程觸發・排程執行」本身就是進階功能。⁴

重點是，這兩種方式都不在 Microsoft 365 內建的 Power Automate 使用權範圍內。Microsoft 365 內建的使用權（seeded license）不包含進階連接器、內部部署閘道、RPA 中的任何一項。³ 也就是說，「想用 Power Automate 處理共用資料夾中的檔案」是一個比看起來更花錢的需求。授權層級與標準／進階的界線，已整理在「Power Automate 的授權與標準／進階連接器的界線」中，請在判斷前先確認。

不增加額外費用的現實解法有兩個。一是把要處理的檔案存放位置搬到 SharePoint／OneDrive，二是把共用資料夾那一側的處理交給 PowerShell，讓 Power Automate 只負責雲端那一側的工作。後者就是下一章的協作模式。

大量資料・複雜邏輯很吃力

用流程的迴圈逐行處理數十萬列的 CSV，這種處理不在 Power Automate 的設計對象範圍內。每種授權每天的動作執行次數也有上限，Microsoft 365 內建的使用權為每位使用者每天 6,000 個動作。³ 大量筆數的比對・彙總・轉換，若用 PowerShell 或 .NET 撰寫，往往幾分鐘就能完成。具體寫法可以直接沿用「PowerShell 實用指令集錦 ── 累積日常工作常用的小工具」中提到的 Group-Object 與 Compare-Object 組合。

此外，條件分支層層堆疊的邏輯，在流程畫面上很難閱讀，也無法撰寫測試。雲端流程單次執行最長 30 天的限制¹³，對等待核准的情境會有影響，但在此之前，「把分支畫在紙上，一張 A4 都裝不下的邏輯」本身就屬於程式碼的領域。

執行記錄 28 天就會消失

雲端流程的執行記錄，預設只會顯示 28 天內的資料。⁷ 「想在三個月後確認某一天的批次有沒有跑」這類需求，執行記錄用不上。若是 PowerShell，可以自行寫記錄檔，保存好幾年（這種設計在記錄檔整備的文章中有詳述）。若 Power Automate 需要留存憑證，可以在流程本身中加入把處理結果寫回 SharePoint 清單的步驟。包含錯誤時的通知與重試在內的詳細設計，請參考「Power Automate 的錯誤處理與重試設計」。

6. 混用時的串接模式

既然兩者擅長的領域不重疊，「處理交給 PowerShell、通知・核准交給 Power Automate」這種橫跨兩邊的業務一定會出現。串接模式有三種。

模式 a：透過檔案的鬆散耦合（推薦）

由工作排程器執行的 PowerShell，把處理結果（結果 CSV・摘要）放到 SharePoint 文件庫，Power Automate 端則用 SharePoint 連接器的「當已建立檔案時（僅限屬性）」觸發程序偵測到後，串接至通知或核准。這是實際存在的標準連接器觸發程序，變更通常會在幾分鐘內被偵測到（因為是透過輪詢確認 SharePoint 端的變更，並非即時）。⁵

若租用戶的顯示語言是英文，用中文名稱是搜尋不到的，因此在此併記英文介面的名稱。用觸發程序清單尋找時請以此為準。⁵

另外，名稱相似的「當資料夾中已建立檔案時」（When a file is created in a folder）已被標示為不建議使用，也有子資料夾中不會啟動等限制，若是新建置就不要選用。⁵

下圖表示這種模式的流程。工作排程器於 02:00 啟動 PowerShell 指令碼 → 指令碼進行彙總・檔案處理・輸出記錄檔，產生結果 CSV 與摘要 → 將其放置到 SharePoint 文件庫 → 放置動作被「當已建立檔案時」觸發程序偵測到，雲端流程啟動 → 流程檢視摘要內容，若正常結束則通知 Teams 完成，若有錯誤則通知承辦人，必要時轉交核准・處理流程，是一條單向的流程。

flowchart TD
    T[工作排程器 02:00 啟動] --> PS[PowerShell 指令碼<br/>彙總・檔案處理・輸出記錄檔]
    PS --> OUT[輸出結果CSV與摘要]
    OUT --> UP[放置到SharePoint文件庫]
    UP --> TRG[雲端流程啟動<br/>當已建立檔案時]
    TRG --> CHK{摘要內容}
    CHK -- 正常結束 --> OK[通知Teams完成]
    CHK -- 有錯誤 --> NG[通知承辦人<br/>必要時轉交核准・處理流程]

從 PowerShell 放置到 SharePoint 的方式，要依工作的執行方式來選擇。把輸出資料夾設為 OneDrive／SharePoint 的同步對象（指令碼只需寫入本機資料夾）的方法最簡單，但同步用戶端是在登入中的使用者工作階段下運作的應用程式。設定為「不論使用者是否已登入都執行」的夜間工作，或是沒有任何人登入的伺服器上，同步不會運作，寫到本機的檔案不會被上傳，流程也就不會啟動，形成一次空跑。若是白天在有人使用的電腦上執行的小規模作業，同步就夠用了，但若前提是夜間・無人執行，請改用 PnP.PowerShell 或 Graph API 從指令碼直接上傳，或是準備一個持續保持登入的工作階段並將其納入監控對象。雖然驗證方面的準備會增加，但可以用機制杜絕「應該有放檔案卻沒有」的情況。

PnP.PowerShell 是用來操作 SharePoint Online、Teams 等 Microsoft 365 的社群製作（並非 Microsoft 官方產品）開源 PowerShell 模組。備有超過 700 個 Cmdlet，可以直接從指令碼進行檔案上傳或清單操作。不過，以前可以輕鬆用共用的 Entra ID 應用程式連線，但該應用程式已在 2024 年 9 月廢止，使用者必須自行註冊自己的 Entra ID 應用程式才能使用。已經不是「裝上模組就能立即運作」了，評估導入時請把這項應用程式註冊與權限授予的工時也一併納入考量。¹⁴

推薦這種模式的理由是，界線以檔案這種看得見的形式固定下來。PowerShell 端不知道 Power Automate 的存在，Power Automate 端也不知道指令碼的內容。當其中一方壞掉時，只要看 SharePoint 上有沒有檔案，就能立刻分辨是哪一邊的問題。負責人也可以分開。指令碼由資訊部門負責、通知流程由熟悉現場的人負責，這樣的分工就能直接成立。此外，放置的檔案本身也能作為彌補執行記錄 28 天問題⁷的憑證發揮作用。

模式 b：從 Power Automate for desktop 呼叫 PowerShell

Power Automate for desktop（PAD）有「執行 PowerShell 指令碼（Run PowerShell script）」動作，可以在桌面流程中執行任意的 PowerShell 程式碼，並用變數（PowershellOutput）接收輸出結果。⁶ 由於可以把既有的指令碼資產當作流程的零件來呼叫，因此可以組出「處理本體維持指令碼原樣，只把啟動與前後的畫面操作交給 PAD」的架構。

這個動作的設定項目只有三個。⁶

輸出以 PowershellOutput（指令碼的輸出）與 ScriptError（執行過程中出現的錯誤）這兩個變數接收。要把值傳回流程，官方的寫法是在 PowerShell 端傳給 Write-Output。⁶

# 假設貼在PAD動作設定「PowerShell code to run」欄位中的最小範例。
# %InputFolder% 是PAD端的變數，會在PowerShell執行前被替換成字串
$targetFolder = '%InputFolder%'
$count = (Get-ChildItem -LiteralPath $targetFolder -Filter '*.csv' -File).Count

# 用Write-Output傳回的內容會進入PowershellOutput變數
Write-Output $count

也就是說，從 PAD 端來看，這個零件的入口只有「嵌入程式碼本文中的變數」，出口只有「PowershellOutput 的字串」這兩者。因為傳回值不會結構化，而是以字串傳回，若想傳回多個值，就要設計成整理成 CSV 一列或 JSON，再於後續步驟解析 PowershellOutput。加上預設逾時只有 10 秒，這個動作並不適合「把整個夜間批次本體都塞進這個動作」的用法。若是長時間的處理，請一併考量以下的注意事項再做判斷。

不過有三點注意事項。第一，這個動作內部會啟動 powershell.exe，也就是 Windows PowerShell 5.1。¹⁵ 以 PowerShell 7 為前提撰寫的指令碼，可能無法原樣執行。第二，有逾時設定（預設值 10 秒），要呼叫長時間的批次時，需要明確延長或設為不限制。⁶ 第三，若想無人定時執行，從雲端流程觸發是進階功能⁴，還需要無人執行的授權與執行機器的管理。「用 PAD 取代工作排程器來定時執行」是否值得為此支付額外費用，最好冷靜評估。若貴公司已經在用 PAD 運行 RPA（畫面操作），執行基礎架構已經齊備，這會是一個選項，但若非如此，模式 a 就已經足夠。

模式 c：接收 HTTP 要求的自製 API

利用雲端流程的「當接收到 HTTP 要求時（When an HTTP request is received）」觸發程序，讓流程擁有一個 URL，再從 PowerShell 端用 Invoke-RestMethod 呼叫並啟動，或是反過來在公司內部架設一個小型 Web API，讓流程來呼叫。這個觸發程序屬於進階的 HTTP 要求／回應連接器。¹⁶ 也有可以設定呼叫方限制（例如僅限租用戶內使用者）的 OAuth 驗證機制。¹⁷

即時性高，也能傳遞參數，是最靈活的模式，但 URL 管理・驗證・錯誤時的重送，需要考量的事情一口氣進入開發領域。到了這個地步，已經不再是「Power Automate 與 PowerShell 的協作」，而是小型系統開發，是該判斷要自行內部承擔、還是委外請人審視設計的階段。

總結來說，先考慮模式 a，若 PAD 的基礎架構已經存在就用 b，只有在即時性需求明確時才用 c。鬆散耦合的設計是檔案協作通用的道理，排他控制與交接的做法在「檔案整合的互斥控制基礎 - 檔案鎖與原子性 claim 的最佳實務」中也有討論。

7. 「沒有人兩邊都會」的問題

到目前為止都在用技術面來寫判斷基準，但在實際現場，最後起作用的往往是「誰能維護」。資訊部門有一位會寫 PowerShell 的人，現場有一位會用 Power Automate 的人，兩邊都懂的人卻是零。這在中小企業是常態。

因此，即使技術上適合用 PowerShell 處理，若會寫的人即將離職，改用 Power Automate 建置（或反過來）這樣的判斷，也是相當合理的。比起工具的優劣，5 年後公司內部是否還有人能修改它更重要。判斷表（第 3 章）是「在有人能維護的前提下的最佳解」，若沒有這樣的人，就要把最佳解依現有人力來調整。

在此基礎上，不論用哪一種工具，都有兩件共通該做的事。

• 列出存在清單。把工作排程器的工作清單（哪台機器・幾點・做什麼・由誰管理）與 Power Automate 的流程清單（擁有者・連線・目的）整理到同一份台帳上。兩套系統混雜的公司，最可怕的就是其中一套系統無法從另一套看見。
• 以可交接的形式保存。指令碼交給 Git、工作定義交給註冊用指令碼⁹、流程交給共同擁有者設定與匯出。沒有規格書的自動化，等同於量產沒有原始碼也沒有規格書的系統的縮小版。流程端具體的交接設計，整理在個人依賴對策的文章中。

8. 總結

PowerShell + 工作排程器與 Power Automate，並非互相競爭的工具，而是守備範圍幾乎不重疊的兩種不同工具。本機・伺服器・檔案・大量資料交給 PowerShell，Microsoft 365 上的資料與通知・核准交給 Power Automate。依這條基本原則，大部分自動化的歸屬就能決定。

橫跨界線的業務，不要硬塞到其中一邊，而是以放在 SharePoint 上的檔案為界線做鬆散耦合串接，這在授權層面與維護層面都比較穩健。PowerShell 通知上的痛苦（Send-MailMessage 已棄用）與 Power Automate 觸及地端的痛苦（閘道・RPA 屬於進階功能），恰好各自由對方的擅長領域補足。

而且，與選擇工具同等重要的是，事先決定好「由誰維護」「哪裡在跑什麼」。兩套自動化系統並存這件事本身是健全的。只有無秩序地混雜才是問題。若您正處於想整理公司內部自動化全貌、或想針對個別案例判斷該用哪一種來建置的階段，也歡迎提出諮詢。

相關文章

• 用 Power Automate 自動化業務 ── 雲端流程與桌面流程的分工，以及錯誤處理設計
• 工作排程器的工作不執行、以 0x1 結束 ── 原因排查與安全的維運設計
• PowerShell 腳本應用 ── 安全地自動化日誌調查、封存與報表化
• Power Automate 的授權 ── Microsoft 365 能免費用到什麼程度，何時需要 Premium
• Power Automate 的屬人化對策 ── 讓建立者離職後流程也不會停止
• 用 Power Automate 設計定期執行流程 ── 月底處理、營業日判定與提醒的實務

相關諮詢領域

合同會社小村軟體提供從 PowerShell 公司內部批次作業的整備，到包含 Power Automate 在內的自動化基礎架構設計審查，涵蓋「該用哪一種工具來做」判斷在內的諮詢服務。

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

參考連結

</content>

相關文章

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

相關主題

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

與本主題相關的服務

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

常見問題

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

Power Automate 和 PowerShell，自動化該用哪一種來做？

基本原則是依「對象在哪裡」來分。如果對象是本機檔案、共用資料夾、伺服器、資料庫、作業系統操作等公司內部的 Windows 環境，PowerShell + 工作排程器通常較穩定、較易維護。如果對象是 SharePoint、Outlook、Teams 等 Microsoft 365 上的資料與通知・核准，則適合用 Power Automate 的雲端流程。把處理本體與通知分開來看，繁重的處理交給 PowerShell、給人的通知或核准交給 Power Automate 的分工方式也很實際。

用 PowerShell 發送郵件或 Teams 通知很困難嗎？

過去常用的 Send-MailMessage Cmdlet，因為無法保證與 SMTP 伺服器之間的安全連線，已被官方正式標示為棄用（obsolete），PowerShell 內部並沒有直接的替代方案。雖然可以透過 Microsoft Graph PowerShell SDK 的 Send-MgUserMail 來發送，但需要事先完成應用程式註冊與權限授予等準備工作，只為了通知就使用這種方式，門檻偏高。實務上，讓 PowerShell 只負責把結果寫入檔案，偵測與通知交給 Power Automate 負責的架構比較好處理。

Power Automate 可以處理本機共用資料夾中的檔案嗎？

可以，但雲端流程要能觸及公司內部網路的檔案，需要導入內部部署資料閘道，而使用閘道的權利並不包含在 Microsoft 365 內建的 Power Automate 使用權中，需要更高階的授權。從雲端流程呼叫桌面流程（RPA）的架構也屬於進階功能。若想在不增加授權的前提下解決問題，較實際的做法是先考慮把要處理的檔案移到 SharePoint／OneDrive 那一側，或是把共用資料夾那一側的處理交給 PowerShell + 工作排程器負責。

讓 PowerShell 的夜間批次與 Power Automate 協作，最簡單的方法是什麼？

建議採用透過檔案的鬆散耦合方式。讓由工作排程器執行的 PowerShell，把處理結果的 CSV 或摘要檔案放進 SharePoint 文件庫，Power Automate 端則用「當已建立檔案時（僅限屬性）」觸發程序偵測到該檔案，再串接到通知或核准。這種架構下，兩邊都不需要了解對方的內部運作，即使其中一方壞掉也容易釐清問題所在，也可以由不同的人負責。雖然也可以用 Power Automate for desktop 的「執行 PowerShell 指令碼」動作直接呼叫，但這會增加授權與機器管理方面的前提條件。

作者檔案

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

Go Komura

小村軟體有限公司 代表

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