Trigger Rule (กฎกระตุ้นการทำงาน)

ภาพรวม

Trigger Rule คือกฎอัตโนมัติแบบ "เมื่อเกิดเหตุการณ์ → ให้ทำสิ่งนี้" (When → Then) แบบ 1 ต่อ 1 ที่สร้างผ่านฟอร์มธรรมดา ไม่ใช่ผังลากวาง แอดมินกำหนดว่าเหตุการณ์ใดจะกระตุ้นกฎ กำหนดเงื่อนไขเพิ่มเติมได้ แล้วเลือกการกระทำหนึ่งอย่างที่จะเกิดขึ้น พร้อมสวิตช์เปิด/ปิดการทำงานของกฎ

เหมาะกับแอดมินที่ต้องการทำงานอัตโนมัติแบบตรงไปตรงมา เช่น เปลี่ยน Rich Menu ให้ลูกค้าเมื่อข้อมูลของเขาเปลี่ยน หรือส่ง Rich Message ทันทีเมื่อมีคนเข้าเป็นสมาชิกกลุ่มเป้าหมาย โดยไม่ต้องออกแบบ workflow ทั้งผัง

ข้อมูล 1 กฎประกอบด้วย

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

เหตุการณ์ต้นทางที่รองรับมี 4 แบบ

ชนิด	ใช้เมื่อ
การเปลี่ยนแปลงของ attribute	ค่าคุณลักษณะของผู้ใช้เปลี่ยนและเข้าเงื่อนไขที่กำหนด
การเข้า/ออกกลุ่มเป้าหมาย	ผู้ใช้ถูกเพิ่มเข้าหรือถูกนำออกจาก audience ที่ระบุ
การส่งฟอร์ม	มีผู้ส่งแบบฟอร์มที่สร้างจาก Form Builder
การคลิกในแคมเปญ	ผู้ใช้คลิกจุดที่กำหนดในแคมเปญ

ความต่างกับ Workflow Automation

ประเด็น	Trigger Rule	Workflow
วิธีสร้าง	ฟอร์มมาตรฐาน	ผังลากวางแบบ canvas
โครงสร้าง	1 เหตุการณ์ → 1 การกระทำ ไม่มีการแตกกิ่ง	กราฟหลาย node แตกกิ่งได้ (เงื่อนไข หน่วงเวลา แบ่งกลุ่ม AI)
เงื่อนไข	หลายเงื่อนไขต่อกันด้วย AND/OR ในระดับเดียว	node เงื่อนไขแยกกิ่ง ใช่/ไม่ใช่ รวมถึงการแบ่งกลุ่มและ split test
สถานะ	เปิด/ปิด	ฉบับร่าง / เปิดใช้งาน / ปิดใช้งาน
ประวัติเวอร์ชัน	ไม่มี	มีพร้อมย้อนเวอร์ชันได้
การทดสอบ	ไม่มี	ทดลองรันและ sandbox แชทได้

ความสัมพันธ์สำคัญคือ Workflow เป็นชั้นบนของ Trigger Rule เมื่อ workflow ถูกเปิดใช้งาน ระบบจะสร้างกฎที่ผูกกับ workflow นั้นขึ้นมาให้ กฎเหล่านี้จะแสดงป้ายกำกับในตาราง พร้อม tooltip บอกชื่อ workflow ที่ดูแลอยู่ และคลิกเพื่อกระโดดไปแก้ที่หน้า workflow ได้โดยตรง ซึ่งเป็นการสื่อว่าไม่ควรแก้กฎนั้นจากหน้านี้

ในทางกลับกัน ชุด enum ของเงื่อนไขและความถี่ทั้งหมดถูกนิยามไว้ที่ Trigger Rule แล้ว node ฝั่ง workflow นำไปใช้ต่อ ทำให้ Trigger Rule เป็นแหล่งความจริงเดียวของชุดเงื่อนไขในทั้งสองโมดูล

Business Flow

การจัดการรายการกฎ

1. เข้าหน้ารายการ ระบบตรวจสิทธิ์การเข้าถึง (สิทธิ์ VIEW ของโมดูล trigger-rule) ก่อนแสดงผล ทั้งสามหน้าของฟีเจอร์นี้ถูกควบคุมสิทธิ์เหมือนกัน
2. ตารางโหลดรายการเรียงตามวันที่สร้างล่าสุด แสดงลำดับ ชื่อกฎ ชนิดเหตุการณ์ สรุปเงื่อนไข ชนิดการกระทำ สวิตช์เปิด/ปิด วันที่สร้าง และปุ่มดำเนินการ (ดูประวัติ / แก้ไข / ลบ)
3. กฎที่ถูกสร้างจาก workflow จะมีป้ายกำกับต่อท้ายชื่อ พร้อมลิงก์ไปยัง workflow ต้นทาง
4. สลับเปิด/ปิดกฎได้จากสวิตช์ในตาราง ระบบบันทึกทันทีและรีเฟรชรายการ หากล้มเหลวจะแสดงกล่องแจ้งข้อผิดพลาด
5. การลบต้องยืนยันผ่านกล่องข้อความก่อน เมื่อสำเร็จระบบจะรีเฟรชตาราง
6. หมายเหตุ: หน้ารายการนี้ยังไม่มีส่วนค้นหาหรือกรองข้อมูล และคอลัมน์สรุปเงื่อนไขให้รายละเอียดครบเฉพาะกฎชนิด attribute change ส่วนชนิดอื่นจะแสดงสรุปแบบย่อ

การสร้างและแก้ไขกฎ

เตรียมข้อมูลตัวเลือก

1. เมื่อเปิดฟอร์ม ระบบโหลดตัวเลือกทั้งหมดพร้อมกัน ได้แก่ รายการ attribute (merge tag) รายการ audience รายการ Rich Menu ที่เปิดใช้งานและอนุญาตให้ใช้ในงานอัตโนมัติ รายการ Rich Message ที่เปิดใช้งาน รายการแบบฟอร์มที่เปิดใช้งาน และรายการแคมเปญ
2. โหมดแก้ไขจะโหลดข้อมูลกฎเดิมแล้วแปลงกลับเป็นค่าในฟอร์ม ระบบจะยังไม่แสดงฟอร์มจนกว่าจะเติมค่าครบ เพื่อไม่ให้เห็นฟอร์มเปล่าชั่วขณะ
3. โหมดสร้างใหม่ตั้งค่าเริ่มต้นให้เป็นเหตุการณ์แบบ attribute change การกระทำแบบเปลี่ยน Rich Menu สถานะเปิดใช้งาน ความถี่แบบครั้งเดียวต่อชั่วโมง และเงื่อนไขว่างหนึ่งแถวที่เชื่อมกันด้วย AND

ส่วน "When" — กำหนดเหตุการณ์

1. เลือกชนิดเหตุการณ์จากปุ่มตัวเลือก 4 แบบ ส่วนที่อยู่ด้านล่างจะเปลี่ยนตามชนิดที่เลือก
2. การเปลี่ยนแปลงของ attribute — เพิ่มเงื่อนไขได้หลายแถว แต่ละแถวประกอบด้วย attribute ที่ต้องการเฝ้าดู ตัวดำเนินการเปรียบเทียบ และค่าที่ใช้เทียบ
   • รายการตัวดำเนินการที่เลือกได้จะกรองตามชนิดข้อมูลของ attribute นั้น เช่น ข้อความ ตัวเลข วันที่ ค่าจริงเท็จ
   • ตัวดำเนินการบางตัวไม่ต้องกรอกค่า เช่น มีค่าอยู่ ไม่มีค่า มีการเปลี่ยนแปลง หรือเป็นวันนี้ ระบบจะซ่อนช่องค่าให้อัตโนมัติ
   • ตัวดำเนินการที่นับเป็นจำนวนวัน (ก่อนหน้า/หลังจาก) จะรับเฉพาะตัวเลข
   • การเปลี่ยน attribute ของแถวใดจะล้างตัวดำเนินการและค่าของแถวนั้น เพื่อไม่ให้เหลือค่าที่ไม่เข้ากับชนิดข้อมูลใหม่
   • เมื่อมีมากกว่า 1 แถว ระบบจะแสดงตัวเลือกให้กำหนดว่าเงื่อนไขทั้งหมดต้องเป็นจริงพร้อมกัน (AND) หรือเป็นจริงข้อใดข้อหนึ่งก็พอ (OR)
3. การเข้า/ออกกลุ่มเป้าหมาย — เลือก audience และระบุว่าจะกระตุ้นเมื่อถูกเพิ่มเข้าหรือถูกนำออก
4. การส่งฟอร์ม — เลือกแบบฟอร์มจากรายการที่เปิดใช้งานอยู่
5. การคลิกในแคมเปญ — เลือกแคมเปญและระบุจุดที่ต้องการติดตาม (พิมพ์เพิ่มเองได้) พร้อมเงื่อนไขเสริมชุดเดียวกับ attribute change ซึ่งเป็นทางเลือก ไม่บังคับกรอก
6. ความถี่ — แสดงกับทุกชนิดเหตุการณ์ เลือกได้ 4 แบบ คือ ทุกครั้ง ครั้งเดียวต่อชั่วโมง ครั้งเดียวตลอดไป และกำหนดช่วงเวลาพักเอง กรณีสุดท้ายจะให้ระบุจำนวนพร้อมหน่วยเวลา (วินาที/นาที/ชั่วโมง/วัน) ซึ่งระบบจะแปลงเป็นวินาทีก่อนบันทึก

ส่วน "Then" — กำหนดการกระทำ

1. เลือกชนิดการกระทำจากปุ่มตัวเลือก
2. เปลี่ยน Rich Menu — เลือก Rich Menu ปลายทางที่จะสลับให้ผู้ใช้
3. ส่งข้อความ — เลือก Rich Message ที่จะส่ง พร้อมสวิตช์เปิด/ปิดการติดตามการคลิกลิงก์ในข้อความนั้น
4. หมายเหตุ: ตัวเลือกการกระทำอีก 3 แบบ (เพิ่มเข้ากลุ่มเป้าหมาย นำออกจากกลุ่มเป้าหมาย และอัปเดต attribute) ยังไม่มีช่องตั้งค่ารองรับในหน้าจอ จึงยังใช้งานจริงไม่ได้ในเวอร์ชันปัจจุบัน

การบันทึก

1. กดบันทึกแล้วระบบจะเปิดกล่องยืนยันก่อนส่งข้อมูล
2. เมื่อยืนยัน ระบบประกอบข้อมูลตามชนิดที่เลือก โดยกรณี attribute change ที่มีเงื่อนไขเดียวจะบันทึกในรูปแบบเงื่อนไขเดี่ยวเพื่อความเข้ากันได้กับข้อมูลเดิม ส่วนหลายเงื่อนไขจะบันทึกพร้อมตัวเชื่อม AND/OR
3. บันทึกสำเร็จจะแสดงกล่องแจ้งผลที่ปุ่มปิดพากลับหน้ารายการ
4. หากเซิร์ฟเวอร์ตอบกลับเป็นข้อผิดพลาดรายฟิลด์ ระบบจะแสดงข้อความใต้ฟิลด์นั้นโดยตรง กรณีอื่นจะแสดงเป็นกล่องแจ้งข้อผิดพลาด
5. เมื่อเปิดกฎเดิมขึ้นมาแก้ไข ระบบรองรับข้อมูลทั้งรูปแบบเงื่อนไขเดี่ยวและหลายเงื่อนไข และแปลงค่าช่วงเวลาพักกลับเป็นหน่วยที่อ่านง่ายที่สุดโดยอัตโนมัติ

การดูประวัติการทำงาน

1. เข้าหน้าประวัติได้จากปุ่มในตารางรายการ หากเปิดหน้านี้โดยไม่มีรหัสกฎ ระบบจะแสดงหน้าไม่พบข้อมูล
2. ส่วนหัวแสดงชื่อกฎ สถานะปัจจุบัน ปุ่มย้อนกลับ และปุ่มรีเฟรชที่ดึงทั้งสถิติและรายการประวัติใหม่พร้อมกัน
3. การ์ดสถิติ 3 ใบ ได้แก่ จำนวนครั้งที่ทำงานทั้งหมดพร้อมยอดสำเร็จ/ล้มเหลว อัตราความสำเร็จในรูปมาตรวัดที่เปลี่ยนสีตามเกณฑ์ และตัวเลขการติดตามลิงก์ (จำนวนผู้เข้าถึง คลิกไม่ซ้ำ และคลิกทั้งหมด)
4. กรองประวัติได้ด้วยคำค้น สถานะสำเร็จ/ล้มเหลว ชนิดเหตุการณ์ และช่วงวันที่
5. ตารางประวัติแสดงรหัสผู้ใช้ (ย่อพร้อมปุ่มคัดลอก) เหตุการณ์ การกระทำ สถานะ ข้อความข้อผิดพลาด และเวลาที่ทำงาน
6. หมายเหตุ: ตัวกรองชนิดเหตุการณ์ยังครอบคลุมเฉพาะ attribute change และการเข้า/ออกกลุ่มเป้าหมาย และคอลัมน์การกระทำแสดงได้ 2 แบบคือเปลี่ยน Rich Menu กับส่งข้อความเท่านั้น

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

หน้ารายการ (/trigger-rule)

• ตารางกฎ — คอลัมน์ครบตั้งแต่ชื่อ เหตุการณ์ สรุปเงื่อนไข การกระทำ สถานะ และวันที่สร้าง พร้อมแถบเลื่อนแนวนอนสำหรับจอแคบ
• ป้ายกำกับกฎที่มาจาก workflow — คลิกเพื่อเปิดหน้าแก้ไข workflow ต้นทาง
• สวิตช์เปิด/ปิด และปุ่มลบ — บันทึกทันทีและมีกล่องยืนยันก่อนลบ

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

หน้าฟอร์ม (/trigger-rule/form)

• ส่วนหัวฟอร์ม — ชื่อกฎและสวิตช์เปิด/ปิดการทำงาน
• บล็อก When — ตัวเลือกชนิดเหตุการณ์ ส่วนเงื่อนไขแบบเพิ่มได้หลายแถว และตัวเลือกความถี่
• บล็อก Then — ตัวเลือกชนิดการกระทำและฟิลด์คอนฟิกของการกระทำนั้น
• ปุ่มท้ายฟอร์ม — ยกเลิกเพื่อกลับหน้ารายการ และบันทึกซึ่งจะเปิดกล่องยืนยันก่อนส่ง

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

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

• ส่วนหัว — ชื่อกฎ สถานะ ปุ่มย้อนกลับ และปุ่มรีเฟรช
• การ์ดสถิติ — ยอดการทำงาน อัตราความสำเร็จ และตัวเลขการติดตามลิงก์
• ส่วนกรองและตารางประวัติ — กรองตามคำค้น สถานะ เหตุการณ์ และช่วงวันที่

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

นิยามชุดตัวเลือกกลาง

src/components/trigger-rule/form/enums/trigger-rule.enum.ts เก็บชุดค่าทั้งหมดของฟีเจอร์ ได้แก่ ชนิดเหตุการณ์ 4 แบบ ชนิดการกระทำ 5 แบบ ตัวเลือกการเข้า/ออกกลุ่มเป้าหมาย ความถี่ 4 แบบ ตัวดำเนินการเปรียบเทียบ 20 ตัว และตารางจับคู่ว่าชนิดข้อมูลใดใช้ตัวดำเนินการใดได้บ้าง ไฟล์นี้ถูก workflow นำไปใช้ต่อด้วย

บริการฝั่ง API

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

ความสามารถ	Endpoint
ดึงรายการกฎ	GET /trigger-rules
ดึงข้อมูลกฎรายตัว	GET /trigger-rules/{id}
สร้างกฎใหม่	POST /trigger-rules
แก้ไขกฎ (รวมถึงการเปิด/ปิด)	PUT /trigger-rules/{id}
ลบกฎ	DELETE /trigger-rules/{id}
ดึงประวัติการทำงาน	GET /trigger-rules/{id}/logs
ดึงสถิติและข้อมูลติดตามลิงก์	GET /trigger-rules/{id}/stats
ดึงกฎที่ผูกกับ audience	GET /trigger-rules/by-audience/{audienceId}

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

• สิทธิ์การใช้งาน — ทั้งสามหน้าถูกควบคุมด้วยสิทธิ์ของโมดูล trigger-rule
• Workflow Automation — เป็นชั้นบนที่สร้างและดูแลกฎบางส่วนแทนผู้ใช้ กฎที่มาจาก workflow ควรแก้จากหน้า workflow เท่านั้น ขณะเดียวกัน workflow ก็ยืมชุดตัวดำเนินการและความถี่ไปจากฟีเจอร์นี้
• Audience — เป็นทั้งแหล่งเหตุการณ์แบบเข้า/ออกกลุ่มเป้าหมาย และเป็นผู้เรียกดูรายการกฎที่ผูกกับ audience จากหน้ารายละเอียด audience
• Form Builder — เป็นแหล่งของแบบฟอร์มสำหรับเหตุการณ์การส่งฟอร์ม
• Campaign และ Audience Filter — เป็นแหล่งของแคมเปญและจุดติดตามสำหรับเหตุการณ์การคลิกในแคมเปญ
• Rich Menu และ Rich Message — เป็นปลายทางของการกระทำ โดยดึงเฉพาะรายการที่เปิดใช้งานอยู่มาเป็นตัวเลือก
• Attribute / Merge Tag — เป็นแหล่งของ attribute และชนิดข้อมูลที่ใช้กำหนดว่าเงื่อนไขใดเลือกได้บ้าง โดยตัวเลือกในฟีเจอร์นี้จะไม่รวม attribute ระดับระบบ
• โครงสร้างพื้นฐานร่วม — ใช้ระบบยืนยันตัวตนและ HTTP client กลางของ CMS (ออกจากระบบอัตโนมัติเมื่อ token หมดอายุ) ระบบ breadcrumb และเมนูด้านข้าง รวมถึงชุด modal มาตรฐานและกลไกแสดงข้อผิดพลาดรายฟิลด์เช่นเดียวกับหน้าอื่นในระบบ

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

โค้ดฝั่ง backend อยู่ที่ internal/modules/triggerrule/ โมดูลนี้เป็น ฝั่งตั้งกฎและดูผล เท่านั้น การรันกฎจริงเกิดที่ line-management-worker-go ซึ่งเป็นคนละ service

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

• ทุก route ถูกครอบด้วย module gate ของโมดูล trigger-rule องค์กรที่ไม่ได้เปิดโมดูลนี้จะถูกปฏิเสธก่อนถึง handler
• policy แยกตามการกระทำ: read สำหรับรายการ ตัวเลือก dropdown รายละเอียด สถิติ log และการค้นกฎตาม audience, create / update / delete สำหรับสร้าง แก้ และลบ
• การเปิด/ปิดกฎใช้ endpoint แก้ไขปกติ จึงต้องมีสิทธิ์ update ไม่ใช่สิทธิ์แยกต่างหาก

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

• ตอนสร้างกฎ backend จะ ตรวจสอบว่าสิ่งที่กฎอ้างถึงมีอยู่จริง ทั้ง audience, แบบฟอร์ม และแคมเปญ ถ้าอ้างถึงสิ่งที่ถูกลบไปแล้วหรือไม่มีอยู่ จะตอบกลับเป็นข้อผิดพลาดพร้อมข้อมูลระบุว่าอ้างอะไรผิด ไม่ใช่บันทึกเงียบ ๆ แล้วไปพังตอนรัน
• การตรวจนี้ทำด้วยคำสั่งค้นข้อมูลตรง ๆ ที่เขียนเองในโมดูล ไม่ได้ผ่าน layer ของโมดูลต้นทาง
• ตัวเลือกชนิดเหตุการณ์ที่หน้าจอโหลดผ่าน GET /api/trigger-rules/dropdown ถูก cache ไว้ใน Redis (คีย์ TRIGGER_SOURCE_TYPES) ไม่ได้อ่านใหม่จากฐานข้อมูลทุกครั้ง
• GET /api/trigger-rules/by-audience/:audienceId เป็น endpoint เฉพาะทางที่ตอบว่ามีกฎใดผูกกับ audience นั้นอยู่บ้าง ใช้ตอนจะลบ audience เพื่อเตือนว่ามีกฎพึ่งพาอยู่

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

• กฎถูกบันทึกในตาราง trigger_rule ส่วนประวัติการทำงานรายครั้งอยู่ในตาราง trigger_log โดยอ้างอิงข้ามไปยังตาราง audience, form_builder, campaign และ workflow
• ตัวโมดูลนี้ไม่ได้ยิงงานเข้าคิวเอง เหตุการณ์ที่ปลุกกฎมาจากคิวข้อความของระบบที่ฟีเจอร์อื่นเป็นผู้ส่ง ได้แก่ การเข้า/ออก audience, การส่งฟอร์ม, การคลิกในแคมเปญ, การมีข้อความเข้ามา และเหตุการณ์เกี่ยวกับการจอง
• ตอนรันจริง worker อ่านกฎจาก Redis (คีย์ TRIGGER_RULES) ไม่ได้อ่านจากฐานข้อมูลทุกครั้ง และใช้กลไกล็อก (TRIGGER_LOCK) เพื่อกันไม่ให้กฎเดียวกันถูกรันซ้อนกันหลายรอบ เมื่อรันเสร็จจึงเขียนผลลงตาราง trigger_log
• การกระทำที่เป็นการเรียก API ภายนอกถูกส่งต่อผ่านคิว web_request_execute ให้ worker เป็นผู้ยิง

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

• ฝั่ง backend รองรับชนิดเหตุการณ์มากกว่าที่หน้าจอเปิดให้เลือก โดยเฉพาะเหตุการณ์ "มีข้อความเข้ามา" และเหตุการณ์กลุ่มการจอง ซึ่งถูกใช้งานผ่าน Workflow ที่ compile ลงมาเป็นกฎ มากกว่าจะสร้างตรงจากหน้า Trigger Rule
• คอลัมน์สถิติในหน้ารายการถูก คำนวณแยกต่อแถว ตอน query รายการ ดังนั้นเมื่อจำนวนกฎและจำนวน log สะสมมากขึ้น การโหลดหน้ารายการจะช้าลงตามไปด้วย
• เพราะ worker อ่านกฎจาก cache การแก้กฎอาจยังไม่มีผลทันที ในรอบการทำงานถัดไป ถ้าพบว่ากฎที่เพิ่งแก้ยังทำงานแบบเดิม ให้ตรวจ cache ก่อน
• กฎที่เกิดจาก Workflow อยู่ในตารางเดียวกันกับกฎที่สร้างเอง การแก้กฎเหล่านั้นจากหน้านี้จึงบันทึกได้จริง แต่จะถูกเขียนทับเมื่อ workflow ต้นทางถูกบันทึกหรือเปิดใช้งานครั้งถัดไป