Workflow

ภาพรวม

Workflow คือเครื่องมือสร้าง automation แบบลากวางบน canvas สำหรับงานหลายขั้นตอนต่อเนื่องกันที่กฎเดี่ยว ๆ ทำได้ยาก — ต้อนรับสมาชิกใหม่ ส่งคอนเทนต์เป็นชุด (drip) ดึงลูกค้าที่เงียบไปกลับมา หรือยิงข้อความติดตามผลหลังคลิกแคมเปญ หนึ่ง workflow คือกราฟที่เริ่มจากโหนด trigger แตกกิ่งผ่านโหนดเงื่อนไข/หน่วงเวลา/แบ่งสาขา แล้วไปจบที่โหนด action มีโหนดให้เลือกทั้งหมด 30 ชนิด จัดเป็น 7 กลุ่มในแถบซ้าย (ทริกเกอร์, เงื่อนไข, การกระทำ, การควบคุมโฟลว์, AI, แอป, ยูทิลิตี้)

กลไกสำคัญที่ต้องเข้าใจก่อนใช้งานคือ Workflow ไม่ได้ทำงานเป็นกราฟตอนรันจริง — เมื่อกดเปิดใช้งาน ระบบจะ "คอมไพล์" กราฟทั้งชุดให้แบนเป็นรายการ Trigger Rule ทีละแถวต่อหนึ่งเส้นทางจาก trigger ถึง action แล้ว worker เบื้องหลังทำงานตามกฎเหล่านั้น เข้าใจข้อนี้แล้วพฤติกรรมแปลก ๆ หลายอย่างของ Workflow จะอธิบายได้หมด

บทบาทที่ใช้งาน — แอดมิน OA ที่ต้องออกแบบเส้นทางการทำงานหลายขั้นตอน (เมนูนี้มีข้อควรทราบเรื่องสิทธิ์ที่ต่างจากเมนูอื่นในระบบ — อ่านหัวข้อ สิทธิ์การเข้าถึง ก่อนใช้งานจริง)

เส้นทางผู้ใช้งาน

1. ดูรายการ workflow

เปิดเมนู Workflow หน้ารายการเรียงจากใหม่ไปเก่าตามวันที่สร้าง ไม่มีช่องค้นหาและไม่มีตัวกรองสถานะ มีเพียงการแบ่งหน้า ตารางแสดง ชื่อ, สถานะ (ฉบับร่าง / เปิดใช้งาน / ปิดใช้งาน), โหนด (จำนวนโหนดในกราฟ), แก้ไขล่าสุด และปุ่มท้ายแถว 5 ปุ่ม — บันทึกกิจกรรม / แก้ไข / ทำสำเนา / เปิด-ปิดใช้งาน / ลบ

2. เริ่มสร้าง — จากศูนย์ จากเทมเพลต หรือให้ AI ร่าง

1. จากศูนย์ — ลากโหนดจากแถบซ้ายมาวางบน canvas แล้วลากเส้นเชื่อมกำหนดลำดับ (แถบเครื่องมือมีปุ่มสลับ โหมดเลื่อน / โหมดเลือก ให้ด้วย และมีปุ่ม ส่งออกเป็น PNG สำหรับบันทึกภาพกราฟไปใช้ประกอบเอกสาร)
2. จากเทมเพลต — กดปุ่ม ใช้เทมเพลต เลือกจาก 17 แบบสำเร็จรูป จัดเป็น 5 หมวด (Onboarding, Segmentation & Engagement, Campaign Attribution, Scheduled & Nurture, Appointment) — ชื่อเทมเพลตทั้งหมดเป็นภาษาอังกฤษเสมอ เพราะฝังไว้ในโค้ดไม่ผ่านระบบแปลภาษา
3. ให้ AI ร่าง — กดปุ่ม สร้างด้วย AI พิมพ์อธิบายสิ่งที่ต้องการเป็นภาษาปกติ ระบบส่งไปให้ AI ร่างกราฟกลับมา ถ้าช่องชื่อเวิร์กโฟลว์ยังว่างอยู่ AI จะตั้งชื่อให้ด้วย

ทั้งการเลือกเทมเพลตและการให้ AI ร่าง แทนที่กราฟทั้งผืนบน canvas ทันที ไม่ใช่การเพิ่มเข้าไป และไม่มีปุ่มย้อนกลับ — บันทึกงานเดิมให้เรียบร้อยก่อนกดสองปุ่มนี้เสมอ

3. ตั้งค่าโหนด

คลิกโหนดเพื่อเปิดแผงตั้งค่าด้านขวา ทุกการเปลี่ยนค่าในแผงนี้เขียนกลับเข้ากราฟบน canvas ทันที — แผงนี้ไม่มีปุ่มบันทึกของตัวเอง แต่นั่นไม่ได้แปลว่างานถูกบันทึกลงฐานข้อมูลแล้ว ยังต้องกดปุ่ม บันทึก ที่แถบเครื่องมือด้านบนอีกครั้ง

ตัวเลือกในแผงนี้ดึงมาจากเมนูอื่นในระบบทั้งหมด — Rich Message, Rich Menu, กลุ่มเป้าหมาย, merge tag, แคมเปญ Friends Track, แคมเปญที่ส่งแล้ว และคลังความรู้ (ดูรายละเอียดว่าดึงแบบมีเงื่อนไขอะไรในหัวข้อ เมนูที่เกี่ยวข้อง)

4. บันทึก

ปุ่มบันทึกที่แถบเครื่องมือเปลี่ยนข้อความตามสถานะ — ถ้ายังเป็นร่าง/ปิดใช้งานจะเป็น บันทึก แต่ถ้า workflow เปิดใช้งานอยู่ ปุ่มจะกลายเป็น บันทึกและคอมไพล์ใหม่ และกล่องยืนยันเตือนตรง ๆ ว่า "บันทึกและคอมไพล์เวิร์กโฟลว์ใหม่? … กฎการทริกเกอร์จะได้รับการอัปเดตทันที"

การบันทึกครั้งแรกของ workflow ใหม่จะพาไปหน้าแก้ไขของ workflow นั้นเลย (เพราะต้องมี id ก่อนจึงจะใช้ฟีเจอร์ทดสอบและประวัติเวอร์ชันได้)

5. ทดสอบก่อนเปิดใช้งาน

มีเครื่องมือทดสอบ 2 ตัว ที่ใช้งานได้ในจังหวะต่างกัน

• ทดสอบรัน (Test Run) — ใช้ได้ทันทีที่ workflow มี id (ยังเป็นร่างได้) ระบุ LINE user id ของผู้ใช้จริงใน OA นี้ ระบบเดินตามทุกเส้นทางในกราฟและรายงานผลรายเส้นทาง (เข้าเงื่อนไขหรือไม่ / ทำ action สำเร็จหรือไม่) มีโหมด dry run ให้เลือกด้วย — สำคัญมาก: ถ้าไม่ติ๊ก dry run ระบบจะทำ action จริงทุกอย่าง ดูรายละเอียดในหัวข้อจุดที่ควรระวัง
• ทดสอบแชท (Chat Sandbox) — จำลองการคุยกับ flow เสมือนเป็นผู้ใช้ ใช้ได้เฉพาะกับ workflow ที่เปิดใช้งานแล้วและมีโหนด "ข้อความที่ได้รับ" คู่กับตัวจำแนกความตั้งใจ (Intent Classifier) เท่านั้น ถ้ายังไม่เปิดใช้งาน sandbox จะตอบกลับเป็นข้อความว่ายังไม่พบกฎที่เปิดใช้งาน

6. เปิดใช้งาน

กดปุ่มเปิดใช้งาน หน้าเว็บตรวจความสมบูรณ์ของกราฟทั้งชุดก่อนด้วยกฎ 34 ข้อ — ถ้ามีข้อผิดพลาดจะขึ้นข้อความชี้ชื่อโหนดที่มีปัญหาและ ไม่ส่งคำขอไปที่เซิร์ฟเวอร์เลย ส่วนคำเตือน (เช่น "บางเส้นทางไม่นำไปสู่การกระทำ … เส้นทางเหล่านี้จะถูกละเว้น") จะแสดงแต่ ไม่บล็อก การเปิดใช้งาน

กฎที่เจอบ่อยได้แก่ ต้องมี trigger อย่างน้อยหนึ่งโหนดและ trigger ทุกตัวต้องมีเส้นขาออก, โหนดทุกตัว (ยกเว้นโหนดหมายเหตุและโหนดจบ) ต้องตั้งค่าแล้ว, โหนดเงื่อนไขต้องเชื่อมทั้งสาขา Yes และ No, โหนดหน่วงเวลาต้องมีสาขา "Completed" และหน่วงได้อย่างน้อย 1 นาที และ ห้ามต่อโหนดหน่วงเวลาสองตัวติดกัน (ยังไม่รองรับ), เปอร์เซ็นต์ของโหนด Split test ต้องรวมได้ 100% พอดี, กราฟต้องไม่มีการวนซ้ำ และโหนดที่ไม่ใช่ trigger ทุกตัวต้องมีเส้นขาเข้า

เมื่อผ่านแล้วเซิร์ฟเวอร์จะตรวจซ้ำอีกชั้น (ชุดที่สั้นกว่ามาก) แล้วคอมไพล์กราฟเป็น Trigger Rule พร้อมบันทึกเวอร์ชันเป็นเหตุการณ์ activate

7. จัดการเวอร์ชันและย้อนกลับ

กดปุ่ม ประวัติเวอร์ชัน ที่แถบเครื่องมือเพื่อเปิดแผงดูรายการเวอร์ชันทั้งหมด (เรียงจากใหม่ไปเก่า หน้าละ 20) เลือกเวอร์ชันเพื่อดูตัวอย่างกราฟ หรือกดย้อนกลับ (rollback) เพื่อนำนิยามของเวอร์ชันนั้นกลับมาใช้ ถ้า workflow เปิดใช้งานอยู่ ระบบจะคอมไพล์ Trigger Rule ใหม่ให้ตรงกับเวอร์ชันที่ย้อนกลับไปทันที

8. ดูประวัติการทำงานและสถิติรายโหนด

กดปุ่ม บันทึกกิจกรรม จากหน้ารายการ (หรือจากแถบเครื่องมือใน canvas) เพื่อเปิดหน้า logs — ค้นหา กรองสถานะ (สำเร็จ/ล้มเหลว) กรองชนิดโหนด และเลือกช่วงวันที่ได้ พร้อมแผงสรุปยอดทำงานรายโหนด ส่วนบน canvas เองก็มีตัวเลขสถิติซ้อนอยู่บนแต่ละโหนดให้เห็นว่าโหนดไหนทำงานไปกี่ครั้ง สำเร็จ/ล้มเหลวเท่าไร และมีกี่รายการค้างอยู่ในสถานะรอ

รายละเอียดสำคัญที่ตรวจสอบจากซอร์สโค้ดจริง

ยืนยันจาก internal/modules/workflow/{controller,service,executor,sandbox,ai}.go ของ line-management-cms-api-go และ src/components/workflow/ ของ cms-web-2026:

• การคอมไพล์แปลงกราฟเป็น "หนึ่ง Trigger Rule ต่อหนึ่งเส้นทาง" — สำหรับ trigger แต่ละตัว ระบบไล่หาทุกเส้นทางที่เดินไปจนถึงโหนด action แล้วยุบสิ่งที่อยู่ระหว่างทางลงเป็นค่าคอนฟิกของกฎแถวเดียว: โหนดเงื่อนไขกลายเป็นรายการเงื่อนไขเรียงกัน (สาขา "No" ถูกติดธง negate: true), โหนด Split test กลายเป็นเงื่อนไขช่วงเปอร์เซ็นต์ (cumulativeStart/cumulativeEnd), โหนด Multi-Split กลายเป็น "เงื่อนไขของสาขาก่อนหน้าทุกตัวถูก negate + เงื่อนไขของสาขานี้" และโหนดหน่วงเวลากลายเป็นก้อน delay ที่ฝังอยู่ในคอนฟิกของ action ไม่ใช่กฎแยกแถว กฎแต่ละแถวถูกตั้งชื่ออัตโนมัติเป็น "{ชื่อ workflow} - [{ป้ายของ trigger}] {ป้ายของ action}"
• หนึ่งเส้นทางคอมไพล์ได้เพียง action เดียว — และ action ตัวถัดไปจะ "ทับ" ตัวก่อนหน้าอย่างเงียบ ๆ — โค้ดคอมไพล์ยอมให้มี action ตัวที่สองได้ กรณีเดียว คือเมื่อตัวแรกเป็นโหนดเรียก API ภายนอก (action_web_request) โดยตัวที่สองจะถูกฝังเป็น postAction (หรือถ้าเป็นโหนดอัปเดต attribute ที่มี responseMappings จะถูกรวมเข้าด้วยกัน) นอกจากกรณีนี้ การต่อโหนด action สองตัวเรียงกัน จะทำให้ตัวแรกหายไปจากกฎที่คอมไพล์โดยไม่มีการเตือนใด ๆ ทั้งฝั่งหน้าเว็บและฝั่งเซิร์ฟเวอร์ไม่มีกฎตรวจข้อนี้ — ถ้าต้องส่งข้อความสองข้อความต่อกัน ให้แยกเป็นสองเส้นทางหรือใช้โหนดส่งข้อความแบบขั้นสูงแทน
• เส้นทางที่ไม่ได้ไปจบที่โหนด action จะถูกข้ามทั้งเส้น — คอมไพล์เลอร์ continue ทิ้งไปเลย หน้าเว็บเตือนไว้เป็นคำเตือน (ไม่บล็อก) ว่าเส้นทางเหล่านั้นจะถูกละเว้น ซึ่งตรงกับพฤติกรรมจริง
• การคอมไพล์ทุกครั้งลบกฎชุดเดิมที่ไม่ถูกสร้างซ้ำแบบ soft delete — หลังสร้างกฎชุดใหม่เสร็จ ระบบเทียบกับกฎเดิมทั้งหมดของ workflow นั้น แล้วประทับ deleted_date ให้ตัวที่ไม่อยู่ในชุดใหม่ — การไปแก้กฎในเมนู Trigger Rule ด้วยมือจึงถูกเขียนทับหายไปทุกครั้งที่บันทึกหรือเปิดใช้งาน workflow ครั้งถัดไป
• การตรวจของเซิร์ฟเวอร์ตอนเปิดใช้งานสั้นกว่าของหน้าเว็บมาก — ฝั่งเซิร์ฟเวอร์ตรวจแค่ 4 ข้อ: (1) นิยามต้องไม่ว่างและต้องมีทั้ง nodes และ edges, (2) ต้องมีโหนดที่ชนิดขึ้นต้นด้วย trigger อย่างน้อยหนึ่งตัว, (3) ต้องมีโหนดที่ชนิดขึ้นต้นด้วย action อย่างน้อยหนึ่งตัว, (4) โหนดทุกตัวยกเว้น annotation/exit ต้องมี config ที่ไม่ใช่อ็อบเจ็กต์ว่าง (ถ้าไม่ผ่านจะคืนชื่อโหนดที่ยังไม่ตั้งค่ามาให้) จากนั้นการตรวจการวนซ้ำของกราฟเกิดขึ้นในขั้นคอมไพล์ — กฎอีก 30 ข้อที่เหลือมีอยู่แค่ฝั่งหน้าเว็บ ใครเรียก API POST /workflows/:id/activate ตรงจะข้ามกฎเหล่านั้นได้ทั้งหมด
• การบันทึกของ workflow ที่เป็นร่างตรวจแค่ชื่อ — ฟังก์ชัน validateWorkflowForSave ตรวจเพียงว่าชื่อไม่ว่างเปล่า กราฟที่ยังไม่สมบูรณ์บันทึกเก็บไว้ได้เสมอ แต่ถ้า workflow เปิดใช้งานอยู่แล้ว การกดบันทึกจะรัน validation ชุดเต็ม 34 ข้อเหมือนตอนเปิดใช้งาน และฝั่งเซิร์ฟเวอร์จะคอมไพล์กฎใหม่ทันทีในคำขอเดียวกัน
• Test Run ที่ไม่ติ๊ก dry run เป็นการทำงานจริง ไม่ใช่การจำลอง — ตัวรัน (executor) เรียก executeAction ตรง ๆ ตามชนิด action ที่ระบุ: ส่งข้อความถึงผู้ใช้จริง สลับ Rich Menu ของผู้ใช้จริง เขียน attribute จริง เพิ่ม/ลบสมาชิกในกลุ่มเป้าหมายจริง และ ยิง HTTP request ออกไปที่ URL ที่ตั้งไว้จริงจาก cms-api เอง (timeout ตั้งค่าได้ ค่าเริ่มต้น 30 วินาที) โหมด dry run จะรายงานเพียงว่าเส้นทางนั้นเข้าเงื่อนไขหรือไม่ พร้อมผลลัพธ์ dry_run โดยไม่ทำ action ใด
• Test Run ข้ามโหนดหน่วงเวลาเสมอ — ในโหมด dry run จะขึ้นข้อความกำกับว่า "Delay node skipped in test run" แต่ในโหมดทำงานจริง โหนดหน่วงเวลาถูกละเลยไปเลย action ที่อยู่หลังการหน่วงเวลาจะทำงานทันที ผลของ Test Run จึงไม่สะท้อนจังหวะเวลาจริงของ flow
• Test Run รองรับ action เพียง 6 ชนิดจาก 10 ชนิดที่คอมไพล์ได้ — ตัวรันรู้จักแค่ send_message, switch_rich_menu, add_to_audience, remove_from_audience, update_attribute, web_request ส่วนโหนดที่ใหม่กว่า (ส่งข้อความแบบขั้นสูง, ส่งต่อให้เจ้าหน้าที่, และกลุ่มโหนดการนัดหมาย) จะได้ผลลัพธ์ failed พร้อมข้อความ "Unknown action type: …" แม้ตั้งค่าถูกต้องทุกอย่างและใช้งานได้จริงในโปรดักชัน — อ่านผล Test Run ของโหนดกลุ่มนี้ว่า "ยังทดสอบไม่ได้" ไม่ใช่ "ตั้งค่าผิด"
• Chat Sandbox อ่านจากกฎที่คอมไพล์แล้ว ไม่ได้อ่านจากกราฟบน canvas — sandbox ค้นตาราง trigger_rule ด้วยเงื่อนไข source_type = 'message_received' AND enabled = true AND deleted_date IS NULL ถ้าไม่พบจะตอบกลับเป็นข้อความว่า "No active message trigger rules found. Please activate the workflow first." — จึงทดสอบสิ่งที่แก้ไว้บน canvas แต่ยังไม่บันทึก/ยังไม่เปิดใช้งานไม่ได้
• ประวัติเวอร์ชันเดินหน้าอย่างเดียว ไม่ถอยกลับ และไม่มีการตัดทิ้ง — บันทึก snapshot ทุกครั้งที่บันทึกโดยส่งนิยามมา (เหตุการณ์ save) ทุกครั้งที่เปิดใช้งาน (activate) และทุกครั้งที่ย้อนกลับ (rollback) เลขเวอร์ชันเป็น max+1 เสมอ — การย้อนกลับไปเวอร์ชัน 3 จึงสร้างเวอร์ชันใหม่ (เช่นเวอร์ชัน 12) ที่มีนิยามเหมือนเวอร์ชัน 3 ไม่ได้ลบเวอร์ชัน 4-11 ทิ้ง และไม่มีกลไกลบเวอร์ชันเก่าอัตโนมัติเลย
• สถิติรายโหนดตั้งใจนับรวมกฎที่ถูก soft delete ไปแล้วด้วย — คำสั่งดึงกฎในฟังก์ชัน GetStats ไม่มีเงื่อนไข deleted_date IS NULL (มีคอมเมนต์ในซอร์สยืนยันว่าตั้งใจ) เพื่อให้ยอดทำงานสะสมของโหนดไม่ถูกรีเซ็ตทุกครั้งที่คอมไพล์ใหม่
• โควตาแพ็กเกจตรวจเฉพาะจังหวะที่ทำให้ workflow เป็น active — คือตอนสร้างพร้อมสถานะ active, ตอนแก้ไขเปลี่ยนสถานะเป็น active และตอนกดเปิดใช้งาน โดยนับ workflow WHERE status = 'active' แยกตาม LINE OA (ถ้าโควตาเป็น -1 หมายถึงไม่จำกัด) เมื่อเกินจะได้ 400 พร้อมข้อความ "Plan limit reached: you are using {x} of {y} workflows. Please upgrade your plan." — สร้างเป็นร่างไว้ได้ไม่จำกัด
• ฟีเจอร์ AI ทั้งหมดต้องมีการตั้งค่า AI ของ OA นั้นก่อน — ทั้งการให้ AI ร่าง flow, การให้ AI แกะโครงสร้าง JSON ที่ปลายทาง API ตอบกลับมา และตัวจำแนกความตั้งใจใน sandbox ต้องมีแถวในตาราง ai_config ที่ตรงทั้ง line_oa_id + organization_id + provider = 'gemini' + status = 'active' ไม่เช่นนั้นจะได้ 400 AI configuration not found for provider "gemini". Please configure an API key. — รองรับผู้ให้บริการเดียวคือ Gemini (โมเดลเริ่มต้น gemini-2.0-flash) การร่าง flow ใช้ temperature 0.7 กับเพดาน 8192 token ส่วนการแกะโครงสร้าง JSON ใช้ 0.3 กับ 4096 token
• การหน่วงเวลาต่ำกว่า 1 นาทีใน workflow ที่เปิดใช้งานอยู่ทำให้คอมไพล์ล้มด้วย 500 ไม่ใช่ 400 — ฟังก์ชัน convertToSeconds โยน error ธรรมดาเมื่อได้ค่าน้อยกว่า 60 วินาที และคอมไพล์เลอร์ห่อมันเป็น Internal Server Error — ตามปกติหน้าเว็บกันไว้ให้แล้วด้วยกฎ 1 นาที แต่ถ้าเจอ 500 ตอนกดบันทึก workflow ที่เปิดใช้งานอยู่ ให้ตรวจค่าหน่วงเวลาก่อนอย่างอื่น
• การสร้างเวกเตอร์ให้ intent แบบคีย์เวิร์ดเป็นแบบทำได้ก็ทำ (best-effort) และเป็นแบบทั้งหมดหรือไม่ได้เลย — ตอนคอมไพล์ trigger ชนิด message_received ระบบยิงข้อความรวมของแต่ละ intent ไปที่ API สร้าง embedding ภายนอก (ค่าเริ่มต้นชี้ไปที่โฮสต์ทดลอง EMBEDDING_API_URL) ถ้าตัวใดล้มเหลว ระบบเขียน log เตือนแล้วเลิกทั้งวง ไม่บันทึกเวกเตอร์ใดเลยแม้ตัวก่อน ๆ จะสำเร็จ — การจำแนกด้วยความหมายจะทำงานได้แม่นน้อยลงโดยที่การคอมไพล์ยังรายงานว่าสำเร็จ

เมนูที่เกี่ยวข้องกันในเส้นทางนี้

ทุกข้อด้านล่างยืนยันจากคำขอที่ workflow-form.container.tsx ยิงออกไปจริงเพื่อเติมตัวเลือกในแผงตั้งค่าโหนด:

• Rich message — เป็นตัวเลือกของโหนดส่งข้อความและส่งข้อความแบบขั้นสูง ดึงเฉพาะรายการ สถานะเปิดใช้งาน (status=active, รูปแบบ dropdown)
• Rich menu — เป็นตัวเลือกของโหนดสลับเมนู ดึงเฉพาะรายการ สถานะเปิดใช้งาน และติดธง isForAutomation=true เท่านั้น — Rich Menu ที่ไม่ได้ทำเครื่องหมายให้ใช้กับ automation จะไม่ปรากฏในตัวเลือก
• User Attribute Setup — เป็นแหล่งของ merge tag ทั้งชุด (ดึงแบบ รวมคุณสมบัติของระบบด้วย เพราะโหนดเรียก API ภายนอกต้องใช้) และเป็นเป้าหมายของโหนดอัปเดต attribute ตัวแผงตั้งค่ายังมีปุ่มสร้างคุณสมบัติใหม่ให้ในตัวโดยไม่ต้องออกจากหน้า
• Segment audience — ดึงมา สองชุดที่ต่างกัน: ชุดแรกคือกลุ่มเป้าหมายทั้งหมด ใช้กับ trigger เข้า/ออกกลุ่มและโหนดเงื่อนไขตรวจสมาชิก; ชุดที่สองกรองเฉพาะกลุ่มที่สร้างจากไฟล์ (dataSource: 'csv') ใช้กับโหนด เพิ่ม/ลบสมาชิกในกลุ่ม — กลุ่มแบบเงื่อนไขอัตโนมัติจึงไม่ปรากฏในสอง action นี้ เพราะแก้สมาชิกด้วยมือไม่ได้
• Friends Track — โหนด trigger เหตุการณ์ Friends Track ดึงรายการแคมเปญ สถานะเปิดใช้งาน เท่านั้นมาให้เลือก
• Campaign — โหนด trigger การคลิกแคมเปญดึงรายการผ่าน endpoint dropdown ตัวเดียวกับที่เมนู Segment audience ใช้ ซึ่งกรองเฉพาะแคมเปญที่ ส่งแล้วและส่งภายใน 3 เดือนล่าสุด (สูงสุด 100 รายการ)
• Knowledge base — เป็นตัวเลือกคลังความรู้ให้โหนดตัวจำแนกความตั้งใจ ใช้ตอบคำถามด้วยเนื้อหาในคลัง
• Trigger Rule — เป็นปลายทางของการคอมไพล์ workflow กฎที่มีคอลัมน์ workflow_id ระบุไว้คือกฎที่ระบบสร้างเอง ไม่ควรแก้ด้วยมือ

จุดที่ควรระวัง

• การกดปุ่มเปิดใช้งานจาก "หน้ารายการ" ข้าม validation 34 ข้อของหน้าเว็บทั้งหมด — ปุ่มสลับสถานะในตารางเรียก POST /workflows/:id/activate ตรง ๆ เหลือแค่การตรวจ 4 ข้อของเซิร์ฟเวอร์ และเมื่อล้มเหลว หน้ารายการยังแสดงเพียงหัวข้อ "ไม่สามารถเปิดใช้งานเวิร์กโฟลว์ได้" โดย ไม่แสดงข้อความอธิบายที่เซิร์ฟเวอร์ส่งกลับมาเลย (โค้ดส่ง desc: '' ไว้) — ถ้าเปิดใช้งานไม่ได้และอยากรู้สาเหตุ ให้เข้าไปกดเปิดใช้งานจากในหน้า canvas แทน เพราะหน้านั้นแสดงข้อความจากเซิร์ฟเวอร์จริง
• Test Run ที่ไม่ติ๊ก dry run ส่งข้อความถึงผู้ใช้จริงและยิง API ปลายทางจริง — ระบุ LINE user id ของลูกค้าจริงแล้วกดรัน หมายถึงลูกค้าคนนั้นได้รับข้อความจริง Rich Menu ของเขาเปลี่ยนจริง และ attribute ของเขาถูกเขียนจริง ให้ใช้บัญชีทดสอบของทีมเสมอ และเลือก dry run เมื่อต้องการดูแค่ว่าเส้นทางไหนเข้าเงื่อนไข
• การต่อโหนด action สองตัวติดกันทำให้ตัวแรกหายไปเงียบ ๆ — ยกเว้นกรณีที่ตัวแรกเป็นโหนดเรียก API ภายนอก ไม่มีการเตือนทั้งฝั่งหน้าเว็บและเซิร์ฟเวอร์ ให้ตรวจสอบผลด้วยการดูจำนวนกฎที่ถูกสร้างในเมนู Trigger Rule หลังเปิดใช้งาน
• เทมเพลตและ AI แทนที่ canvas ทั้งผืน — ไม่มี undo และไม่ได้บันทึกให้ด้วย ถ้าปิดหน้าไปโดยไม่กดบันทึก งานที่ AI ร่างมาจะหายทั้งหมด
• AI ร่างมาแล้วยังไม่ได้บันทึก — ต้องกดปุ่มบันทึกเองอีกครั้งเสมอ
• โควตาแพ็กเกจไม่มีการเตือนล่วงหน้า — สร้างและออกแบบไปได้เรื่อย ๆ แล้วมาถูกปฏิเสธที่ปุ่มเปิดใช้งานทีเดียว แม้ flow จะสมบูรณ์ทุกอย่าง
• การปิดใช้งานกับการลบทำต่างกันกับกฎที่คอมไพล์ไว้ — การปิดใช้งานตั้ง enabled = false ให้กฎทั้งหมดแต่ยังไม่ลบ (เปิดใช้งานอีกครั้งจะคอมไพล์ทับให้ใหม่) ส่วนการลบ workflow ตั้ง enabled = false แล้ว soft delete กฎทั้งชุดพร้อมกัน
• มีโหนดสองตัวที่สถานะไม่ตรงกันในซอร์สโค้ด — โหนด trigger_tracking_event มีอยู่ในชุดชนิดโหนดและถูกลงทะเบียนไว้บน canvas แต่ ไม่ปรากฏในแถบเลือกโหนดด้านซ้าย (จึงลากมาวางใหม่ไม่ได้ แต่ workflow เก่าที่มีโหนดนี้อยู่ยังทำงานได้) และในทางกลับกัน โหนด "ส่งต่อให้เจ้าหน้าที่" อยู่ในแถบเลือกโหนดและมีแผงตั้งค่าให้ครบ แต่ยังไม่ได้ลงทะเบียนในชุดโหนดที่ canvas รู้จัก
• โหนดหน่วงเวลาต่อกันสองตัวไม่รองรับ — เป็นข้อจำกัดจริง ไม่ใช่บั๊ก มีกฎกันไว้ตรง ๆ ในหน้าเว็บ
• เมนูที่คอมไพล์ไปใช้ต้องคงอยู่ — ถ้าลบ Rich Message หรือกลุ่มเป้าหมายที่โหนดใดอ้างถึงทิ้ง กฎที่คอมไพล์ไว้ยังเก็บ id เดิมอยู่ และจะล้มตอนทำงานจริง (เห็นได้ในหน้าประวัติการทำงานเป็นสถานะล้มเหลว)

สิทธิ์การเข้าถึง (ตรวจสอบจากซอร์สโค้ดจริง)

• ฝั่งหน้าเว็บ — PermissionGuard ของทั้งสามหน้าถูกคอมเมนต์ปิดไว้ ไฟล์ src/app/workflow/page.tsx, form/page.tsx และ logs/page.tsx ยัง import PermissionGuard ไว้แต่ export ตัวคอมโพเนนต์ออกไปเปล่า ๆ โดยมีคอมเมนต์กำกับตรง ๆ ว่า // Temporarily bypassing permission check for development — ผู้ใช้ที่ล็อกอินแล้วและพิมพ์ URL เข้ามาตรง ๆ จึงเปิดทั้งสามหน้าได้ แม้ไม่มีสิทธิ์ดูโมดูล Workflow สิ่งที่ยังทำงานอยู่คือการซ่อนรายการในเมนูซ้าย ซึ่งยังตรวจ ability.can(VIEW, workflow) ตามปกติ — เป็นการซ่อนไม่ให้เห็น ไม่ใช่การปิดกั้นไม่ให้เข้า
• ฝั่งเซิร์ฟเวอร์ — ทั้ง 18 เส้นทางของโมดูลนี้ถูกครอบด้วย ModuleGate("workflow") ที่บังคับใช้จริง (ผู้เรียกที่เป็น onemoby ข้ามได้) ในทางปฏิบัติ นี่คือด่านเดียวที่กันการเข้าถึง Workflow ได้จริง — ถ้าผู้ดูแลระดับแพลตฟอร์มปิดโมดูลนี้ให้องค์กรใด ผู้ใช้ในองค์กรนั้นจะเปิดหน้าได้แต่ทุกคำขอจะได้ 403 และหน้าจอว่างเปล่า
• policy annotation ระดับการกระทำมีประกาศไว้ครบทุกเส้นทางแต่วิ่งผ่าน middleware ที่เป็น no-op เหมือนโมดูลอื่นทั้งระบบ — การบังคับจริงจึงอยู่ที่ ModuleGate ระดับโมดูลเท่านั้น และมีจุดที่ประกาศไว้ต่างจากพวก: เส้นทาง POST /workflows/:id/test-chat ประกาศ policy เป็น read ของโมดูล lineOa ไม่ใช่ workflow (ไม่มีผลจริงเพราะ policy เป็น no-op แต่ควรรู้ไว้)
• การเข้าถึงข้อมูลถูกจำกัดขอบเขตด้วย line_oa_id ของ token ผู้เรียก — Chat Sandbox ตรวจซ้ำอีกชั้นและคืน 403 Access denied ตรง ๆ ถ้า workflow ที่ขอมาไม่ได้อยู่ทั้ง OA และองค์กรเดียวกันกับผู้เรียก
• DELETE /api/workflows/:id เป็น soft delete พร้อมปิดและ soft delete กฎที่คอมไพล์ไว้ทั้งชุด — ไม่มีเส้นทาง hard delete และไม่มีการตรวจสิทธิ์ Super Admin ในโมดูลนี้เลย

ไฟล์อ้างอิงจากซอร์สโค้ด

Frontend (cms-web-2026)

• src/app/workflow/page.tsx, form/page.tsx, logs/page.tsx — จุดเข้าทั้งสามหน้า และจุดที่ PermissionGuard ถูกคอมเมนต์ปิดไว้
• src/components/workflow/list/workflow-list.container.tsx — ตาราง ปุ่มสลับสถานะ (จุดที่ข้าม validation) การทำสำเนา และการลบ
• src/components/workflow/form/workflow-form.container.tsx — การบันทึก/เปิดใช้งาน/ปิดใช้งาน/ย้อนกลับ และคำขอทั้งหมดที่ดึงตัวเลือกจากเมนูอื่น
• src/components/workflow/form/workflow-form.tsx — แถบเครื่องมือ, จุดเรียก validation, การเลือกเทมเพลตและการให้ AI ร่าง (จุดที่แทนที่ canvas ทั้งผืน)
• src/components/workflow/form/utils/workflow-validation.ts — กฎ validation ทั้ง 34 ข้อและการตรวจเส้นทางที่ไม่ไปจบที่ action
• src/components/workflow/form/components/node-palette.tsx — 7 กลุ่มโหนดและรายการโหนดในแต่ละกลุ่ม
• src/components/workflow/form/components/node-config-drawer.tsx — แผงตั้งค่าโหนดทุกชนิด (เขียนกลับเข้ากราฟทันทีโดยไม่มีปุ่มบันทึกของตัวเอง)
• src/components/workflow/form/components/test-run-modal.tsx, chat-sandbox.tsx — เครื่องมือทดสอบทั้งสองตัว
• src/components/workflow/form/components/version-history-drawer.tsx, version-preview-modal.tsx — แผงประวัติเวอร์ชันและการดูตัวอย่าง
• src/components/workflow/form/data/workflow-templates.ts — เทมเพลตทั้ง 17 แบบ
• src/components/workflow/logs/workflow-logs.container.tsx — หน้าประวัติการทำงานและตัวกรอง
• src/services/types/workflow.type.ts — ชุดชนิดโหนดทั้ง 30 ชนิด

Backend (line-management-cms-api-go)

• internal/modules/workflow/controller.go — 18 เส้นทางและ ModuleGate("workflow")
• internal/modules/workflow/service.go — ตรรกะสร้าง/แก้ไข/ลบ/ทำสำเนา, การตรวจตอนเปิดใช้งาน, ฟังก์ชัน compile ที่แปลงกราฟเป็น Trigger Rule, การบันทึกเวอร์ชันและย้อนกลับ, สถิติและประวัติการทำงาน, การเรียก AI
• internal/modules/workflow/executor.go — ตัวรัน Test Run และ executeAction ที่รองรับ action 6 ชนิด
• internal/modules/workflow/sandbox.go — Chat Sandbox (จุดที่ยืนยันว่าอ่านจากกฎที่คอมไพล์แล้ว)
• internal/modules/workflow/ai.go, prompt.go — การเรียก Gemini ผ่านตาราง ai_config และ prompt ที่ใช้ร่าง flow
• internal/modules/workflow/paths.go, helpers.go — การไล่เส้นทางในกราฟและการตรวจการวนซ้ำ
• internal/modules/planlimits/service.go — การตรวจโควตา workflow ที่เปิดใช้งาน

ดูรายละเอียดเชิงเทคนิคเพิ่มเติม (เวอร์ชันก่อนหน้าของทีมเอกสาร) ที่ Workflow Automation