Workflow n8n Makin Panjang? Pecah dengan Sub-wo…

Workflow n8n biasanya dimulai dari kebutuhan kecil: menerima data dari formulir, menyimpannya ke spreadsheet, lalu mengirim notifikasi. Masalah muncul ketika proses itu terus ditambahi fitur. Ada validasi, pemanggilan API, pencatatan log, pengiriman WhatsApp, percobaan ulang, dan pengecualian untuk kondisi tertentu. Dalam beberapa minggu, satu canvas bisa dipenuhi puluhan node yang saling silang.

Workflow seperti itu mungkin masih berjalan, tetapi belum tentu mudah dirawat. Ketika satu API berubah atau format data berganti, kita harus menelusuri seluruh alur untuk menemukan bagian yang terdampak. Di sinilah sub-workflow berguna: proses besar dipecah menjadi workflow kecil yang bisa dipanggil dari workflow lain.

n8n memang dirancang untuk menghubungkan aplikasi, memproses data, dan mengotomatisasi alur kerja dengan sedikit atau tanpa kode. Namun, fleksibilitas ini juga membuat kita mudah menaruh terlalu banyak tanggung jawab di satu workflow. Dokumentasi n8n menyediakan konsep flow logic dan sub-workflow untuk membantu menyusun proses yang lebih terstruktur.

Apa itu sub-workflow?

Sub-workflow adalah workflow yang diperlakukan seperti fungsi kecil dalam pemrograman. Workflow utama mengirim data ke sub-workflow, sub-workflow mengerjakan satu jenis tugas, lalu hasilnya dikembalikan ke workflow utama.

Contohnya, workflow utama menerima prospek baru dari landing page. Daripada menaruh semua logika di satu tempat, kita bisa membaginya seperti ini:

Workflow utama menerima webhook dan menentukan jenis permintaan.
Sub-workflow validasi memeriksa email, nomor telepon, dan field wajib.
Sub-workflow normalisasi merapikan format nama, nomor WhatsApp, dan tanggal.
Sub-workflow penyimpanan mengirim data ke CRM atau database.
Sub-workflow notifikasi mengirim pesan ke tim penjualan.

Secara konsep, workflow utama menjadi pengatur lalu lintas. Ia tidak perlu mengetahui seluruh detail cara validasi atau cara mengirim notifikasi. Ia cukup tahu data apa yang harus dikirim dan hasil seperti apa yang akan diterima.

Mengapa pemisahan ini penting?

1. Perubahan menjadi lebih terlokalisasi

Misalnya, penyedia CRM mengubah nama field dari phone menjadi phone_number. Jika semua proses berada dalam satu workflow, perubahan kecil ini bisa memengaruhi banyak cabang. Dengan sub-workflow penyimpanan, perubahan cukup dilakukan di satu tempat.

Ini bukan berarti masalah akan hilang secara otomatis. Kita tetap perlu menguji alur setelah perubahan. Namun, area yang harus diperiksa menjadi lebih jelas.

2. Workflow lebih mudah dibaca

Canvas yang rapi membantu kita memahami proses tanpa harus membuka setiap node. Nama sub-workflow bisa menjelaskan maksudnya, misalnya Normalize Lead Data, Save Order to Database, atau Send Internal Alert.

Penamaan yang baik lebih berguna daripada sekadar membuat garis workflow terlihat rapi. Orang lain yang mengambil alih proyek dapat memahami struktur sebelum membaca detail teknis.

3. Komponen bisa digunakan kembali

Jika ada tiga sumber prospek—website, iklan, dan WhatsApp—ketiganya mungkin perlu melalui proses normalisasi yang sama. Daripada menyalin node ke tiga workflow, kita dapat memanggil satu sub-workflow normalisasi dari ketiganya.

Penggunaan ulang juga mengurangi risiko logika yang berbeda-beda. Tanpa itu, format nomor telepon dari website bisa berbeda dengan format dari WhatsApp meskipun keduanya masuk ke CRM yang sama.

Cara membagi workflow tanpa membuatnya terlalu rumit

Kesalahan umum adalah memecah setiap dua atau tiga node menjadi sub-workflow. Hasilnya memang terlihat modular, tetapi alurnya justru sulit diikuti karena terlalu banyak perpindahan konteks.

Gunakan batas yang bermakna. Sebuah bagian layak dijadikan sub-workflow jika memenuhi setidaknya satu kondisi berikut:

Bagian tersebut punya tanggung jawab yang jelas dan berbeda dari proses utama.
Bagian tersebut akan dipakai oleh lebih dari satu workflow.
Bagian tersebut sering berubah karena bergantung pada API atau sistem eksternal.
Bagian tersebut perlu diuji atau dijalankan ulang secara terpisah.
Bagian tersebut memiliki detail teknis yang tidak perlu memenuhi canvas utama.

Sebaliknya, jangan memisahkan langkah yang selalu dipahami sebagai satu kesatuan sederhana. Contohnya, tiga node untuk mengubah nama field dan langsung meneruskan data mungkin belum perlu dibuat menjadi sub-workflow tersendiri.

Pola praktis: workflow utama sebagai orkestrator

Bayangkan otomasi pengajuan cuti karyawan. Workflow utama menerima pengajuan, lalu memanggil beberapa proses:

Validasi data karyawan dan tanggal cuti.
Memeriksa sisa jatah cuti.
Mengirim permintaan persetujuan kepada manajer.
Menyimpan hasil persetujuan.
Mengirim pemberitahuan kepada karyawan.

Workflow utama sebaiknya hanya memperlihatkan urutan bisnisnya. Detail seperti format tanggal API, query database, atau struktur payload email ditempatkan di sub-workflow yang sesuai.

Gunakan input dan output yang sederhana. Misalnya, sub-workflow validasi menerima objek dengan employee_id, start_date, dan end_date. Hasilnya mengembalikan status, pesan kesalahan, dan data yang sudah dinormalisasi. Hindari membuat sub-workflow bergantung pada terlalu banyak node tertentu dari workflow pemanggil.

Hal yang perlu diperhatikan

Jangan menyembunyikan kontrak data

Setiap sub-workflow sebaiknya memiliki aturan yang jelas: field apa yang wajib masuk, tipe datanya, dan hasil apa yang dikembalikan. Tanpa kontrak data, perubahan kecil di workflow utama dapat merusak sub-workflow secara diam-diam.

Dokumentasikan aturan ini di nama node, catatan workflow, atau dokumentasi proyek. Jika perlu, tambahkan node validasi di awal agar data yang salah berhenti lebih cepat.

Perhatikan kredensial dan akses

Sub-workflow yang mengakses CRM, database, atau layanan pesan tetap membawa risiko akses. Jangan menganggap pemisahan workflow otomatis membuat sistem lebih aman. Tinjau siapa yang dapat melihat, menjalankan, atau mengedit workflow dan kredensialnya.

Fitur berbagi workflow n8n memiliki konsekuensi penting: pengguna yang diberi akses dapat menjalankan workflow, sementara pengeditan node tertentu dapat dibatasi jika kredensialnya tidak dibagikan. Detail hak akses dapat berubah sesuai jenis instalasi dan paket yang digunakan, jadi periksa dokumentasi workflow sharing n8n sebelum menerapkannya di tim.

Jangan melupakan pengujian dan pemulihan

Karena satu workflow memanggil workflow lain, kegagalan bisa terjadi di batas antarworkflow. Uji kondisi seperti input kosong, API sedang lambat, respons tidak sesuai format, dan sub-workflow mengembalikan hasil gagal.

n8n menyediakan riwayat eksekusi dan opsi untuk mencoba ulang eksekusi yang gagal. Namun, coba ulang bukan pengganti desain yang aman. Jika sub-workflow mengirim email atau membuat data baru, pastikan pengulangan tidak menimbulkan efek ganda.

Dokumentasi eksekusi n8n menjelaskan bahwa eksekusi yang gagal dapat dicoba ulang dengan workflow asli atau versi workflow yang sudah diperbarui. Pilihan ini berguna saat memperbaiki alur, tetapi harus digunakan dengan pemahaman terhadap data yang sudah terlanjur diproses.

Yang bisa dilakukan sekarang

Pilih satu workflow yang paling sering disentuh atau paling sulit dijelaskan.
Tandai bagian yang memiliki tanggung jawab berbeda, seperti validasi, penyimpanan, dan notifikasi.
Pindahkan satu bagian yang paling mandiri menjadi sub-workflow.
Tentukan format input dan output sebelum menghubungkannya kembali.
Uji kondisi sukses, data tidak lengkap, dan kegagalan API.
Beri nama workflow berdasarkan tugasnya, bukan berdasarkan aplikasi yang dipakai.

Tujuan akhirnya bukan membuat sebanyak mungkin sub-workflow. Tujuannya adalah membuat perubahan lebih aman, pengujian lebih terarah, dan alur bisnis lebih mudah dipahami. Jika seseorang harus membuka seluruh node hanya untuk mengetahui apa yang dilakukan workflow, itu tanda bahwa pembagian tanggung jawab perlu ditinjau ulang.

Sumber & bacaan lebih lanjut

– Rio Yotto @rioyotto