今天會開始把每個使用到的Node進行介紹，先從必定唯一的Start Node開始。

1. 這個節點做什麼

開始（Start）是每一個流程模板固定唯一的入口節點。使用者在表單中心送出表單、外部系統以 API Key 呼叫觸發端點發動流程、或資安事件建案這類流程觸發方式，最終都會走到同一段程式：先建立表單實例與 流程實例，再以 Start 節點的圖形節點資料建立第一筆執行佇列項目（狀態 PENDING）， 之後才由這個節點的處理器接手，執行完立即（同一輪）依出線推進到下一個節點。它與「這次送單」的關係是一對一： 每次送單都會建立一個全新的流程實例，並從 Start 重新出發，不會有兩次送單共用同一次 Start 執行紀錄的情況。

因為它是唯一入口，設計器把 Start 節點列為特例：右鍵選單不提供「替換節點」， Ctrl+C 複製會直接把它從選取範圍剔除並顯示「Start 節點不允許複製」， 刪除鍵對它也不生效。這確保每個流程模板固定只有一個起點。

這個節點不需要任何設定就能運作，設計器也沒有提供可以編輯的欄位。如果想在流程一開始就準備好幾個初始 流程變數，不要嘗試在 Start 上尋找設定入口——目前唯一的做法是緊接在 Start 後面接一個「設定變數（OpSet）」節點，把要準備的初始值寫在那裡。

2. 設定欄位

設計器沒有為 Start 提供任何設定面板：點選這個節點時，右側只會出現節點通用的「名稱」 「描述」欄位，不會像其他節點一樣多出專屬設定區塊。

3. 可用的變數與輸出

可讀取：執行 Start 的當下，表單實例與流程實例都已經建立完成， 所以 ${f.欄位}（表單欄位）、${fi.xxx}（表單資訊）、 ${wi.code|exec_code|name|status|depth}（流程實例資訊）都可以正常取值。 ${v.變數}（流程變數）要分兩種情況：

主流程的開始：永遠是空的，因為還沒有任何節點執行過、寫過任何值。
子流程的開始：只看得到上一層子流程節點「輸入參數（父流程 → 子流程）」對照表裡 映射過來的變數（以對照表右欄「子流程變數」的名稱讀取），這些值在開始節點執行之前就已經寫好； 上一層其他沒有列進對照表的流程變數，在子流程裡一律讀不到。詳見第 4 節「放在子流程裡時」。
寫出：Start 本身不寫入任何流程變數。它的執行結果只回報 {'status': 'success', 'data': {'started_at': 節點執行當下的 UTC 時間}}，這個 started_at 只存在於這顆節點自己的執行紀錄裡，不是流程變數，後面的節點無法用 ${v.started_at} 取得它。要在流程裡引用「流程何時開始」，需要自己在 Start 後面接一個 OpSet 節點寫入 ${t.now}，或直接查 fw_workflow_instances.started_at。

4. 出線行為

Start 沒有任何出線選擇邏輯：它一律回報執行成功，不會產出「挑選出線」用的資料， 所以引擎套用通用規則——取它的全部出線。實務上 Start 通常只接一條出線，但沒有限制它 接兩條以上；如果真的接了兩條以上，這些出線會同時被推進（與其他節點的通用並行規則一致）， 形成從流程一開始就並行的多條分支，不需要額外的並行節點。

Start 理論上不會執行失敗——它的處理邏輯裡沒有會主動拋出例外的分支， 除非發生資料庫連線中斷這類基礎設施層級的問題，否則不會看到它的狀態變成 FAILED。

4.1 放在子流程裡時：由上一層啟動，行為不變

結束（End）放在子流程裡會多做一層事（見 結束（End）第 4 節），開始節點則沒有對應的特殊邏輯： 它的處理器不會判斷自己是在主流程還是子流程，執行內容與主流程完全相同。父子流程切換的工作分別由 上一層的子流程（SubFlow）節點與子流程裡的 End 負責，開始節點只是被動地 「被排進佇列」：

1. 上一層流程走到子流程節點時，該節點先建立一個新的子流程實例（${wi.depth} 比上一層多 1、 ${wi.exec_code} 是上一層代號加上 -SUB<層數>-<節點編號> 後綴）， 接著把「輸入參數（父流程 → 子流程）」對照表裡的變數逐一寫成整棵流程樹共用的變數， 最後只把子流程 graph 裡型別為 Start 的節點排進執行佇列，其他節點都不排。 子流程模板沒有開始節點時，什麼都不會被排進佇列，子流程不會執行，上一層的子流程節點會停在等待狀態。
2. 子流程的開始節點被執行時，做的事與主流程一模一樣：記錄啟動、回報成功、取全部出線推進。
3. 子流程裡的 End 要回頭找「是上一層哪一顆子流程節點呼叫我的」，靠的就是第 1 步排進佇列的那筆 開始節點紀錄（上面記著呼叫它的上一層實例與節點）。這是資料層的關聯，設計者看不到也不需要設定， 但它解釋了為什麼子流程模板一定要有開始節點：沒有它，子流程既起不來、結束時也找不到回去的路。

子流程與主流程共用同一張表單（同一個表單實例），所以子流程開始節點之後的節點讀 ${f.欄位}、${fi.xxx} 拿到的是同一份資料；只有流程變數是各層獨立、只透過對照表傳遞。

5. 常見設計方式

5.1 最小可行流程（取自 node展覽館 NT-01，請安裝後到範例企業 DemoSOC 的流程設計）

5.2 銜接第一個資料整理節點（取自 SOC 團隊版）

6. 注意事項

在 config 塞了 init.variables，流程變數卻查無此值
症狀：用腳本或 API 直接把 init.variables 寫進流程模板的 graph JSON， 跑完流程後查 fw_workflow_variables 完全找不到對應的值，也沒有任何錯誤訊息。
原因：處理器目前只會針對這個鍵逐項寫一行日誌，並未真正呼叫變數服務把值存起來。
正確做法：要建立初始流程變數，一律在 Start 後面接一個 「設定變數（OpSet）」節點，這是目前平台上唯一會把值真的寫進流程變數的方式。

想放第二個 Start 當備用入口
症狀：在設計器裡試著複製 Start、或用右鍵想刪除、替換這個唯一的入口， 操作都被擋下並顯示警告。
原因：設計器把 node-Start 這個節點 ID／Start 這個型別列為特例， 複製、刪除、替換三個操作都在前端直接擋掉。
正確做法：流程只能有一個入口；如果想「依情境走不同開頭」，應該在 Start 之後接 Branch 做分流，而不是想辦法多開一個入口。

以為 started_at 是可以引用的流程變數
症狀：後面的節點用 ${v.started_at} 想引用「流程開始時間」，卻讀不到任何值。
原因：started_at 只寫進 Start 這顆節點自己的執行紀錄， 從來沒有任何節點把它同步成流程變數。
正確做法：需要在流程裡引用開始時間，接一個 OpSet 節點自己寫入 ${t.now}（如 node展覽館 NT-01 示範的 start_time 變數）， 或直接查 fw_workflow_instances.started_at。

子流程一開始就想引用上一層設定好的流程變數，卻讀到空值
症狀：上一層流程在子流程節點之前用「設定變數（OpSet）」寫了一個變數， 子流程裡緊接開始節點的第一個節點用 ${v.那個變數} 引用，得到空字串，沒有任何錯誤訊息。
原因：每一層流程的流程變數是獨立的，子流程不會自動看到上一層的變數；只有子流程節點面板 「輸入參數（父流程 → 子流程）」對照表列出的變數，才會在子流程的開始節點執行前先寫進整棵流程樹共用的區域。
正確做法：在上一層的子流程節點面板把要傳的變數加進「輸入參數」對照表，左欄填上一層的變數名、 右欄填子流程要用的名稱，子流程一律用右欄的名稱引用。反過來要把子流程的結果帶回上一層， 不要依賴面板上的「輸出參數（子流程 → 父流程）」對照表——目前沒有任何程式會套用它； 上一層能拿到的只有子流程 End 寫回的結束方式變數，見 結束（End）第 4 節。

7. 在 node展覽館 實際操作

對應示範「NT-01 Start 示範」。它是全平台最小的可跑流程：Start → 設定變數 （OpSet，寫入 started_by_flow 與 start_time 兩個示範變數） → End（finish_mode=detach）。到表單中心「填寫表單」找到「NT-01 Start 示範表單」送出（表單只有一個非必填的備註欄位），送出後幾乎立刻完成：查 fw_workflow_instances 應該立刻看到一筆新實例，execution_code 是這次 送單的可辨識代號，狀態很快變成 COMPLETED；查 fw_workflow_variables 可以看到 started_by_flow 與 start_time 兩個變數，證明流程確實是從 Start 一路推進過來的——而不是靠 Start 自己的 init.variables。

8. 相關節點

• 設定變數（OpSet）：Start 之後最常接的第一個節點， 用來準備初始流程變數——Start 本身無法設定這件事。
• 結束（End）：流程的另一端點；任何流程模板最終都要走到這裡才算真正結束。
• 分支（Branch）：如果要在流程一開始就依條件分流，接在 Start 之後的是 Branch，而不是嘗試放第二個入口。
• 子流程（SubFlow，本系列尚未撰寫專篇）：啟動子流程的節點，它只會把子流程的 Start 排進佇列並傳入對照表裡的變數；子流程怎麼收尾、怎麼回到上一層，看 結束（End）第 4 節。兩篇對照著讀就是父子流程切換的完整分工。