n8n 電子郵件審核工作流程：核准後續處理與測試清單

「核准」按鈕留下了一個重要的問題：被核准的內容究竟是什麼？我正在建立一個由我個人營運、自行託管的 n8n 系統，並輔以 AI 協助。研究和草擬的內容會進入審核佇列，而客戶電子郵件則需要我的核准。這是我自己的專案，並非付費客戶的案例研究。

螢幕截圖中的流程顯示了待處理草稿查詢、重複聯絡人檢查、Gmail 核准請求，以及一個明確的核准分支。在寄送之前，它會重新讀取已核准的資料列，並驗證核准的快照。

後續追蹤會進行新的執行緒檢查，而寄送路徑則會記錄收據。被拒絕、過期的核准以及測試執行都有獨立的分支。這些都是實作步驟，並不能證明所有失敗情況都已解決，特別是寄送收據不等於實際送達證明。

以下是我會納入核准工作流程測試計畫的六種情境。首先，如果核准後收件人變更或訊息變更，應停止並請求重新核准。其次，若核准連結被點擊兩次，不應建立第二次寄送；若核准過期，則不應寄送。最後，如果執行在寄送步驟附近停止，應在重試前協調結果，而非盲目重寄；若收件人在追蹤前回覆，則應阻止該排隊的追蹤。

請使用合成聯絡人或您控制的信箱進行這些測試。對於每個案例，請記錄輸入、預期結果、實際結果和執行證據。這是一份建議的檢查清單，並非聲稱我的專案已通過所有這六項測試。

我特別感興趣的部分是，如果執行在錯誤的時刻停止，本地的「正在寄送」狀態本身無法證明電子郵件供應商那裡發生了什麼事。在您的 n8n 電子郵件工作流程中，您如何處理這種不確定的結果，尤其是在供應商沒有寄送冪等鍵（send-idempotency key）的情況下？在允許重試之前，您需要什麼證據？上方螢幕截圖顯示了我的工作流程畫布，其中核准分支已放大。它說明了結構，而非執行追蹤。