Form Submissions
當 Agent 用了 Request Form 來收集結構化資訊時，Form Submissions 就會變得重要。
如果你的 Agent 還沒用表單，這一頁保持空白是正常的。
這一頁是拿來做什麼的
當對話從自由聊天，進到結構化 intake 時，這一頁就會開始發揮作用。
對 Consultation Desk 來說，常見的是：
- callback 的聯絡資訊
- 偏好的後續聯繫時段
- 不想再靠聊天手動整理的 intake 資料
Operator 會怎麼用它
當 submission 開始進來後，這一頁就會變成一個營運待辦區：
- 看使用者到底提交了什麼
- 確認資訊是否完整
- 交給正確的人工作業流程
查看通知行為
唯讀通知摘要會依目前篩選條件調整。選擇 所有表單 時，摘要會顯示工作區規則的狀態與目的地，以及有個別設定的表單數量；選擇特定表單時，則顯示該表單目前使用工作區預設、自訂目的地或不發送通知，以及真正會收到通知的目的地。選擇 管理工作區通知，即可在工作區通知直接打開 已送出表單 事件。
該頁的規則編輯器只能選取工作區目錄中已存在且相容的目的地。表單回覆頁面不提供通知目的地管理功能。
若要新增、編輯、測試、驗證、啟用、停用或刪除目的地，請使用工作區通知的 目的地 分頁。
表單送出規則支援下列目的地類型：
Slack Incoming Webhook：把格式化後的 submission 訊息送到 Slack channel。Slack Workflow Webhook：把欄位以 key-value payload 送進 Slack Workflow。Email：把 submission notification 寄到已驗證的 Email 地址。
設定 Email 目的地後，請從 目的地 傳送驗證信並打開驗證連結，再把它當成正式通知管道。修改 Email 地址後必須重新驗證。設定完成後，用測試通知確認目的地可以正常運作。
在表單通知規則中取消選取目的地並儲存後，該規則就不會再路由到此目的地。若這是其他規則共用的目的地，不會因此被刪除。
Slack Workflow payload keys
每個 form field 都會成為 top-level payload key：
- 優先使用 field label 作為 key；如果 label 是空的，則使用 field name。
- 如果多個 field 產生相同 key，較後面的值會覆蓋先前的值。
- Codeer 也會加入
event_type、form_name、form_request_id、submitted_at、submitted_by_external_user_id、workspace_name、workspace_id、agent_name與agent_id。
連接 Workflow 前，請先到 Agent settings → Tools → Request Form → Open Form Builder，為 field 設定穩定且不重複的 label。
Identity masking 不會改寫 notification payload
Form Submission notification 會把使用者提交的 form field 送到外部 destination，也可能包含原始 submitted_by_external_user_id。Mask end-user identity 保護的是 workspace UI response，不會取代 notification payload 裡的 identity value。請只使用有權接收這些 end-user data 的 destination。
Webhook URL 必須保密
Slack webhook URL 是 secret。不要把它貼到公開文件、issue comment、screenshot 或 source code。
如果頁面是空的
頁面是空的，通常代表下面其中之一：
- Agent 還沒用
Request Form - 表單存在，但還沒有人真的觸發它
- rollout 還太早，還沒產生 submission