Sub-workflow：把常用邏輯抽成小工作流

為什麼要學這個

你已經跟著第 7 章認完節點三大類、跟著第 15 章學會 IF/Switch、跟著第 17 章設好 Error workflow、跟著第 18 章把資料整形整乾淨了。你的 workflow 越拉越多、越拉越像。

然後有一天你翻開自己的 n8n 首頁，發現：

• 「傳 Slack 通知」的那四步驟（IF 判斷 severity → Set 標題 → Slack 發訊息 → Sheets log）—— 在五個 workflow 都在複製貼上
• 老闆突然說「以後所有通知都要多附一句『請於 24 小時內回覆』」—— 你要改五個地方
• Slack channel 從 #alerts 改成 #ops-alerts—— 又要改五個地方
• 某天有一個 workflow 忘記改，同事收不到通知，鍋你揹

這是「複製貼上式開發」必然的下場。解法：把那四步驟抽成一個獨立的小工作流叫 Sub-workflow，其他 workflow 用 Execute Workflow 節點呼叫它。之後改共用邏輯只要改那一個 sub-workflow，所有呼叫方自動吃到新版。

什麼是 sub-workflow：兩個角色

Sub-workflow 不是一個特別的節點類型，也不需要任何 add-on。它就是一個普通的 workflow，只是設計成給別人呼叫的。整套機制靠兩個節點分別扮演兩個角色：

整個機制長得像程式語言的函式呼叫：

• 呼叫方傳「參數」（items）給 sub-workflow
• Sub-workflow 拿參數去執行
• Sub-workflow 執行完把「回傳值」（最後一個節點的 items）交還給呼叫方
• 呼叫方把回傳值當作 Execute Workflow 節點的 output，繼續往下游流

什麼時候該抽 sub-workflow、什麼時候不用

不是每段邏輯都值得抽。太積極抽反而會讓 workspace 一堆碎片工作流，反過來難管。用下面這張表判斷：

動手：建一個「統一發 Slack 通知」sub-workflow

用一個具體案例走一遍。要抽的邏輯：「收到一個事件，依 severity（error/warn/info）決定 channel 跟顏色，發到 Slack。」 之後任何 workflow 要通知都直接呼叫這一個。

1. 開一個新 workflow，命名 [Sub] Slack Alert

   首頁 Workflows → + Create workflow。右上角 workflow 名稱點下去改成 [Sub] Slack Alert。前綴 [Sub] 是慣例（後面命名慣例段會講），一眼就知道這個 workflow 是要給別人呼叫的、不會自己主動跑。

2. Trigger 節點選 Execute Workflow Trigger

   畫布上按 Tab 或點 + 打開節點抽屜，搜尋 Execute Workflow Trigger（在 Trigger 類）拉進來。這個節點的角色就是「當我被別人呼叫時，我從這裡開始」。沒有它，別人的 Execute Workflow 節點會找不到入口。

3. 設 Input Data Mode = Define using JSON example

   點開 Execute Sub-workflow Trigger 節點，找到 Input data mode 下拉，官方共三個選項：Define using fields below（一欄一欄敲名字＋型別）、Define using JSON example（貼一段範例 JSON、n8n 幫你推 schema）、Accept all data（不驗證、來什麼收什麼）。這裡選 Define using JSON example，貼上：

   {
     "severity": "error",
     "message": "資料庫連線失敗",
     "source": "backup-daily"
   }

   好處：呼叫方在他的 Execute Sub-workflow 節點裡會看到這個 schema 提示，直接依樣拼資料傳進來。省掉「我到底要傳什麼」的溝通成本。想要「介面契約先行」的團隊選 Define using fields below；想「先跑再說什麼都收」的選 Accept all data。

4. 加 IF 節點：判斷 severity

   接一個 IF 節點，條件寫 {{ $json.severity }} equals error。True 分支走「發到 #ops-error 頻道、紅色 icon」；False 分支再接一個 IF 判 warn／info，或者直接用 Switch 節點三分（第 15 章教過 Switch 就是為這種情境設計的）。

5. Slack 節點：依 severity 決定 channel

   每個分支各拉一個 Slack → Message → Send 節點：error 分支的 Channel 填 #ops-error、warn 填 #ops-warn、info 填 #ops-info。Text 欄位用 expression 統一拼：[{{ $json.severity | upper }}] {{ $json.source }}: {{ $json.message }}。這樣三個 channel 訊息長相一致，維護一次到位。

6. 結尾：讓 workflow 自然結束（不用 Respond to Webhook）

   三個 Slack 節點各自是分支的終點就好。Sub-workflow 執行完，最後一個節點的 items 會自動被當作回傳值送回呼叫方——不用另外接 Respond to Webhook（那是給 Webhook 節點用的，不是 sub-workflow）。想回傳自訂結構的話，最後可以接一個 Set/Edit Fields 節點整成想要的樣子（例：{ "notified": true, "channel": "#ops-error" }）。

7. Save（Ctrl+S）並複製 workflow ID

   存檔後看瀏覽器網址列，會像 https://n8n.woowtech.io/workflow/abc123XYZ——最後那段就是 workflow ID。等下呼叫方 Execute Workflow 節點下拉找不到時，你可以直接貼這串 ID。注意：sub-workflow 不用把 Active toggle 打開，因為它不是靠自己的 trigger 主動跑，是等別人來呼叫。

8. 用 Execute Workflow Trigger 節點的「Execute step」按鈕測一次

   點 Execute Workflow Trigger 節點右上角 Execute step，會用你剛剛在 JSON Example 貼的資料當 input 試跑一次。三個 Slack 節點應該只有 error 分支被觸發（因為 example 的 severity 是 error）。真的收到 Slack 訊息就代表 sub-workflow 本身沒問題。

動手：從別的 workflow 呼叫這個 sub-workflow

Sub-workflow 建好了。現在打開一個既有的 workflow（例如「每天備份資料庫」），把原本自己塞在裡面的四個 Slack 通知節點刪掉，改成一個 Execute Workflow 節點呼叫 sub-workflow。

1. 打開要改造的 workflow

   假設你有一條「每天凌晨備份資料庫」的 workflow，Schedule Trigger → 執行備份 → IF 判斷 exit code → 成功／失敗各發 Slack。現在把「發 Slack」那段拆掉。

2. 刪掉原本的 Slack 節點群，改拉 Execute Workflow

   把原本自己的 IF/Set/Slack 那些節點刪光。從節點抽屜搜尋 Execute Workflow（Action 類，別跟 Trigger 版搞混了），拉進來接在 IF 節點後面。

3. Source 選 Database，Workflow 下拉選 [Sub] Slack Alert

   節點打開，Source 有四個模式：Database（從 workspace 現有 workflow 挑，最常用）、Local File（讀本機 JSON 檔）、Parameter（把整段 workflow JSON 貼進節點）、URL（指定 workflow URL）。保留預設 Database，下拉找 [Sub] Slack Alert；找不到再切別的模式手動指定。

4. 檢查 Wait for Sub-workflow Completion

   這個 toggle 決定「我要等 sub-workflow 跑完拿到回傳值再繼續嗎」。打勾＝等；不勾＝呼叫完就繼續往下（fire-and-forget，適合純通知不 care 結果）。想用 sub-workflow 的回傳資料繼續處理的話一定要打勾。官方文件沒明說預設值，實務上建 Execute Sub-workflow 節點時是打勾的，不放心請自己確認一次。

5. Mode 選 Run once with all items

   Mode 有兩個選項：Run once with all items（把上游全部 items 一次丟進 sub-workflow，sub-workflow 跑一次）或 Run once for each item（每筆 item 各觸發一次 sub-workflow，跑 N 次）。通知這種一次一筆的情境選 Run once with all items 就好。

6. 設要傳的 items：用 Workflow Inputs 或 Set 節點預整形

   Sub-workflow 若在 Trigger 端定義了 schema（Define using fields below 或 Define using JSON example），Execute Sub-workflow 節點會自動顯示 Workflow Inputs 表格讓你逐欄填 expression、還有一個 Attempt to convert types toggle 幫忙做型別轉換。如果 sub-workflow 是 Accept all data，這區塊不會出現，上游 items 原封不動就是 input。想大幅改結構的話，先加一個 Set/Edit Fields 節點整成 { severity, message, source } 再接：

   severity: error
   message: {{ $json.error_message }}
   source: backup-daily

   Save 存檔，手動 Execute Workflow 跑一次驗證：Sub-workflow 那邊會被喚醒、Slack 應該收到訊息、Execute Workflow 節點在呼叫方這邊會顯示回傳的 items。

傳參數的兩種模式

Execute Workflow 節點怎麼決定要丟什麼給 sub-workflow？主要兩種模式，任選：

Sub-workflow 的限制與注意事項

抽出來很爽，但有幾個現實限制要放在心上，不然半年後會踩雷：

命名慣例：一眼看出誰是誰

Workspace 用久了會有幾十上百個 workflow，一半是主 workflow、一半是被呼叫的。全部混在一起找不到人。用前綴分類是最簡單有效的做法：

Workflow 列表頁支援搜尋，打 [Sub] 就能一次看到所有 sub-workflow，改起來、盤點起來都方便。這個慣例在 Woow 內部團隊沿用很久，新同事看到也一秒理解。

實例：一組 utility sub-workflow 家族

有了 sub-workflow 觀念以後，你可以幫團隊建一組「共用工具箱」。以下是很多公司實際跑的四個 sub-workflow，供參考：

建完這四個以後，你所有 workflow 都乾淨很多：

• 要通知？不自己拼 Slack，呼叫 [Sub] Slack Alert
• 要記 log？不自己拼 Sheets，呼叫 [Sub] Log Execution
• 要顯示時間給人看？呼叫 [Sub] Format Date TW，全公司格式一致
• 要查同事？呼叫 [Sub] Get Employee Info，內部 API 換 URL 也只改這一個

之後 HR API 網址換了、Slack channel 改名、時區格式微調——只改對應的那一個 sub-workflow，全公司所有 workflow 自動吃到新版。這就是 sub-workflow 真正的威力。

常見卡關與怎麼救

常見問題