Sub-Workflow ใน n8n: แยก Workflow ให้จัดการง่าย

Workflow ที่ดีในช่วงแรกมักจะเริ่มเป็นระเบียบ มีโหนดไม่กี่ตัว เส้นทางชัดเจน แต่เมื่อเวลาผ่านไป requirement เพิ่มขึ้น โหนดก็เพิ่มตามจนกลายเป็น Workflow ที่มี 50 โหนด เส้นทางพันกันยุ่ง และทุกคนกลัวแตะเพราะไม่รู้ว่าจะพังอะไร

Sub-Workflow คือวิธีแก้ปัญหานี้โดยตรง

Sub-Workflow คืออะไร

Sub-Workflow คือ Workflow ปกติที่ถูกออกแบบให้ “ถูกเรียกใช้” จาก Workflow อื่นแทนที่จะทำงานอิสระ มันรับข้อมูลเข้า ประมวลผล และส่งผลลัพธ์กลับ เหมือนกับ function ในการเขียนโค้ด

ใน n8n ทำได้ด้วย Node สองตัว:

Execute Sub-Workflow (ใน Workflow หลัก) — เรียกใช้ Sub-Workflow พร้อมส่งข้อมูล
When Executed by Another Workflow (ใน Sub-Workflow) — รับข้อมูลที่ถูกส่งมา

เมื่อไหรควรใช้ Sub-Workflow

1. Logic ที่ซ้ำในหลาย Workflow ถ้า Workflow หลายตัวต้องทำสิ่งเดียวกัน เช่น แปลง Order Format หรือ Validate ข้อมูลลูกค้า ให้แยกออกมาเป็น Sub-Workflow แล้วทุก Workflow เรียกใช้ตัวเดียวกัน แก้ที่เดียวก็อัปเดตทุกที่

2. Workflow หลักซับซ้อนเกินไป ถ้า Workflow หลักเริ่มมีโหนดเกิน 20-30 ตัว และมี Logic ที่แยกเป็นหน่วยได้ชัดเจน ให้แยกออกเป็น Sub-Workflow ตาม responsibility

3. ต้องการ Test แยกส่วน Sub-Workflow สามารถ Test ได้อิสระโดยไม่ต้องรัน Workflow หลักทั้งหมด ทำให้ Debug และพัฒนาได้เร็วขึ้น

วิธีสร้าง Sub-Workflow

ขั้นตอนที่ 1: สร้าง Sub-Workflow

สร้าง Workflow ใหม่ เพิ่ม Node “When Executed by Another Workflow” เป็น Trigger แรก Node นี้จะรับข้อมูลที่ถูกส่งมาจาก Workflow หลัก

ตั้งชื่อ Workflow ให้ชัดเจน เช่น “SUB: Process Order” หรือ “SUB: Validate Customer” การใส่ prefix “SUB:” ช่วยให้หาเจอง่ายในรายการ Workflow

ขั้นตอนที่ 2: ออกแบบ Input/Output

Sub-Workflow ที่ดีควรมี Input และ Output ที่ชัดเจน ก่อนเริ่มเขียน ให้กำหนดก่อนว่า:

รับข้อมูลอะไรเข้ามา (fields ไหน)
ส่งผลลัพธ์อะไรกลับ (fields ไหน)

ตัวอย่าง Sub-Workflow “Process Order”:

Input: { orderId, customerId, items[], totalAmount }
Output: { success, processedOrder, error? }

ขั้นตอนที่ 3: เรียกใช้จาก Workflow หลัก

ใน Workflow หลัก เพิ่ม Node “Execute Sub-Workflow” ตั้งค่า:

Workflow — เลือก Sub-Workflow ที่สร้างไว้
Wait for Sub-Workflow — เปิดไว้ถ้าต้องการผลลัพธ์กลับมา (ปิดได้ถ้าแค่ trigger แล้วไม่ต้องรอ)

ส่งข้อมูลผ่าน Input Fields:

{
  "orderId": "{{ $json.id }}",
  "customerId": "{{ $json.customer.id }}",
  "items": "{{ $json.line_items }}",
  "totalAmount": "{{ $json.total }}"
}

ตัวอย่างจริง: ระบบประมวลผล Order

สมมติมี 3 แหล่งที่มาของ Order — เว็บไซต์, LINE OA และ Shopee แต่ละช่องทางมี Trigger ต่างกันและ Format ต่างกัน แต่กระบวนการหลังจากได้รับ Order เหมือนกัน

ก่อนใช้ Sub-Workflow:

Workflow เว็บไซต์: Webhook → แปลงข้อมูล → บันทึก DB → ส่งอีเมลยืนยัน → อัปเดต Inventory
Workflow LINE OA: LINE Trigger → แปลงข้อมูล → บันทึก DB → ส่งอีเมลยืนยัน → อัปเดต Inventory
Workflow Shopee: Shopee Trigger → แปลงข้อมูล → บันทึก DB → ส่งอีเมลยืนยัน → อัปเดต Inventory

โค้ดส่วน “บันทึก DB → ส่งอีเมลยืนยัน → อัปเดต Inventory” ซ้ำกัน 3 ครั้ง

หลังใช้ Sub-Workflow:

SUB: Process Order → บันทึก DB → ส่งอีเมลยืนยัน → อัปเดต Inventory
Workflow เว็บไซต์: Webhook → แปลงข้อมูล → Execute Sub-Workflow (Process Order)
Workflow LINE OA: LINE Trigger → แปลงข้อมูล → Execute Sub-Workflow (Process Order)
Workflow Shopee: Shopee Trigger → แปลงข้อมูล → Execute Sub-Workflow (Process Order)

ตอนนี้ถ้าต้องแก้ไข Logic การส่งอีเมลยืนยัน แก้ที่ Sub-Workflow ที่เดียวก็พอ

Nested Sub-Workflow

Sub-Workflow สามารถเรียก Sub-Workflow อีกตัวได้ (nested) แต่ควรระวังไม่ให้ลึกเกิน 3 ชั้น เพราะยิ่งลึกยิ่ง Debug ยาก

โครงสร้างที่แนะนำ:

Workflow หลัก
  → SUB: Process Order
      → SUB: Validate Customer (nested level 1)
      → SUB: Calculate Shipping (nested level 1)

ไม่ควรทำ:

Workflow หลัก
  → SUB: A
      → SUB: B
          → SUB: C
              → SUB: D  ← ลึกเกินไป

ส่งข้อมูลกลับจาก Sub-Workflow

เมื่อ Sub-Workflow ทำงานเสร็จ สามารถส่งข้อมูลกลับมาให้ Workflow หลักได้อัตโนมัติ — n8n จะส่ง output ของ Node สุดท้ายใน Sub-Workflow กลับมาเป็น result ของ Execute Sub-Workflow Node

ถ้าต้องการ output ที่ชัดเจน ให้ใส่ Set Node เป็น Node สุดท้ายใน Sub-Workflow เพื่อกำหนด output structure:

{
  "success": true,
  "orderId": "{{ $json.id }}",
  "message": "Order processed successfully"
}

Error Handling ใน Sub-Workflow

Sub-Workflow ควรมี Error Handling เป็นของตัวเอง ถ้า Error เกิดใน Sub-Workflow และไม่ได้จัดการ Error จะ bubble up ไปยัง Workflow หลัก ซึ่งบางครั้งอาจเป็นพฤติกรรมที่ต้องการ แต่บางครั้งไม่ใช่

แนะนำให้ Sub-Workflow ส่ง error กลับเป็น output แทนการ throw error:

// Success case
{ "success": true, "data": {...} }

// Error case
{ "success": false, "error": "Customer not found", "code": "CUSTOMER_404" }

แล้วให้ Workflow หลักตรวจสอบ success field ก่อนทำงานต่อ

จัดการ Version ของ Sub-Workflow

เมื่อต้องแก้ไข Sub-Workflow ที่ถูกใช้งานอยู่ในหลายที่ ให้ระวังเรื่อง breaking changes — การเปลี่ยน input/output structure จะทำให้ Workflow ที่เรียกใช้พังทันที

วิธีที่ดี: ทดสอบ Sub-Workflow ที่แก้แล้วกับ Workflow หลักทีละตัวก่อน Deploy จริง และถ้าเปลี่ยน interface มาก อาจสร้าง Sub-Workflow เวอร์ชั่นใหม่แยกต่างหากแล้วค่อยๆ ย้ายมาใช้

Sub-Workflow เป็นหนึ่งในเทคนิคที่ทำให้ n8n สามารถจัดการ Workflow ขนาดใหญ่ในระดับ Enterprise ได้ การลงทุนเวลาออกแบบโครงสร้าง Sub-Workflow ที่ดีตั้งแต่ต้นจะประหยัดเวลาในการ debug และบำรุงรักษาได้มากในภายหลัง

อยากเรียน n8n แบบเป็นระบบ ตั้งแต่เริ่มต้นจนสร้าง Workflow ใช้งานจริงได้ ลองดู คอร์สสอน n8n ที่ aiunlock.co