緊急廣播（AlertBroadcast）是只適用在最緊急的情況，或真正的SOC組織有許多顯示器時能突顯緊急案件，會佔用全畫面以醒目方式呈現，如果各位讀者沒學會BeakPlatform的設計直接使用一定會感覺很麻煩。對，沒錯！希望各位自己把流程設計改得好用些才真的上線

SOC有用到的流程節點Node至此介紹完畢，下一篇做其他功能的實作才不會太枯燥

1. 這個節點做什麼

緊急廣播（AlertBroadcast）建立或更新一筆廣播記錄，前端每隔一段時間（預設最長 1 分鐘，由平台設定的輪詢週期決定）輪詢一次，一旦查到屬於自己、還沒確認過的廣播，就會立刻在畫面上 彈出一個全頁對話框，可以設定成必須捲到底、勾選「我已閱讀並知悉以上訊息」才能關閉。這是全平台 干擾程度最高的通知方式，設計上就是給「所有人都必須知道、也必須明確表示知道」的場景用的。

節點執行本身不會等任何人看到或確認：寫入記錄的當下就完成並往下走，之後有沒有人看到、 何時看到、有沒有勾選確認，完全是使用者瀏覽器那一端的事，跟流程的進度無關。

適用情境：需要讓一群人「都知道」且通常也要「明確表示知道」的高干擾通知，例如處置完成通報、 需要主管介入確認的升級通報。不適合的情境：

1. 需要逐案留痕的稽核通知——同一個廣播代碼 再次觸發會覆蓋前一則內容並清空所有人的已讀記錄（見「6. 注意事項」），這種情境應改用 Email 或 Telegram 節點，各自獨立留下一筆送達紀錄；
2. 只是想讓大家「順便看到」、不需要停下手邊工作， 應改用干擾程度低很多的跑馬燈廣播（NavbarBroadcast）。

2. 設定欄位

2.1 基本內容

2.2 目標對象

2.3 已讀確認

3. 可用的變數與輸出

會做變數替換的只有標題與訊息內容，語法與所有節點共用： ${f.欄位}（表單欄位）、${fi.applicant|serial|...}（表單資訊）、 ${v.變數}（流程變數）、${wi.code|exec_code|name|status|depth}（流程實例， 僅此五個）、${n.name|id|type}（節點上下文）、${t.now|date|time}（時間）。 廣播代碼不做變數替換，即使寫了 ${...} 樣板也會原封不動存進資料庫—— 這是本節點最容易誤用的一點，務必留意「6. 注意事項」的說明。目標對象、角色、部門、包含子部門、 是否需要已讀確認，全部是設定值，同樣不支援變數替換。訊息內容的變數替換另外會對「替換進來的值」做 HTML 跳脫（見 2.1 與「6. 注意事項」）；標題目前沒有這道處理，但前端渲染標題時會整段另外跳脫一次， 兩者用不同機制達到同樣「不被當成 HTML 執行」的效果。

這個節點不會寫入任何流程變數。執行完成後能查到結果的只有兩個地方：

• 流程管理頁的執行紀錄：含 broadcast_code、目標設定、require_ack。
• 廣播本身存在企業的「查詢清單」資料（依廣播代碼識別）；使用者的已讀確認紀錄則各自獨立存放， 可在「緊急廣播管理」頁面查看已讀／未讀名單與統計（見「6. 注意事項」與「7. 在 node展覽館 實際操作」）。

4. 出線行為

節點本身完全不挑邊，只回報「成功」或「失敗」兩種結果。依系統共用規則，只要節點成功， 接在它後面的所有出線都會同時被走（設計上通常只接一條）——而且如前所述，這個「成功」只代表 「記錄已寫入資料庫」，跟有沒有人真的看到、確認完全無關，兩者是分開的兩件事。

成功
寫入（或覆蓋既有的同代碼）廣播記錄，立即往下走。

失敗
廣播代碼為空，或標題替換後仍是空字串，都會讓節點回報失敗。訊息內容 即使替換後是空字串也不會失敗（見「2.1 基本內容」）。失敗時佇列會依系統共用的重試機制自動重試 （最多 3 次相同失敗才整個標記為執行失敗），重試期間不會往任何出線推進，流程實例維持在執行中， 不會自動結束。

5. 常見設計方式

5.1 封鎖完成後通報角色，不要求已讀（取自 SOC 團隊版）

5.2 逾時催辦後升級通報主管，要求已讀（取自 SOC 團隊版）

6. 注意事項

把廣播代碼當成「每案一個」，結果全部案件共用同一則
症狀：同一段時間內連續處理好幾個案件，每次都觸發了緊急廣播，但使用者只會看到「最新那一次」 的內容，前面幾次的彈窗內容像是消失了；如果 require_ack 是開著的，先前已經確認過的人 這次又要重新確認一次。
原因：broadcast_code 不做變數替換，如果誤以為它跟標題、內容一樣會把 ${wi.exec_code} 之類的樣板換成每個案件不同的值，實際上寫進資料庫的是完全相同的字面 字串（含 ${...} 本身）。同一個廣播代碼的每一次執行都會覆蓋前一則的內容，並清空所有人 的已讀紀錄——這個節點的設計語意本來就是「目前生效的這一則橫幅」，不是逐案累積的通知歷史。
正確做法：需要逐案獨立留痕的通知，改用 Email 或 Telegram 節點，各自送出獨立的一筆訊息； 這個節點適合的是「同一時間只需要一則有效」的場景，例如系統維護公告、目前唯一生效的緊急狀態通報。

想用變數帶入格式化的 HTML，結果畫面上顯示原始標籤文字
症狀：樣板裡用變數引用某個表單欄位或流程變數，期待它帶來的內容含有 ／ 之類的標籤並正常排版，結果彈窗上看到的是 <b> 這種原始字元，不是真的粗體或換行效果。
原因：訊息內容的變數替換只針對「${...} 替換進來的值」做 HTML 跳脫， 設計者直接寫在樣板本身、不經變數替換的標籤則不受影響，仍會被當成 HTML 渲染 （前端仍以 innerHTML 插入頁面）。也就是說：標籤要有效就得寫在樣板裡，變數帶進來的內容 一律以純文字呈現，不能指望從表單欄位或流程變數帶入可執行的 HTML。
正確做法：需要排版效果時，把標籤寫進樣板本身，變數只放在標籤內部當成純文字內容，例如 ${f.finding_title} 會正常加粗顯示變數值。這個欄位仍然只應該由 能設計流程的人填入樣板，不要把整段訊息內容直接綁到一般使用者可自由載入、未經設計者過目的來源—— 雖然變數帶進來的 HTML 標籤現在不會被執行，但仍可能塞入大量文字或非預期字元影響版面。

沒有要求已讀時，彈窗會反覆跳出，而且沒有辦法讓它提早消失
症狀：使用者按了「關閉」，過一陣子（換頁、重新整理、或下一次輪詢）同一則廣播又跳出來。
原因：「需要已讀確認」關掉時，對話框的「關閉」按鈕只是把當前畫面上的彈窗移除， 不會呼叫任何確認 API；只要平台端這筆廣播記錄仍是啟用狀態，下一次輪詢查到同一個人 還沒有確認紀錄，就會再跳出來一次。
正確做法：如果希望使用者「看過一次就不再跳出」，把「需要已讀確認」打開，讓關閉動作真的留下 確認紀錄。如果只是想要一則低干擾、看過就算、不需要持續提醒的訊息，這個節點其實不是最合適的選擇， 跑馬燈廣播更貼近這種語意。

沒有任何介面或 API 能手動停用一則已發送的緊急廣播
症狀：流程設計錯誤、或內容打錯字，想把已經發出去的廣播立刻收回，卻找不到停用或刪除的按鈕。
原因：「緊急廣播管理」頁面只能查看每一則廣播的已讀／未讀名單與統計，沒有 停用、刪除或撤回的功能；這個節點本身也沒有內建的有效期限欄位。要讓一則廣播對所有人都消失， 唯一可靠的辦法是每個人各自完成已讀確認（僅在「需要已讀確認」開著、且使用者主動點擊確認時才會生效）， 或是由有資料庫存取權限的人直接介入停用該筆記錄。
正確做法：送出前務必先確認內容正確；設計流程時若擔心誤觸發，可以考慮先接一個需要人工核准的 關卡再觸發這個節點，而不是依賴事後能夠收回。跑馬燈廣播（NavbarBroadcast）在這一點上 不同：它可以設定到期時間自動失效，也有對應的「結束」模式可以主動關閉。

指定對象時忘記勾角色或部門，等同沒有任何人看得到
目標對象選了「指定對象」，卻沒有勾選任何角色、也沒有勾選任何部門時，這則廣播實際上不會被推送給 任何人——目標過濾邏輯在角色與部門清單都是空的情況下，判定結果就是「不在目標範圍內」。角色與部門是 OR 關係（命中其中之一即可），「包含子部門」只影響部門的展開範圍，不影響角色。

7. 在 node展覽館 實際操作

對應「NT-24 AlertBroadcast 示範」。流程：送出表單後立即觸發一則對全企業使用者的緊急廣播 （target_type=all，require_ack=true），標題與內容取自表單欄位； 接著把本次流程執行代碼寫回表單的另一個欄位，用來對照示範「同一種 ${wi.exec_code} 變數語法，在一般欄位裡會被替換，但在廣播代碼裡不會」；最後接一個自簽的確認關卡收尾。

操作方式：到表單中心開啟「NT-24 AlertBroadcast 示範表單」送出，切換到平台任一頁面，最長等 1 分鐘（前端輪詢週期）就會跳出全頁強制彈窗，內容是表單裡填的標題與內文，開頭固定標示示範字樣以避免 被誤認為真的系統公告。捲到底、勾選「我已閱讀並知悉以上訊息」後按「已知道」即可關閉。

要直接對照「廣播代碼沒有被替換」這件事，可以查詢廣播記錄的代碼欄位——會看到代碼裡原封不動含有 字面上的 ${wi.exec_code}，而不是被換成實際的執行代碼。示範用完之後，這一則廣播不會 自動消失（見「6. 注意事項」），需要由有資料庫存取權限的人手動停用該筆記錄。

8. 相關節點

• 防禦決策（DecisionWriter）：常見的搭配對象——寫入封鎖 決策之後緊接一則通報，讓相關人員知道剛剛做了什麼處置。
• 簽核（FormAdapter）：計時催辦與升級通報的目的通常就是提醒 某個簽核關卡逾時未處理。
• 暫停（Delay）：SLA 催辦與升級通報前，先用這個節點計時等待一段 時間再檢查有沒有人處理。
• 寫入欄位（OpFieldWrite）：這個節點不寫流程變數，需要把 「已觸發廣播」這類說明留在表單上時，改用這個節點寫回表單欄位。