Automation ควรหยุดตรงไหนเมื่อข้อมูลไม่ครบ

เขียน Stop Conditions ก่อนเขียน Happy Path

ก่อนทำ flow ให้ระบุเงื่อนไขที่ต้อง “ไม่ทำต่อ” เช่น missing required field, identity conflict, amount outside tolerance, duplicate uncertainty, permission missing หรือ downstream unavailable จากนั้นกำหนด action ของแต่ละ stop: fail, wait, create task หรือ human review

การเขียน stop conditions ล่วงหน้าช่วยให้ทีมไม่เติม default ที่ดูสะดวกแต่ผิดความจริง เช่น supplier ไม่ทราบแล้วเลือก “Misc Vendor” เพื่อให้ workflow ผ่าน หรือยอดไม่ตรงแล้วปัดทิ้งโดยไม่มี owner

Waiting เป็นสถานะปกติของงาน ไม่ใช่ failure เสมอไป

บางงานรอเอกสาร รอ approval หรือรอเวลาที่เหมาะสมจึงควรอยู่ Waiting พร้อม deadline, owner และ resume condition n8n execution history แยกสถานะ Running, Success, Failed และ Waiting ซึ่งสะท้อนว่า workflow สามารถหยุดรอโดยยังเป็น execution ที่ติดตามได้

ออกแบบว่าเมื่อ timeout แล้วจะเตือนใคร retry ได้กี่ครั้ง และเมื่อใดเปลี่ยนจาก Waiting เป็น Failed/Manual Review เพื่อไม่ให้รายการค้างเงียบตลอดไป

แหล่งอ้างอิง: [1]

งานที่มีผลกระทบสูงควรมี human approval ที่เห็นข้อมูลครบ

ตัวอย่างเช่น เปลี่ยนบัญชีธนาคาร supplier, อนุมัติจ่าย, override geofence หรือบันทึกรายการที่ confidence ต่ำ ควรหยุดก่อน action สำคัญและแสดง context, evidence, proposed action และผลกระทบให้ผู้อนุมัติเห็น ไม่ใช่ส่งเพียงปุ่ม Approve ไม่มีข้อมูล

n8n รองรับ pattern “send and wait for approval” ในบาง integration และแนะนำ Wait node สำหรับ approval ที่ซับซ้อนกว่า ตัวอย่างนี้แสดงว่ามนุษย์สามารถเป็น state ใน workflow โดยไม่ต้องทำงานนอกระบบแบบไร้ร่องรอย

แหล่งอ้างอิง: [2]

Retry ต้องไม่สร้างผลซ้ำ

ก่อน retry action ที่มี side effect เช่นสร้าง invoice ส่งคำสั่งซื้อหรือแจ้งเตือน ให้มี idempotency key หรือ lookup ว่าคำสั่งเดิมสำเร็จไปแล้วหรือไม่ เพราะ timeout ฝั่ง caller ไม่ได้แปลว่า server ปลายทางไม่ทำงาน

แยก retryable error เช่น network timeout จาก business error เช่น invalid supplier หรือยอดไม่ตรง Business error ไม่ควรถูกยิงซ้ำทุกนาที แต่ควรเข้าสู่ exception queue ให้แก้ข้อมูลต้นเหตุ

เก็บ execution evidence เพื่ออธิบายว่าทำไมระบบหยุดหรือเดินต่อ

สำหรับแต่ละ run เก็บ workflow/version, trigger identity, input reference, decisions, retries, error category และ final outcome โดยหลีกเลี่ยงการ log secret หรือข้อมูลเกินความจำเป็น n8n execution history สามารถใช้ดูและ retry failed workflows ได้ จึงควรกำหนด retention และสิทธิ์เข้าถึงตามความเสี่ยง

เมื่อ automation ทำงานผิด ทีมควรตอบได้ว่า input ใดทำให้เข้า branch นี้ rule version ไหนทำงาน และคนใดอนุมัติการ resume การมี log เพียง “workflow failed” ไม่พอสำหรับงานที่ต้องตรวจสอบย้อนหลัง

แหล่งอ้างอิง: [1]

นำไปใช้กับธุรกิจของคุณ

Automation ที่เชื่อถือได้ไม่ได้วัดจากเปอร์เซ็นต์งานที่ไม่มีคนแตะ แต่จากความสามารถในการเดินต่อเมื่อข้อมูลพอ หยุดเมื่อไม่พอ และอธิบายได้ว่าทำไมแต่ละรายการจึงอยู่ในสถานะนั้น