1. 這個節點做什麼

暫停（Delay）讓流程實例在這個節點停留一段設定好的時間，時間到之前流程不會繼續往下走；時間一到， 由平台背景的執行器自動把這個節點撿回來繼續執行，不需要任何人操作，也不會佔用任何人的待辦清單。它本身不呼叫 任何外部服務，純粹是時間控制。

適合用在：SLA 計時（過多久還沒人處理就提醒或升級）、限制對外部系統的呼叫頻率、排定一段時間後才執行的 後續動作。不適合用在：需要精確到秒的排程（見下方「精度」說明）、等待另一個並行分支完成（那是 並行匯合 的工作）、或等待某個人做出決策（那是簽核 （FormAdapter）的工作，簽核有自己一套獨立的等待與逾時機制）。

2. 設定欄位

面板欄位|config key|必填|預設值|說明
:--|:--|:--|:--
延遲秒數|delay_seconds|選填|面板顯示 60；未設定時 handler 視同 0|面板限制最大 86400（24 小時）。這是面板唯一提供的設定欄位。
（面板未提供，需直接編輯流程 graph）|delay_minutes|選填|0|與 delay_seconds、delay_hours 是相加關係，不是互斥選項。
（面板未提供，需直接編輯流程 graph）|delay_hours|選填|0|同上，與另外兩個相加。
（面板未提供，需直接編輯流程 graph）|delay_until|選填|—|ISO 8601 格式的絕對時間字串（例如 2026-12-31T16:00:00Z）。只要填了這個欄位， 會完全取代前三者相加的總和，不是取兩者中較晚或較長的那個；不支援 ${...} 變數替換，必須是寫死的字串。

3. 可用的變數與輸出

暫停節點不讀取任何表單欄位或流程變數來決定要等多久——它只看自己 config 裡寫死的秒數／ 分鐘／小時／絕對時間；delay_until 也不支援 ${...} 變數替換，這點與平台其他大多數 節點的欄位行為不同，直接編輯流程 graph 時要特別注意。

它也不會輸出任何流程變數。如果想在流程日誌或後續節點裡留下「暫停在這裡等過」的紀錄， 慣例是在它後面接一個設定變數（OpSet）節點，用 ${t.now} 寫入一個 時間戳記變數。

4. 出線行為

暫停節點每次被執行（不論是第一次進入，還是被喚醒重新執行）只會有兩種結果：

• 還沒到目標時間：節點進入 WAITING 狀態，資料庫裡的排程時間欄位 （scheduled_at）被設成目標時間，不推進任何出邊，也不算失敗。
• 已經到了目標時間：節點回報成功，執行結果裡沒有指定任何出線，於是照通用規則「沒有指定 出線就取全部出邊」往下推進——正常情況下暫停節點只接一條出邊，效果上就是走那一條。

誰喚醒它：平台背景執行器的主輪詢迴圈預設每 5 秒跑一次，每次都會找「狀態是 WAITING、節點型別是暫停（或結束、並行匯合、OS 命令這幾種同樣會等待的型別）、而且排程時間已經到期」 的節點，重新丟進 handler 執行一次。另外還有一個獨立的備援輪詢，每 120 秒跑一次同樣的查詢，作為主迴圈萬一漏接 時的第二道保險。

精度：不是精確到秒。目標時間一到，最快也要等到下一次主輪詢週期（預設 5 秒）才會被撿起來， 再加上啟動執行程序本身的時間，實際恢復執行的時間通常會比設定的時間晚幾秒。大多數 SLA 或催辦用途這點誤差不 重要，但不要拿暫停節點做秒級精度要求的排程。

流程已經結束時到期：如果暫停節點還在等待期間，而流程因為另一條並行分支先走到「結束」節點 而進入完成、取消、失敗等終態，執行器下一次輪詢到這個還在等待的節點時，會直接把它標記為已取消， 不會恢復執行，也不會再往下走。這正是「暫停接分支做 SLA 計時」這種設計能夠安全收尾的原因： 人工處理完成、流程正常結束之後，還在倒數的計時分支會被直接取消，不會事後才跳出一則「已逾時」的提醒。

5. 常見設計方式

5.1 基本用法：固定秒數暫停

5.2 SLA 計時與逐級催辦（取自 SOC 團隊版）

資安事件處置流程（SOC 團隊版）用「暫停＋分支」的組合做兩段式 SLA 催辦：第一次等 15 分鐘後檢查有沒有人 簽核，沒有就發一則催辦通知，再等 15 分鐘後二次檢查，還是沒有就升級通報主管。這條計時分支只負責 提醒，從頭到尾都不會替值班人員做出封鎖或放行的決定，真正的決定仍在另一條人工簽核的路徑上完成。

5.3 絕對時間：delay_until

面板不提供這個欄位，只能直接編輯流程 graph（例如用腳本產生流程模板）：

{
  "delay_until": "2026-12-31T16:00:00Z"
}
// 一旦填了 delay_until，delay_seconds／delay_minutes／delay_hours
// 即使同時存在也會被完全忽略；delay_until 不支援 ${...} 變數替換，
// 必須是寫死的 ISO 8601 字串。

6. 注意事項

沒有設定任何延遲時間，等於完全不暫停
症狀：拖了一個暫停節點到畫布上，但沒有打開面板設定就直接發行，結果流程跑到這個節點時完全沒有停頓， 立刻就繼續往下走了。
原因：當 delay_seconds／delay_minutes／ delay_hours 全部是 0（或完全沒有設定過，config 是空物件）、也沒有填 delay_until 時，handler 會判定「無延遲設定」，直接回報成功並推進，不會進入等待狀態。
正確做法：放到畫布上的 暫停節點務必打開面板、設定延遲秒數並按套用；不要假設「放了一個暫停節點」本身就會造成停頓。

流程已經結束，還在等待的暫停到期後不會繼續
症狀：設計了一條並行的計時分支，指望它「不管人工那條有沒有完成，時間到了都會做點什麼」，結果 人工那條先讓流程走到結束之後，計時分支到期時預期的通知或動作完全沒有發生。
原因：結束節點結束的是 整個流程實例；已經是完成、取消、失敗等終態的流程，執行器發現還有暫停節點在等待到期，會直接把它標記為 已取消，不會恢復執行。
正確做法：把計時分支設計成「純粹催辦、不代替人做決定」（見圖 2），並且接受 它在流程正常結束後就會被安全地丟棄；不要把「流程結束後一定要執行到的動作」放在暫停節點後面。

面板只做得到「延遲秒數」，其餘要直接改流程 graph
設計器面板只有「延遲秒數」一個輸入框（上限 86400 秒／24 小時）。要用分鐘、小時或絕對時間，只能透過 直接編輯流程 graph JSON（例如用佈建腳本）產生，設計器裡看不到這些欄位，之後在設計器裡開啟這個節點，也 只會看到（也只能改）秒數欄位。delay_until 另外不支援 ${...} 變數替換，只能是 寫死的字串——這點與平台大多數節點欄位的行為不同。

delay_until 是覆蓋，不是取較晚的那個
如果 delay_until 與 delay_seconds／delay_minutes／ delay_hours 同時存在於 config 裡，只有 delay_until 生效，其餘三個會被完全 忽略，不會拿來比較取較晚或較長的那個。直接編輯 graph 時如果同時留著這兩組設定，要清楚知道實際生效的 只有 delay_until。

精度受輪詢週期限制
目標時間到了之後，最快也要等下一次主輪詢週期（預設每 5 秒一次）才會被撿起來，加上啟動執行的時間， 實際恢復通常會晚個幾秒。這對大多數 SLA、催辦、節流用途不是問題，但不要拿暫停節點做秒級精度要求的排程。

delay_until 若是過去時間，不會真的等待
delay_until 填的時間如果已經過去，節點會判定「已過目標時間」直接回報成功繼續，不會等待， 也不會有任何錯誤或提示。拿舊資料重新跑一次含暫停節點的流程時，暫停節點有可能完全不會停頓，看起來像是 跳過了這一步。

7. 在 node展覽館 實際操作

NT-08 Delay 示範：流程送出後先進入暫停節點等待 45 秒（delay_seconds=45）， 時間到才會被執行器自動撿回來繼續，接著才會出現待簽核任務。

在平台安裝目錄下執行（需要系統管理權限；這支批次同時會建立分支的兩個示範）：

venv/bin/python scripts/seed_node_showcase.py --apply --only B2

寫入後到表單中心（例如 http://192.168.0.112:8000/beakplatform/forms/center）的「填寫表單」 分類「node展覽館」下找到「NT-08 Delay 示範表單」送出。預期看到：送單後立刻查詢，暫停節點狀態是等待中， 排程時間大約是送單時間再加 45 秒，流程實例本身仍在執行中；45 秒以上之後再查一次，暫停節點應該已經變成 成功，流程繼續往下走到設定變數節點（寫入一個記錄恢復時間的流程變數）再到簽核節點；簽核後流程才會結束。

8. 相關節點

• 分支（Branch）：暫停通常接一個分支，檢查「等待的條件現在是否已經成立」， 兩者搭配才做得出 SLA 計時、逐級催辦這類效果。
• 緊急廣播（AlertBroadcast）：計時到期又還沒處理時，最常見的下一步 就是發一則提醒或升級通報。
• 設定變數（OpSet）：暫停恢復執行後，常用來記錄一個時間戳記變數；沒有出線的 設定變數節點也是讓計時分支安靜結束、不干擾其他分支的標準做法。
• 結束（End）：結束節點結束的是整個流程實例，還在等待中的暫停節點會在流程 結束後被執行器取消。