解決方案手冊
Make 存取申請風險審查迴圈的規劃指南，包含設定、Jodoo 欄位、驗證記錄與推出注意事項。
開啟手冊MAKE + JODOO
使用 Make + Jodoo 進行 AI 存取申請風險審查
了解 Make 與 Jodoo 如何處理存取申請風險審查：審查來源申請、回傳結構化決策欄位、將結果寫入 Jodoo，並讓負責人、狀態與下一步行動保持可見。
1
使用一致的評估準則審查存取申請資料
2
將風險等級、政策例外、簽核路徑、建議審查人、開通狀態、到期日與下一個最佳行動寫入 Jodoo
3
讓負責人佇列與後續追蹤狀態保持可見
4
在將工作流程調整為生產來源之前，先使用 Make 驗證結果
5
公開驗證使用 Make Run once 模式，因此擷取的截圖可在情境歷程中顯示 webhook bundle、模組泡泡、操作次數與 HTTP 回應。
影片導覽
Make 示範中會發生什麼事
影片展示 Make 如何處理財務分析工作區的存取申請進入工作流程，內容包含申請人、部門、申請角色、業務理由、政策例外與緊急程度脈絡，接著由 Jodoo 儲存營運記錄。
Custom webhook 接收申請
財務分析工作區的存取申請進入工作流程，內容包含申請人、部門、申請角色、業務理由、政策例外與緊急程度脈絡。
Make 準備結構化審查欄位
工作流程會明確保留風險等級、政策例外、簽核路徑、建議審查人、開通狀態、到期日與下一個最佳行動，而不是回傳鬆散的段落文字。
HTTP 模組寫入 Jodoo
已測試的執行會將審查輸出送至 Jodoo，並從橋接端收到 Jodoo 資料 ID。
Make 驗證結果可檢視
公開驗證使用 Make Run once 模式，因此擷取的截圖可在情境歷程中顯示 webhook bundle、模組泡泡、操作次數與 HTTP 回應。
Jodoo 保留團隊記錄
Jodoo 應用程式會儲存申請人、部門、申請系統、申請角色、存取類型、業務理由與風險等級，供審查與後續追蹤使用。
展示摘要
Make 審查申請，Jodoo 追蹤後續處理
此實作適合需要可視化情境畫布、Run once 測試與模組歷程的營運團隊。此頁面會保留可視化情境設定、實際執行，以及 Jodoo 回寫結果。HTTP 模組證據是可視化的：方法、端點、body 類型、已解析回應與完成狀態，都可在不開啟程式碼編輯器的情況下檢視。
Make 情境
Make Custom webhook 接收範例 payload，並由 HTTP 模組將結構化欄位送入 Jodoo。
結構化決策
工作流程會針對財務分析工作區回傳風險等級、政策例外、簽核路徑、建議審查人、開通狀態、到期日與下一個最佳行動。
Make 成功執行
Make 執行歷程會顯示 HTTP 模組完成狀態、操作詳細資料，以及 Jodoo 資料 ID 回應。
Make 實作細節
先從 Custom webhook 開始，貼上範例申請，讓 Make 推斷 bundle，再將決策欄位對應到 HTTP 模組 body。
存取申請配方細節
針對存取申請風險審查，在 HTTP 模組寫入 Jodoo 前，Make bundle 會讓申請人、部門、目標應用程式、申請角色、理由與政策例外欄位保持可見。
Jodoo 回寫
Jodoo 會儲存存取申請記錄，並讓下一步行動保持可見。
營運後續追蹤
建議的下一步行動是將申請分派給資安團隊進行政策審查，並在開通前確認主管核准。
可重複使用套件
重點套件包含手冊、Jodoo 欄位藍圖與 Make 工作流程配方。
平台設定說明
Make 的特定特色
Jodoo 記錄模型可以維持一致，但各個代理平台的建置方式、測試檢視與正式上線交接流程各不相同。
設定驗證
此驗證使用 Run once，讓傳入的 bundle 與 HTTP 回應保持可見。
動作路徑
HTTP 模組讓方法、URL、body 類型與回應解析都可檢視。
配方重點
情境歷程會提供操作、持續時間與回寫回應的可視化記錄。
生產規劃
生產規劃應涵蓋 webhook 負責權、router、錯誤處理器與操作用量。
證據細節
公開驗證使用 Make Run once 模式，因此擷取的截圖可在情境歷程中顯示 webhook bundle、模組泡泡、操作次數與 HTTP 回應。
執行證據
HTTP 模組證據是可視化的：方法、端點、body 類型、已解析回應與完成狀態，都可在不開啟程式碼編輯器的情況下檢視。
建置細節
先從 Custom webhook 開始，貼上範例申請，讓 Make 推斷 bundle，再將決策欄位對應到 HTTP 模組 body。
實作路徑
當高價值合約、緊急發票或缺少資訊的案件需要不同 Jodoo 佇列時，請在基礎驗證後使用 router。
防護機制
在將 Run once 驗證轉為啟用中的工作流程前，請檢視操作用量、webhook 負責權與情境排程。
審查控制
在 HTTP 模組周圍加入錯誤處理器，讓失敗的回寫可以重試，或移至人工審查路徑。
情境配方
針對存取申請風險審查，在 HTTP 模組寫入 Jodoo 前，Make bundle 會讓申請人、部門、目標應用程式、申請角色、理由與政策例外欄位保持可見。
工作流程調整
在第一次回寫驗證穩定後，可使用 router 分流低風險存取變更、需要主管核准的申請，以及需資安審查的例外。
工作流程工具包
建立相同的存取申請風險審查迴圈
檢視手冊、複製工作流程配方，並在調整 Make 工作流程時使用 Jodoo 欄位模型。
可重複使用的工作流程
工作流程負責判斷，Jodoo 讓工作持續推進。
- 01
Custom webhook
以財務分析工作區啟動存取申請測試。先從 Custom webhook 開始，貼上範例申請，讓 Make 推斷 bundle，再將決策欄位對應到 HTTP 模組 body。
- 02
Make 情境
Make Custom webhook 接收範例 payload，並由 HTTP 模組將結構化欄位送入 Jodoo。
- 03
HTTP 模組
將結構化 JSON 傳送至 Jodoo 回寫橋接端。HTTP 模組證據是可視化的：方法、端點、body 類型、已解析回應與完成狀態，都可在不開啟程式碼編輯器的情況下檢視。
- 04
驗證回應
顯示成功的平台執行與 Jodoo 資料 ID。公開驗證使用 Make Run once 模式，因此擷取的截圖可在情境歷程中顯示 webhook bundle、模組泡泡、操作次數與 HTTP 回應。
- 05
Jodoo 佇列
儲存負責人審查、狀態追蹤與後續處理所需欄位。在將 Run once 驗證轉為啟用中的工作流程前，請檢視操作用量、webhook 負責權與情境排程。
工作流程循環
從 Make 存取申請風險審查到 Jodoo
Custom webhook 會先使用合成資料接收或啟動存取申請風險審查。
Make 套用聚焦的審查指令，並回傳風險等級、政策例外、簽核路徑、建議審查人、開通狀態、到期日與下一個最佳行動。
HTTP 模組將結構化輸出送至 Jodoo 回寫橋接端，並接收資料 ID。
針對存取申請風險審查，在 HTTP 模組寫入 Jodoo 前，Make bundle 會讓申請人、部門、目標應用程式、申請角色、理由與政策例外欄位保持可見。
在第一次回寫驗證穩定後，可使用 router 分流低風險存取變更、需要主管核准的申請，以及需資安審查的例外。
情境歷程是 IT 營運的重要驗證依據，因為它會顯示每個模組、操作次數、回應 body，以及已接受的 Jodoo 資料 ID。
驗證完成後，Make 可以加入通知、簽核分支，以及開通交接失敗時的錯誤處理器。
先從 Custom webhook 開始，貼上範例申請，讓 Make 推斷 bundle，再將決策欄位對應到 HTTP 模組 body。
當高價值合約、緊急發票或缺少資訊的案件需要不同 Jodoo 佇列時，請在基礎驗證後使用 router。
Jodoo 會建立存取申請追蹤器記錄，並儲存申請人、部門、申請系統、申請角色、存取類型、業務理由、風險等級與政策例外。
團隊會檢視佇列、指派負責人，並完成下一步行動：將申請分派給資安團隊進行政策審查，並在開通前確認主管核准。
在將 Run once 驗證轉為啟用中的工作流程前，請檢視操作用量、webhook 負責權與情境排程。
在 HTTP 模組周圍加入錯誤處理器，讓失敗的回寫可以重試，或移至人工審查路徑。
欄位對應
代理輸出轉為 Jodoo 欄位
| 代理或來源資料 | Jodoo 記錄欄位 |
|---|---|
| 來源申請詳細資料 | 申請人、部門、申請系統、申請角色 |
| 審查決策欄位 | 風險等級、政策例外、簽核路徑、建議審查人、開通狀態 |
| 工作流程回應 | 來源平台、原始工作流程輸出 |
AI 代理配方
提示詞與結構化輸出
Make 角色
審查一筆存取申請風險審查申請，並回傳 Jodoo 可儲存、分派與報表化的結構化欄位。先從 Custom webhook 開始，貼上範例申請，讓 Make 推斷 bundle，再將決策欄位對應到 HTTP 模組 body。
審查指令
使用財務分析工作區的範例脈絡，判定風險等級、政策例外、簽核路徑、建議審查人、開通狀態、到期日與下一個最佳行動，並讓建議的下一步行動保持具體。針對存取申請風險審查，在 HTTP 模組寫入 Jodoo 前，Make bundle 會讓申請人、部門、目標應用程式、申請角色、理由與政策例外欄位保持可見。
回寫合約
透過 HTTP 模組傳送可預測的 JSON 物件；Jodoo 每次執行都應收到相同欄位名稱。當營運團隊想用畫布、篩選器、router 與模組層級執行歷程說明交接時，Make 會很有幫助。
必要輸出
回傳風險等級、政策例外、簽核路徑、建議審查人、開通狀態、到期日與下一個最佳行動、source_platform、agent_confidence，以及用於稽核脈絡的原始工作流程輸出。
Make 控制項
在將 Run once 驗證轉為啟用中的工作流程前，請檢視操作用量、webhook 負責權與情境排程。在 HTTP 模組周圍加入錯誤處理器，讓失敗的回寫可以重試，或移至人工審查路徑。記錄誰負責 webhook URL，以及誰可編輯承載生產申請資料的模組。
存取申請實作注意事項
針對存取申請風險審查，在 HTTP 模組寫入 Jodoo 前，Make bundle 會讓申請人、部門、目標應用程式、申請角色、理由與政策例外欄位保持可見。在第一次回寫驗證穩定後，可使用 router 分流低風險存取變更、需要主管核准的申請，以及需資安審查的例外。情境歷程是 IT 營運的重要驗證依據，因為它會顯示每個模組、操作次數、回應 body，以及已接受的 Jodoo 資料 ID。驗證完成後，Make 可以加入通知、簽核分支，以及開通交接失敗時的錯誤處理器。
{
"requester": "Maya Chen",
"department": "Finance",
"requested_system": "Finance analytics workspace",
"requested_role": "Analyst",
"access_type": "New access",
"business_justification": "Quarter-end reporting and variance analysis",
"risk_level": "Medium",
"policy_exception": "Requires manager approval before provisioning",
"approval_route": "Manager then Security",
"suggested_reviewer": "Security Operations",
"provisioning_status": "Pending approval",
"due_date": "2026-06-12",
"next_best_action": "確認主管核准，並轉交資安團隊審核"
}Jodoo 入門應用程式
存取申請入門應用程式
為團隊調整存取申請風險審查工作流程時，可使用此欄位模型、檢視與自動化。
包含的欄位
- 申請人
- 部門
- 申請系統
- 申請角色
- 存取類型
- 業務理由
- 風險等級
- 政策例外
- 簽核路徑
- 建議審查人
- 開通狀態
- 到期日
- 下一個最佳行動
- 來源平台
- 原始工作流程輸出
建議檢視
- 待存取審查
- 資安審查佇列
- 主管簽核佇列
- 可進行開通
- 所有存取申請
自動化規則
- Make 回傳結構化輸出後，建立一筆 Jodoo 記錄。
- 將高優先級或例外記錄移至正確的負責人佇列。
- 當缺少資訊或有暫緩原因時，通知建議負責人。
- 在稽核脈絡中保留原始工作流程輸出。
上線檢查清單
正式上線前需確認的事項
- 啟用情境前，先將合成資料送至 Custom webhook。
- 編輯後重新開啟 HTTP 模組，確認已儲存的 JSON 對應。
- 使用情境歷程確認狀態、操作與回應 body。
- 只有在基礎回寫穩定後，才加入 router、篩選器與通知。
- 在將 Run once 驗證轉為啟用中的工作流程前，請檢視操作用量、webhook 負責權與情境排程。
- 在 HTTP 模組周圍加入錯誤處理器，讓失敗的回寫可以重試，或移至人工審查路徑。
- 記錄誰負責 webhook URL，以及誰可編輯承載生產申請資料的模組。
- 在第一次回寫驗證穩定後，可使用 router 分流低風險存取變更、需要主管核准的申請，以及需資安審查的例外。
- 情境歷程是 IT 營運的重要驗證依據，因為它會顯示每個模組、操作次數、回應 body，以及已接受的 Jodoo 資料 ID。
- 驗證完成後，Make 可以加入通知、簽核分支，以及開通交接失敗時的錯誤處理器。
工作流程
從 Make 存取申請到 Jodoo 記錄
Make 處理可視化情境；Jodoo 保留團隊可篩選、指派與審查的記錄。
Custom webhook 會先使用合成資料接收或啟動存取申請風險審查。
Make 套用聚焦的審查指令，並回傳風險等級、政策例外、簽核路徑、建議審查人、開通狀態、到期日與下一個最佳行動。
HTTP 模組將結構化輸出送至 Jodoo 回寫橋接端，並接收資料 ID。
針對存取申請風險審查，在 HTTP 模組寫入 Jodoo 前，Make bundle 會讓申請人、部門、目標應用程式、申請角色、理由與政策例外欄位保持可見。
在第一次回寫驗證穩定後，可使用 router 分流低風險存取變更、需要主管核准的申請，以及需資安審查的例外。
情境歷程是 IT 營運的重要驗證依據，因為它會顯示每個模組、操作次數、回應 body，以及已接受的 Jodoo 資料 ID。
驗證完成後，Make 可以加入通知、簽核分支，以及開通交接失敗時的錯誤處理器。
先從 Custom webhook 開始，貼上範例申請，讓 Make 推斷 bundle，再將決策欄位對應到 HTTP 模組 body。
當高價值合約、緊急發票或缺少資訊的案件需要不同 Jodoo 佇列時，請在基礎驗證後使用 router。
Jodoo 會建立存取申請追蹤器記錄，並儲存申請人、部門、申請系統、申請角色、存取類型、業務理由、風險等級與政策例外。
團隊會檢視佇列、指派負責人，並完成下一步行動：將申請分派給資安團隊進行政策審查，並在開通前確認主管核准。
在將 Run once 驗證轉為啟用中的工作流程前，請檢視操作用量、webhook 負責權與情境排程。
在 HTTP 模組周圍加入錯誤處理器，讓失敗的回寫可以重試，或移至人工審查路徑。
Jodoo 記錄
Jodoo 儲存的內容
工作流程執行後，Jodoo 會保留長期可用的存取申請欄位：申請人、部門、申請系統、申請角色、存取類型、業務理由、風險等級、政策例外。
申請人部門申請系統申請角色存取類型業務理由風險等級政策例外簽核路徑建議審查人開通狀態到期日下一個最佳行動來源平台原始工作流程輸出
真實測試執行
Make 工作流程已將存取申請寫入 Jodoo
截圖使用合成資料，並展示 Make 設定、成功執行，以及由工作流程建立的 Jodoo 資料列。
Make 情境設定
Make Custom webhook 接收範例 payload，並由 HTTP 模組將結構化欄位送入 Jodoo。
Make 成功執行
Make 執行歷程會顯示 HTTP 模組完成狀態、操作詳細資料，以及 Jodoo 資料 ID 回應。
Jodoo 回寫
存取申請風險審查已寫入 Jodoo，並顯示申請人、部門、申請系統、申請角色、存取類型與業務理由欄位。
常見問題
常見問題
了解如何將代理平台搭配 Jodoo 記錄、工作流程與應用程式範本使用的相關解答。
這個 Make 存取申請風險審查是否已完成端到端測試？
是。此驗證使用合成資料、真實 Make 執行，以及含驗證清單的 Jodoo 回寫截圖。
為什麼使用 Make 進行存取申請風險審查？
當營運團隊需要可視化情境畫布、Run once 測試與模組歷程時，可使用 Make。接著由 Jodoo 保留可長期使用的記錄，用於審查與後續追蹤。
這個 Make 實作與其他平台範例有何不同？
公開驗證使用 Make Run once 模式，因此擷取的截圖可在情境歷程中顯示 webhook bundle、模組泡泡、操作次數與 HTTP 回應。先從 Custom webhook 開始，貼上範例申請，讓 Make 推斷 bundle，再將決策欄位對應到 HTTP 模組 body。針對存取申請風險審查，在 HTTP 模組寫入 Jodoo 前，Make bundle 會讓申請人、部門、目標應用程式、申請角色、理由與政策例外欄位保持可見。
工作流程執行後，Jodoo 會儲存什麼？
Jodoo 會儲存申請人、部門、申請系統、申請角色、存取類型、業務理由、風險等級、政策例外、簽核路徑、建議審查人，以及用於稽核脈絡的原始工作流程輸出。
之後可以連接生產來源資料嗎？
可以。先從已驗證的合成資料執行開始，等存取申請風險審查 schema 穩定後，再連接表單、入口網站、收件匣、API 或內部系統。當高價值合約、緊急發票或缺少資訊的案件需要不同 Jodoo 佇列時，請在基礎驗證後使用 router。
哪些內容仍應由團隊審查？
工作流程可以準備決策欄位，但負責人仍應審查業務風險、付款或法務核准，以及最終營運決策。請記錄誰負責 webhook URL，以及誰可編輯承載生產申請資料的模組。
下一步
將存取申請轉為可追蹤的後續處理
先從一次已驗證的 Make 執行開始，再將相同回寫模式重複用於相鄰的審查佇列與營運交接。在將 Run once 驗證轉為啟用中的工作流程前，請檢視操作用量、webhook 負責權與情境排程。