Workflow n8n Jalan, tetapi Data Salah? Cara Memasang Validasi di Setiap Tahap

Kesalahan paling mahal dalam workflow n8n sering kali bukan workflow yang gagal. Justru yang lebih sulit ditemukan adalah workflow yang selesai dengan status sukses, tetapi membawa data yang keliru: alamat email kosong, harga terbaca sebagai teks, tanggal bergeser, atau nama field berubah dari customer_email menjadi email.

Masalah ini muncul karena banyak workflow hanya memeriksa apakah sebuah node berhasil dijalankan. Padahal, keberhasilan teknis dan kebenaran data adalah dua hal berbeda. API bisa mengembalikan respons HTTP 200, tetapi isi responsnya belum tentu sesuai dengan yang dibutuhkan langkah berikutnya.

Di sinilah validasi data berperan. Validasi adalah pemeriksaan untuk memastikan data memiliki bentuk, isi, dan nilai yang masuk akal sebelum diteruskan. Dalam n8n, data dari node sebelumnya dapat dirujuk melalui expressions dan pemetaan field di antarmuka workflow. ([docs.n8n.io](https://docs.n8n.io/data/data-mapping/data-mapping-ui/?utm_source=openai))

Anggap setiap tahap sebagai pintu pemeriksaan

Bayangkan workflow sebagai jalur sortir barang di gudang. Barang yang masuk perlu dicek labelnya, jumlahnya, dan kondisinya sebelum dikirim ke tujuan. Jika pemeriksaan hanya dilakukan di pintu terakhir, barang yang salah sudah telanjur melewati banyak proses.

Workflow n8n sebaiknya memiliki beberapa “pintu pemeriksaan”:

• Setelah data masuk: pastikan payload tidak kosong dan field utama tersedia.
• Setelah transformasi: cek apakah nama field, tipe data, dan formatnya sudah seragam.
• Sebelum mengirim ke sistem lain: pastikan data memenuhi syarat API tujuan.
• Setelah respons diterima: periksa apakah operasi benar-benar menghasilkan ID atau status yang diharapkan.

Pola ini tidak berarti setiap node harus dipenuhi puluhan kondisi. Fokusnya adalah menemukan titik yang paling berisiko menyebabkan kerusakan data atau tindakan yang sulit dibatalkan.

Mulai dengan kontrak data sederhana

Sebelum menambahkan node IF atau Code, tulis dulu bentuk data yang diharapkan. Tidak perlu langsung memakai sistem schema yang rumit. Sebuah daftar kecil sudah cukup:

{
  "order_id": "ORD-1001",
  "customer_email": "pelanggan@example.com",
  "total": 125000,
  "currency": "IDR",
  "status": "paid"
}

Kontrak data ini menjawab beberapa pertanyaan dasar: field apa yang wajib ada, tipe datanya apa, nilai apa yang diperbolehkan, dan kapan data dianggap tidak valid.

Contohnya, order_id tidak boleh kosong, total harus berupa angka positif, sedangkan status mungkin hanya boleh berisi paid, pending, atau cancelled. Aturan seperti ini membuat workflow lebih mudah dipahami ketika dirawat beberapa minggu atau bulan kemudian.

Normalisasi sebelum validasi

Data dari webhook, RSS, spreadsheet, atau API sering memakai format yang berbeda. Email bisa memiliki spasi di awal, nomor telepon bisa memakai tanda plus atau angka nol, dan nama field bisa berubah antar sumber.

Karena itu, normalisasi sebaiknya dilakukan sebelum validasi. Gunakan node seperti Edit Fields untuk menyamakan nama dan bentuk data. Misalnya, ubah beberapa variasi berikut menjadi satu format:

• email, email_address, dan customerEmail menjadi customer_email.
• Nilai harga berbentuk string seperti "125000" menjadi angka.
• Teks status seperti PAID dan Paid menjadi paid.

Perbedaan antara pemetaan dan transformasi penting dipahami. Dokumentasi n8n menjelaskan bahwa data mapping berarti mengambil data dari node sebelumnya, bukan mengubah isinya. Perubahan format perlu dilakukan secara sengaja melalui ekspresi atau node transformasi. ([docs.n8n.io](https://docs.n8n.io/data/data-mapping/data-mapping-ui/?utm_source=openai))

Gunakan jalur valid dan tidak valid

Setelah data dinormalisasi, buat jalur keputusan. Node IF cocok untuk pemeriksaan sederhana, misalnya apakah email ada atau apakah total lebih besar dari nol. Untuk beberapa pilihan status, node Switch atau rangkaian kondisi dapat membuat alurnya lebih jelas.

Contoh logikanya:

1. Periksa apakah order_id, customer_email, dan total tersedia.
2. Jika tidak, kirim data ke jalur karantina.
3. Jika ya, periksa apakah status termasuk daftar yang diperbolehkan.
4. Hanya data yang lolos semua pemeriksaan yang diteruskan ke CRM atau layanan pembayaran.

Jalur tidak valid tidak harus berakhir dengan error keras. Untuk data operasional, lebih berguna jika item tersebut disimpan ke tabel khusus, dikirim sebagai notifikasi internal, atau ditandai untuk diperiksa manual. Dengan begitu, satu data buruk tidak selalu menghentikan seluruh proses.

Bedakan data kosong, data salah, dan data tidak dikenal

Tiga kondisi ini sering dicampur, padahal penanganannya berbeda.

• Data kosong: field tidak ada atau nilainya kosong. Contoh: email pelanggan tidak dikirim.
• Data salah: field ada, tetapi formatnya tidak sesuai. Contoh: total berisi teks “seratus ribu”.
• Data tidak dikenal: formatnya benar, tetapi nilainya belum dipahami workflow. Contoh: status baru refunded muncul setelah sistem sumber menambahkan fitur.

Data kosong biasanya bisa ditolak atau diminta ulang. Data salah perlu diperbaiki atau dikarantina. Data tidak dikenal sebaiknya diperlakukan hati-hati, terutama jika workflow akan melakukan tindakan seperti mengirim pesan, membuat invoice, atau mengubah status pelanggan.

Jangan kehilangan jejak saat mengubah data

Transformasi yang terlalu agresif bisa membuat masalah baru. Misalnya, workflow mengganti seluruh isi item dengan hasil pemrosesan sehingga informasi sumber seperti URL, waktu masuk, atau ID eksekusi ikut hilang.

Simpan metadata penting bersama data yang sudah dinormalisasi:

• source untuk mengetahui asal data.
• received_at untuk mencatat waktu data diterima.
• validation_status untuk membedakan valid dan ditolak.
• validation_errors untuk menjelaskan alasan penolakan.

Ini juga membantu saat workflow memakai data dari beberapa cabang. n8n memiliki mekanisme item linking untuk menjaga hubungan antara item yang diproses dan sumbernya. Jika hubungan ini hilang pada node tertentu, expressions yang merujuk ke data sebelumnya dapat bermasalah. ([docs.n8n.io](https://docs.n8n.io/data/data-mapping/data-item-linking/item-linking-node-building/?utm_source=openai))

Uji dengan data buruk, bukan hanya data ideal

Workflow sering diuji menggunakan satu contoh yang rapi. Padahal, masalah biasanya muncul dari kasus pinggir: field hilang, array kosong, karakter khusus, respons API berubah, atau data berisi lebih banyak item daripada perkiraan.

Buat set pengujian kecil yang mencakup:

• Data lengkap dan valid.
• Field wajib yang hilang.
• Nilai kosong atau bernilai nol.
• Format tanggal yang berbeda.
• Status yang belum dikenal.
• Respons API tanpa properti yang biasanya tersedia.

Data yang dipasang untuk pengujian juga dapat membantu proses debugging. Dokumentasi n8n menyediakan pembahasan tentang pinning dan mocking data, sementara eksekusi sebelumnya dapat dimuat kembali untuk dianalisis atau dicoba ulang. ([docs.n8n.io](https://docs.n8n.io/workflows/sharing/?utm_source=openai))

Yang bisa dilakukan sekarang

1. Pilih satu workflow yang paling sering mengubah atau mengirim data.
2. Tulis tiga sampai lima field yang paling penting.
3. Tambahkan satu node normalisasi sebelum proses utama.
4. Buat pemeriksaan IF untuk field wajib dan nilai kritis.
5. Sediakan jalur karantina untuk data yang gagal.
6. Simpan alasan kegagalan, bukan hanya label “invalid”.
7. Uji workflow dengan minimal lima contoh data buruk.

Validasi bukan jaminan bahwa workflow tidak pernah salah. Namun, validasi membuat kesalahan lebih cepat terlihat, lebih mudah dilacak, dan lebih kecil kemungkinannya menyebar ke sistem lain. Otomatisasi yang baik bukan hanya mampu menjalankan pekerjaan tanpa klik manual, tetapi juga tahu kapan harus berhenti dan meminta pemeriksaan manusia.

Sumber & bacaan lebih lanjut

• Referencing data in the UI - n8n Docs
• Item linking for node creators - n8n Docs
• Sharing - n8n Docs
• All executions - n8n Docs

– Rio Yotto @rioyotto