Workflow Automation

ภาพรวม

Workflow Automation คือเครื่องมือสร้าง flow อัตโนมัติแบบลากวาง (visual flow builder) ที่ให้แอดมิน OA ออกแบบเส้นทางการทำงานบน canvas แทนการตั้งกฎทีละข้อผ่านฟอร์ม หนึ่ง workflow คือกราฟที่ประกอบด้วย node และ เส้นเชื่อม (edge) โดยเริ่มจาก trigger node แล้วแตกกิ่งผ่าน condition / delay / split ไปจบที่ action node

เหมาะกับทีมที่ต้องการทำ automation หลายขั้นตอนต่อเนื่องกัน เช่น ต้อนรับสมาชิกใหม่ ส่งคอนเทนต์เป็นชุด (drip) ดึงลูกค้าที่เงียบไปกลับมา หรือยิงข้อความติดตามผลหลังคลิกแคมเปญ ซึ่งกฎแบบ Trigger Rule เดี่ยว ๆ ทำได้ยาก

หัวข้อ	รายละเอียด
หน้าหลัก	รายการ (/workflow), canvas (/workflow/form), ประวัติการทำงาน (/workflow/logs)
สถานะ workflow	draft (ร่าง) / active (ทำงานอยู่) / inactive (ปิดชั่วคราว)
ชนิด node	30 ชนิด แบ่ง 7 กลุ่ม: trigger, condition, action, flow control, AI, apps, utility
Template สำเร็จรูป	17 แบบ ใน 5 กลุ่ม (Onboarding, Segmentation & Engagement, Campaign Attribution, Scheduled & Nurture, Appointment)
ข้อจำกัดโครงสร้าง	กราฟต้องไม่มีวงจรย้อนกลับ (DAG), trigger ทุกตัวต้องมีเส้นออก, node ที่ไม่ใช่ trigger ต้องมีเส้นเข้า

จุดสำคัญที่ต้องทราบ

• workflow ที่ถูก activate จะถูกแปลง (compile) เป็น Trigger Rule ฝั่ง backend หน้ารายการ Trigger Rule จึงแสดงป้าย workflowId / workflowName กำกับว่ากฎนั้นถูกจัดการโดย workflow ตัวใด — ไม่ควรแก้กฎเหล่านั้นตรง ๆ
• ทุกครั้งที่บันทึกหรือ activate ระบบจะเก็บ version ไว้ ย้อนกลับ (rollback) ได้ภายหลัง
• ก่อน activate ระบบจะตรวจความสมบูรณ์ของ flow ทั้งชุด ถ้าไม่ผ่านจะระบุ node ที่มีปัญหาให้แก้ก่อน

Business Flow

1. จัดการรายการ workflow

1. เข้าหน้า /workflow ระบบโหลดรายการแบบแบ่งหน้า เรียงตามวันที่สร้างล่าสุด และคงข้อมูลหน้าเดิมไว้ระหว่างเปลี่ยนหน้าเพื่อไม่ให้ตารางกระพริบ
2. ตารางแสดงชื่อ workflow (คลิกเข้า canvas ได้) สถานะ จำนวน node ในกราฟ วันที่แก้ไขล่าสุด และปุ่มดำเนินการ
3. ปุ่มในแต่ละแถวมี 5 อย่าง ได้แก่ ดูประวัติการทำงาน แก้ไขบน canvas ทำสำเนา (clone) เปิด/ปิดการทำงาน และลบ
4. การลบต้องยืนยันผ่านกล่องข้อความก่อน ส่วนการทำสำเนาและการเปลี่ยนสถานะทำได้ทันที
5. ทุกคำสั่งจบด้วยการโหลดตารางใหม่พร้อมกล่องแจ้งผลสำเร็จหรือผิดพลาด
6. การเปิด/ปิดจากหน้ารายการจะไม่ตรวจความสมบูรณ์ของ flow ฝั่งหน้าจอ แต่ปล่อยให้ backend เป็นผู้ตัดสิน (ต่างจากปุ่ม activate บน canvas ที่ตรวจก่อนเสมอ)

2. ออกแบบ flow บน canvas

1. เมื่อเปิดหน้า canvas ระบบจะโหลดตัวเลือกสำหรับ node config ล่วงหน้าพร้อมกันหลายชุด ได้แก่ merge tag, รายการ audience, audience แบบ manual (CSV) สำหรับ action เพิ่ม/ลบสมาชิก, Rich Menu, Rich Message, แคมเปญ Friend Track, แคมเปญสำหรับ tracking spot และ Knowledge Base
2. โหมดแก้ไขจะโหลดตัวกราฟเดิมและสถิติการทำงานรายnode มาแสดงเป็น badge บน node ด้วย
3. ระหว่างโหลด ระบบจะเติมชื่อที่อ่านง่ายให้ค่าที่เก็บเป็น id (เช่น audience, Rich Message) เพื่อให้ node แสดงชื่อจริงได้โดยไม่ต้องเรียก API ซ้ำ
4. ผู้ใช้ลาก node จาก Node Palette ด้านซ้ายมาวางบน canvas ระบบจะสร้าง node ใหม่พร้อม id เฉพาะตัว และตั้งค่าเริ่มต้นให้บาง node
5. ลากเส้นเชื่อมระหว่าง node เพื่อกำหนดลำดับ ระบบตรวจความถูกต้องของเส้นตั้งแต่ยังไม่ปล่อยเมาส์
6. canvas รองรับ snap-to-grid, มินิแมป, การซูมเป็นเปอร์เซ็นต์ และสลับโหมดเมาส์ระหว่าง pan (ลากพื้นเพื่อเลื่อน) กับ select (ลากคลุมเลือกหลาย node)

3. กฎการเชื่อมเส้น

1. node ประเภท action โดยทั่วไปเป็นปลายทาง (terminal) ต่อออกไม่ได้ ยกเว้น 2 กรณี
   • action_web_request ต่อไปได้เฉพาะ node ที่เป็น action ด้วยกัน
   • action_advanced_send_message ที่เปิดการติดตามผล (tracking) ต่อไปยัง delay_wait ได้ 1 เส้น
2. node ประเภท exit เป็นปลายทางเสมอ
3. node ที่แตกกิ่งได้ (condition, delay, split test, multi-split, GenAI intent classifier) จะแนบข้อมูล branch ไปกับเส้น เพื่อให้รู้ว่าเส้นนั้นแทนผลลัพธ์ใด
4. เส้นแต่ละเส้นแสดง label ตามความหมายของ branch เช่น yes / no, completed / expired, กลุ่ม split A–D, ชื่อ branch ของ multi-split หรือชื่อ intent ของ GenAI classifier

4. ตั้งค่า node

1. คลิกที่ node เพื่อเปิดแผงตั้งค่า (Node Config Drawer) ด้านขวา คลิกพื้นที่ว่างบน canvas เพื่อปิด
2. แผงตั้งค่าใช้การ บันทึกอัตโนมัติ ไม่มีปุ่ม Save แยก ทุกครั้งที่แก้ไขค่าระบบจะเขียนกลับเข้ากราฟทันที
3. ฟิลด์ข้อความรองรับ merge tag ผ่านปุ่มแทรกแท็ก ซึ่งแบ่งกลุ่มเป็น user field / custom attribute / system attribute แล้วเติมแท็กรูปแบบปีกกาคู่ ({{tag}}) ต่อท้ายค่าปัจจุบัน
4. สร้าง attribute ใหม่ หรือ audience ใหม่ ได้จากในแผงตั้งค่าโดยไม่ต้องออกจากหน้า canvas
5. action_web_request มีตัวช่วยพิเศษ 2 อย่าง
   • Import จาก cURL — วางคำสั่ง cURL แล้วระบบแกะ method, URL, header, body และเดาชนิดเนื้อหา (JSON / form-urlencoded / raw) ให้อัตโนมัติ
   • Parse Response — วางตัวอย่าง JSON ที่ปลายทางตอบกลับ ระบบจะไล่หา path ของทุกฟิลด์ (เช่น $.data.name) ให้เลือกติ๊กเป็น mapping และ node action_update_attribute ที่ต่ออยู่ถัดไปจะถูกเติม mapping ให้อัตโนมัติ
6. action_advanced_send_message จะไล่ย้อน flow ขึ้นไปหาว่า trigger ต้นทางเป็น booking หรือไม่ ถ้าใช่จะเพิ่มชุด merge tag ของการจอง (booking.serviceName, booking.date, booking.status และอื่น ๆ) ให้เลือกใช้
7. โหมดตอบกลับของ action_advanced_send_message และ GenAI intent ใช้ตัวตั้งค่าร่วมกัน เลือกได้ 4 แบบ: ข้อความจาก AI, ตอบจาก Knowledge Base (ระบุ topK และสัดส่วนการค้นหาเชิงความหมายได้), Rich Message ที่มีอยู่ และ Flex Message ที่ออกแบบเอง โดยแนบ Quick Reply ได้ทุกแบบยกเว้น Rich Message
8. Flex Builder แปลง Flex JSON ของ LINE เป็นโครงต้นไม้ให้แก้ไขทีละองค์ประกอบ พร้อมพรีวิว และมีปุ่มให้ AI ช่วยสร้างโครงจากคำอธิบาย

5. ตั้งค่า node ที่ซับซ้อน

trigger_scheduled (ตั้งเวลา) — เลือกรูปแบบได้ 5 แบบ และเลือก timezone ได้ 9 ค่า (ค่าเริ่มต้นคือ Asia/Bangkok)

รูปแบบ	ค่าที่ต้องกรอก
interval	ทุก ๆ กี่หน่วย (1–1440) + หน่วยเป็นนาทีหรือชั่วโมง
daily	ชั่วโมง (0–23) + นาที (0–59)
weekly	วันในสัปดาห์ + ชั่วโมง + นาที
monthly	วันที่ในเดือน (1–31) + ชั่วโมง + นาที
custom	กำหนดเงื่อนไขเวลาเอง

multi_split (แตกหลายทาง) — สร้างได้ 2–6 branch ต่อ node แต่ละ branch ระบุ key, เงื่อนไข และค่าที่เทียบ พร้อมทางออกสำรอง else ที่เปิดไว้เป็นค่าเริ่มต้น เมื่อลบ branch ระบบจะจัดลำดับ branch ใหม่ทั้งชุดและลบเส้นที่ผูกกับ branch ที่หายไปให้อัตโนมัติ กรณีต้นทางเป็น trigger_campaign_click จะมีปุ่มสร้าง branch จาก tracking spot ของแคมเปญให้ในคลิกเดียว (สูงสุด 6 spot)

delay_wait (หน่วงเวลา) — กำหนดระยะเวลารอ (นาที / ชั่วโมง / วัน) และเวลาหมดอายุ พร้อมตัวเลือกประเมินเงื่อนไขซ้ำเมื่อครบเวลา หากต้นทางเป็น action_advanced_send_message ที่เปิด tracking จะเพิ่มโหมดรอผลการคลิกได้ 2 แบบ คือ รอคลิกลิงก์ใดก็ได้ หรือรอคลิก spot ที่ระบุ (ระบบดึงรายชื่อ spot จาก Flex Message ของ node ต้นทางมาเป็นตัวเลือกให้)

6. Template และการให้ AI สร้าง flow

1. ปุ่ม Template เปิดรายการ 17 แบบสำเร็จรูป เช่น Welcome New Member, VIP Upgrade, Audience Re-engagement, Drip Content, Birthday Greeting, Booking Confirmation
2. การเลือก template จะ แทนที่กราฟบน canvas ทั้งหมดทันที โดยไม่มีการถามยืนยัน จึงควรบันทึกงานเดิมก่อน
3. ปุ่ม AI ให้พิมพ์คำอธิบายสิ่งที่ต้องการ (ไม่เกิน 2,000 ตัวอักษร) แล้วระบบสร้างกราฟให้ พร้อมตั้งชื่อ workflow ให้ถ้ายังไม่ได้ตั้ง
4. ปุ่มกล้องส่งออกภาพ canvas เป็นไฟล์ PNG ตามชื่อ workflow

7. บันทึกและเปิดใช้งาน

1. บันทึก ต้องมีชื่อ workflow เป็นอย่างน้อย แต่ถ้า workflow นั้นทำงานอยู่แล้ว ระบบจะบังคับตรวจความสมบูรณ์ครบชุดด้วย (ปุ่มจะเปลี่ยนข้อความเป็นบันทึกและคอมไพล์ใหม่)
2. เปิดใช้งาน ต้องผ่านการตรวจทั้งหมด กฎหลักได้แก่
   • ต้องมี trigger อย่างน้อย 1 ตัว และ trigger ทุกตัวต้องมีเส้นออก
   • ทุก node ต้องตั้งค่าครบ (ยกเว้น node หมายเหตุและ node จบ flow)
   • condition node ต้องต่อทั้งทาง yes และ no
   • delay_wait ต้องมีปลายทางของ branch completed ระยะเวลารอต้องไม่น้อยกว่า 60 วินาที และห้ามต่อ delay ซ้อน delay
   • split_test ต้องมีอย่างน้อย 2 เส้นทาง และสัดส่วนรวมกันได้ 100 พอดี
   • multi_split ต้องมีอย่างน้อย 2 branch ที่ระบุ key และเงื่อนไขครบ พร้อมมีเส้นออก
   • action_web_request ต้องระบุ URL และ method ถ้ามี body ที่ไม่ได้ใช้ merge tag จะบังคับให้เป็น JSON ที่ถูกต้อง
   • genai_intent_classifier ต้องมี intent อย่างน้อย 1 รายการ ทุก intent ต้องมีชื่อและมีเส้นออก และ intent สำรองต้องอ้างถึง intent ที่มีอยู่จริง
   • trigger_message_received มีได้ตัวเดียวต่อ workflow และต้องต่อไปยัง genai_intent_classifier เท่านั้น
   • กราฟต้องไม่มีวงจรย้อนกลับ
   • นอกจากนี้ระบบจะเตือน (ไม่บล็อก) เมื่อพบเส้นทางที่จบลงโดยไม่มี action หรือ node จบ flow
3. เมื่อผ่านการตรวจ ระบบเปิดกล่องยืนยันตามคำสั่งที่เลือก แล้วแปลงกราฟเป็น payload ส่งบันทึก
4. การสร้างครั้งแรกที่สำเร็จจะพาไปหน้า canvas ของ workflow ที่เพิ่งสร้าง (ไม่เด้งกลับหน้ารายการ) ส่วนการแก้ไขจะโหลดข้อมูลใหม่และคงอยู่หน้าเดิม

8. ประวัติเวอร์ชันและการย้อนกลับ

1. ปุ่มประวัติจะแสดงเฉพาะ workflow ที่บันทึกแล้ว และโหลดรายการเวอร์ชันเมื่อเปิดแผงเท่านั้น
2. แต่ละเวอร์ชันแสดงเลขเวอร์ชัน ประเภทเหตุการณ์ (บันทึก / เปิดใช้งาน / ย้อนกลับ) เวลา และผู้ดำเนินการ
3. กด Preview เพื่อดูกราฟของเวอร์ชันนั้นแบบอ่านอย่างเดียว หรือกด Rollback (มีขั้นยืนยัน) เพื่อย้อนกลับไปใช้เวอร์ชันนั้น

9. การทดสอบและตรวจสอบการทำงาน

1. Test Run — ระบุ LINE user id แล้วสั่งรัน flow เลือกได้ว่าเป็นการทดลอง (dry run) หรือรันจริง กรณีรันจริงจะมีคำเตือนชัดเจนเพราะระบบจะส่งข้อความออกไปจริง ผลลัพธ์แสดงเป็นรายการต่อ node พร้อมสถานะสำเร็จ / ล้มเหลว / ข้าม และข้อความผิดพลาด
2. Chat Sandbox — แผงแชทข้าง canvas สำหรับคุยกับ flow เสมือนเป็นผู้ใช้จริง มีแผง debug แสดง intent ที่จับได้พร้อมค่าความมั่นใจ วิธีที่จับได้ (keyword / AI / fallback) โหมดการตอบ เวลาที่ใช้ประมวลผลแยกตามขั้นตอน และชิ้นข้อมูลจาก Knowledge Base ที่ถูกดึงมาใช้ พร้อมกด Quick Reply ที่บอทตอบกลับมาต่อได้ทันที
3. สถิติบน node — แสดงเป็น badge มุมขวาบนของแต่ละ node บอกจำนวนครั้งที่รันทั้งหมด ล้มเหลว และรออยู่
4. ตัวบอกสถานะ แสดงสถานะปัจจุบันพร้อมเวลาที่ทำงานล่าสุด

10. หน้าประวัติการทำงาน (logs)

1. เข้าถึงได้จากปุ่มดู logs ในหน้ารายการ ต้องระบุ workflow ที่ต้องการ มิฉะนั้นจะแสดงหน้าไม่พบข้อมูล
2. ด้านบนมีการ์ดสรุป 3 ใบ ได้แก่ จำนวนการทำงานทั้งหมดพร้อมยอดสำเร็จ/ล้มเหลว, อัตราความสำเร็จแบบมาตรวัด (เขียวเมื่อไม่ต่ำกว่า 90%, เหลืองเมื่อไม่ต่ำกว่า 70%, แดงเมื่อต่ำกว่านั้น) และสัดส่วน node ที่มีการทำงานจริงพร้อม node ที่ทำงานบ่อยที่สุด 3 อันดับ
3. กรองข้อมูลได้ด้วยคำค้น สถานะ ชนิด node และช่วงวันที่ พร้อมปุ่มล้างค่าที่จะแสดงเมื่อมีเงื่อนไขค้างอยู่
4. ตารางแสดง LINE user id (ย่อกลางและคัดลอกได้) node ที่ทำงาน สถานะ ที่มาของการรัน (ทดสอบเองหรืออัตโนมัติ) ข้อความผิดพลาด และเวลา

หน้าจอและองค์ประกอบหลัก

หน้ารายการ (/workflow)

• ตารางรายการ — ชื่อ สถานะ จำนวน node วันที่แก้ไข และปุ่มดู logs / แก้ไข / clone / เปิด-ปิด / ลบ
• กล่องยืนยันและกล่องแจ้งผล — ชุด modal มาตรฐานของ CMS

ไฟล์อ้างอิงหลัก: src/app/workflow/page.tsx, src/components/workflow/list/workflow-list.container.tsx

หน้า canvas (/workflow/form)

• Node Palette (ซ้าย) — คลังnode แบ่ง 7 กลุ่มแบบพับเก็บได้ ย่อเป็นแถบไอคอนแคบได้ การ์ดแต่ละใบลากลง canvas ได้โดยตรง
• Canvas (กลาง) — พื้นที่วาด flow พร้อมมินิแมป พื้นหลังแบบจุด ตัวควบคุมการซูม และปุ่มสลับโหมดเมาส์
• แถบเครื่องมือด้านบน — ชื่อ workflow, ตัวบอกสถานะ, ปุ่ม Template / AI generate / export PNG / Test Run / Chat Sandbox / ประวัติเวอร์ชัน และปุ่มบันทึก-เปิดใช้งาน
• Node Config Drawer (ขวา) — แผงตั้งค่าแบบบันทึกอัตโนมัติที่รวมฟอร์มของ node ทุกชนิดไว้ พร้อมตัวช่วย merge tag, สร้าง attribute/audience แบบ inline, import cURL และ parse response
• Chat Sandbox (ขวา) — แผงแชททดสอบพร้อมข้อมูล debug ใช้สลับกับ Node Config Drawer
• Version History Drawer — ไทม์ไลน์เวอร์ชันพร้อม preview และ rollback

ไฟล์อ้างอิงหลัก: src/app/workflow/form/page.tsx, src/components/workflow/form/workflow-form.container.tsx, src/components/workflow/form/workflow-form.tsx, src/components/workflow/form/components/node-config-drawer.tsx

หน้าประวัติการทำงาน (/workflow/logs)

• การ์ดสรุป 3 ใบ — จำนวนการทำงาน อัตราความสำเร็จ และความครอบคลุมของ node
• แถบกรอง — คำค้น สถานะ ชนิด node และช่วงวันที่
• ตาราง log — รายการการทำงานรายครั้งพร้อมข้อความผิดพลาดแบบ tooltip

ไฟล์อ้างอิงหลัก: src/app/workflow/logs/page.tsx

กลุ่ม node ที่รองรับ

กลุ่ม	ตัวอย่าง node	หมายเหตุ
Trigger	เปลี่ยนแปลง attribute, เข้า/ออก audience, ตั้งเวลา, Friend Track event, คลิกแคมเปญ, รับข้อความ, trigger รวม	trigger_advanced เลือกแหล่งที่มาได้ 6 แบบในตัวเดียว
Trigger (Apps)	สร้างการจอง, ยกเลิกการจอง, เปลี่ยนสถานะการจอง, แจ้งเตือนก่อนถึงนัด	ดึงข้อมูล journey / location / service จากโมดูล Appointment
Condition	เงื่อนไข attribute, เงื่อนไข audience, multi-split	2 แบบแรกมีทางออก yes และ no
Action	ส่งข้อความ, สลับ Rich Menu, เพิ่ม/ลบสมาชิก audience, อัปเดต attribute, เรียก API ภายนอก, ส่งข้อความขั้นสูง, ส่งต่อให้เจ้าหน้าที่	ส่วนใหญ่เป็นปลายทางของ flow
Action (Apps)	ส่งลิงก์จอง, อัปเดตสถานะการจอง
Flow control	หน่วงเวลา, split test	split test แบ่งได้สูงสุด 4 ทาง รวม 100%
AI	GenAI intent classifier	จำนวน intent ไม่จำกัด ระบุแบบ AI หรือ keyword ก็ได้
Utility	หมายเหตุบน canvas, node จบ flow	ข้ามการตรวจความสมบูรณ์

บริการฝั่ง API

รวมอยู่ที่ src/services/workflow.service.ts ภายใต้ path หลัก workflows

ความสามารถ	Endpoint
ดึงรายการ workflow	GET /workflows
ดึงข้อมูลรายตัว	GET /workflows/{id}
สร้าง / แก้ไข / ลบ	POST /workflows, PUT /workflows/{id}, DELETE /workflows/{id}
ทำสำเนา	POST /workflows/{id}/clone
เปิด / ปิดใช้งาน	POST /workflows/{id}/activate, POST /workflows/{id}/deactivate
ประวัติการทำงาน	GET /workflows/{id}/logs
สถิติรายnode	GET /workflows/{id}/stats
รายการเวอร์ชัน / รายละเอียด / ย้อนกลับ	GET /workflows/{id}/versions, GET /workflows/{id}/versions/{versionId}, POST /workflows/{id}/versions/{versionId}/rollback
ทดสอบรัน	POST /workflows/{id}/test-run
ทดสอบแชท	POST /workflows/{id}/test-chat
ให้ AI สร้าง flow	POST /workflows/generate

แผงตั้งค่า node ยังเรียกข้อมูลเพิ่มเติมตรงจาก API อื่นเมื่อจำเป็น ได้แก่ ทีมของ Mbox (GET /line-oa/{lineOaId}/mbox/teams) และข้อมูลของโมดูล Appointment (GET /apps/appointment/journeys, GET /apps/appointment/locations, GET /apps/appointment/locations/{id}/services)

จุดเชื่อมต่อกับฟีเจอร์อื่น

• Trigger Rule — เป็นปลายทางของการ compile workflow ที่ activate แล้ว กฎที่เกิดจาก workflow จะมีป้ายบอกที่มาในหน้ารายการ Trigger Rule และใช้ชุดเงื่อนไข/ความถี่เดียวกันกับที่ workflow ใช้ในแผงตั้งค่า node
• Audience Management — เป็นแหล่งข้อมูลของ trigger เข้า/ออก audience และเงื่อนไข audience ส่วน action เพิ่ม/ลบสมาชิกจำกัดให้เลือกได้เฉพาะ audience แบบ manual (CSV) เพื่อไม่ให้ไปแก้ audience ที่คำนวณจาก filter
• Rich Message / Rich Menu — เป็นตัวเลือกของ action ส่งข้อความและ action สลับเมนู โดยดึงเฉพาะรายการที่เปิดใช้งานอยู่
• Attribute Master และ System Attribute — เป็นแหล่งของ merge tag และเป้าหมายของ action อัปเดต attribute พร้อมสร้าง attribute ใหม่ได้จากในแผงตั้งค่า
• Friend Track และ Campaign — ให้ข้อมูลแคมเปญและ tracking spot สำหรับ trigger คลิกแคมเปญและการสร้าง branch อัตโนมัติ
• Knowledge Base — ใช้เป็นฐานความรู้ของโหมดตอบกลับแบบ RAG ใน GenAI intent และข้อความขั้นสูง
• Apps Appointment — ให้ข้อมูล journey, สาขา และบริการ สำหรับ node กลุ่มการจอง
• Mbox — เป็นปลายทางของ action ส่งต่อให้เจ้าหน้าที่ โดยเลือกทีมผู้รับได้
• Form Builder — เป็นหนึ่งในแหล่งที่มาของ trigger รวม (เมื่อมีการส่งฟอร์ม)
• โครงสร้างพื้นฐานร่วม — ใช้ระบบยืนยันตัวตนและ HTTP client กลางของ CMS (ออกจากระบบอัตโนมัติเมื่อ token หมดอายุ) ระบบ breadcrumb และเมนูด้านข้าง รวมถึงชุด modal มาตรฐาน โดยสถานะของ canvas ถูกเก็บแยกไว้ใน store เฉพาะของ workflow

รายละเอียดฝั่ง Backend (CMS API)

Workflow เป็นโมดูลที่ใหญ่ที่สุดของ cms-api โค้ดอยู่ที่ internal/modules/workflow/ และแยกความรับผิดชอบเป็นหลายไฟล์ตามหน้าที่

ส่วนของโค้ด	บทบาท
service	งาน CRUD, จัดการเวอร์ชัน, เปิด/ปิดใช้งาน, สรุปสถิติ
executor	ตัวเดินขั้นตอนของ flow ทีละ node
sandbox	เบื้องหลังของ Test Run และ Chat Sandbox รวมถึงการค้นความรู้แบบ RAG
ai / prompt	การให้ AI ร่าง flow จากคำอธิบาย

สิทธิ์ที่ต้องมี

• ทุก route ถูกครอบด้วย module gate ของโมดูล workflow หากองค์กรไม่ได้เปิดโมดูลนี้ จะถูกปฏิเสธก่อนถึง handler
• policy แยกตามการกระทำ: read สำหรับรายการ รายละเอียด สถิติ log และเวอร์ชัน, create สำหรับสร้าง ทำสำเนา และให้ AI ร่าง flow, update สำหรับแก้ไข เปิด/ปิด ย้อนเวอร์ชัน แปลง response และ Test Run, delete สำหรับลบ
• ข้อสังเกต — endpoint สำหรับ Chat Sandbox ใช้ policy ของโมดูล line-oa (สิทธิ์อ่าน) ไม่ใช่ของ workflow ตามที่สืบทอดมาจากระบบเดิม ดังนั้นผู้ที่มีสิทธิ์อ่าน LINE OA อาจทดลองคุยกับบอตได้แม้สิทธิ์ workflow จะจำกัดกว่า

Validation และ Business Rule ที่ backend ตรวจ

• จำนวน workflow ที่เปิดใช้งานพร้อมกันถูกจำกัดด้วยโควตาของแพ็กเกจ (ค่า maxActiveWorkflows) การกด activate จึงอาจถูกปฏิเสธเพราะเกินโควตา แม้ flow จะสมบูรณ์ทุกอย่างและผ่านการตรวจฝั่งหน้าจอแล้ว
• การตรวจโควตาเกิดขึ้นตอนบันทึกและตอนเปิดใช้งาน ไม่ใช่ตอนออกแบบ ดังนั้นสร้าง flow เป็นร่างไว้เยอะได้ ข้อจำกัดอยู่ที่จำนวนที่ "ทำงานอยู่จริง"
• POST /api/workflows/parse-response เป็น endpoint ฝั่ง backend ที่ช่วยแปลงและตรวจ response spec ของ node ที่เรียก API ภายนอก การ mapping ฟิลด์จากตัวอย่าง JSON จึงไม่ได้คิดที่หน้าจอฝ่ายเดียว
• POST /api/workflows/generate ส่งคำอธิบายภาษาคนไปให้ AI ร่างเป็นโครง flow กลับมา — เป็น endpoint ที่ใช้ policy create เพราะผลลัพธ์คือ flow ใหม่

สิ่งที่บันทึกและผลข้างเคียง (Side Effect)

• ข้อมูลกระจายอยู่หลายตาราง: workflow (ตัว flow), workflow_version (ประวัติเวอร์ชัน), trigger_rule (กฎที่ compile ออกมา) และกลุ่มตารางความรู้ knowledge_base / knowledge_document / knowledge_chunk สำหรับโหมดตอบจาก Knowledge Base
• การ activate เขียนข้อมูลข้ามโมดูล โดยสร้าง/ปรับกฎในตาราง trigger_rule ให้สอดคล้องกับ flow นี่คือเหตุผลที่ไม่ควรแก้กฎที่มีป้ายบอกว่ามาจาก workflow ตรง ๆ เพราะการบันทึก workflow ครั้งถัดไปจะเขียนทับ
• การเรียก API ภายนอกไม่ได้ยิงจาก cms-api โดยตรง แต่ส่งงานเข้าคิว web_request_execute ให้ line-management-worker-go เป็นผู้ยิงจริง คิว message_received_trigger เป็นทางที่ข้อความเข้ามาปลุก flow
• ตอน Chat Sandbox ทำงาน backend เรียกบริการภายนอกสองตัว คือ embedding API เพื่อแปลงข้อความเป็นเวกเตอร์ และ Meilisearch เพื่อค้นชิ้นความรู้ที่ใกล้เคียง ปลายทางทั้งสองตั้งค่าผ่านตัวแปรสภาพแวดล้อม (EMBEDDING_API_URL, MEILISEARCH_HOST, MEILISEARCH_API_KEY)
• การลบ workflow เป็น soft delete โดยประทับเวลาในคอลัมน์ deleted_date

การตั้งค่า AI ที่อยู่เบื้องหลัง

ปุ่มให้ AI ช่วยสร้าง flow และ Flex Builder พึ่งพาการตั้งค่า AI ที่เก็บแยกอยู่ในตาราง ai_config ต่อ LINE OA/องค์กร โดยเก็บ provider, ชื่อ model, API key และพารามิเตอร์การ generate

• GET /api/ai-config อ่านค่าที่ตั้งไว้ และ PUT /api/ai-config เป็นการบันทึกแบบ upsert (ไม่มีการแยกสร้างกับแก้)
• POST /api/ai-config/generate-flex รับคำอธิบายเป็นข้อความ (ฟิลด์ prompt) แล้วคืน Flex Message JSON กลับมาให้ตัวแก้ไข rich message นำไปวางต่อ
• provider ที่ implement จริงมีเพียง Gemini ตัวเดียว โค้ดเปิดช่องไว้สำหรับเพิ่ม provider อื่น แต่การเลือก provider อื่นจะยังไม่ทำงาน
• ค่าพารามิเตอร์ที่ไม่ส่งมาจะใช้ค่าเริ่มต้น โดย backend แยกกรณี "ไม่ส่งค่ามาเลย" ออกจาก "ส่งค่ามาเป็นศูนย์" อย่างชัดเจน การส่งค่า 0 มาจึงหมายถึงศูนย์จริง ไม่ใช่ให้ใช้ค่าเริ่มต้น
• ข้อสังเกตด้านความปลอดภัย — endpoint กลุ่ม ai-config ทั้งสามตัวอยู่บนกลุ่ม route แบบสาธารณะที่ต้องการเพียง token ระดับล็อกอิน (ไม่ต้องเลือก OA ก่อน) และ ไม่มี module gate ครอบ ส่วน policy ที่ประกาศไว้ก็ยังไม่บังคับใช้ เมื่อพิจารณาว่าตารางนี้เก็บ API key ของ provider ด้วย จุดนี้จึงเป็นสิ่งที่ควรทบทวนเมื่อจะรัดกุมสิทธิ์เพิ่ม

Edge Case และข้อสังเกตที่ควรรู้

• ตาราง workflow, workflow_version และ trigger_rule ไม่ได้ใช้กลไก soft delete อัตโนมัติของ ORM ทุก query ต้องเขียนเงื่อนไข "ยังไม่ถูกลบ" เอง หากลืมจะเห็นข้อมูลที่ลบไปแล้วปนกลับมา
• เพราะการเรียก API ภายนอกวิ่งผ่านคิว ผลลัพธ์จึงเป็นแบบไม่ทันที (asynchronous) การที่ Test Run รายงานว่า node ผ่านไม่ได้ยืนยันว่าปลายทางตอบกลับสำเร็จแล้ว
• Chat Sandbox พึ่งพาบริการภายนอก หากปลายทาง embedding หรือ Meilisearch ใช้งานไม่ได้ โหมดตอบจาก Knowledge Base จะทดสอบไม่ได้ ทั้งที่ตัว flow ถูกต้องทุกอย่าง
• ค่าเริ่มต้นของ MEILISEARCH_HOST ชี้ไปที่เครื่องเดียวกัน (localhost) ถ้าไม่ได้ตั้งค่าไว้ในสภาพแวดล้อมจริง การค้นความรู้จะล้มเหลวแบบเงียบ ๆ ให้ตรวจตัวแปรสภาพแวดล้อมก่อนสงสัยข้อมูลใน Knowledge Base
• การ activate ไม่ใช่แค่เปลี่ยนสถานะ แต่เป็นการ compile กราฟลงเป็นกฎ ดังนั้นการเปิดใช้งานที่สำเร็จจึงอาจใช้เวลานานกว่าการบันทึกร่างธรรมดา