Menangani kasus pengecualian dalam otomasi

Kasus pengecualian dalam otomasi adalah kejadian yang keluar dari jalur normal: data tidak cocok dengan aturan, layanan pihak ketiga gagal, atau keputusan butuh pertimbangan. Cara menanganinya: pisahkan error teknis dari kasus bisnis, ulangi yang sementara, beri aturan untuk yang berulang, dan serahkan sisanya ke manusia dengan konteks lengkap.

Tesis artikel ini: kualitas sebuah otomasi diukur dari cara ia menangani kasus yang meleset, dan jarang dari jalur normalnya. Jalur normal biasanya selesai dirancang dalam sehari. Kasus yang meleset baru ketahuan setelah workflow jalan berminggu-minggu, dan di situlah tim mulai kehilangan kepercayaan pada otomasinya.

Yang perlu diluruskan dulu

Banyak orang mengira otomasi yang baik adalah otomasi yang tidak pernah butuh campur tangan manusia. Pandangan ini membuat orang memaksa semua kasus masuk ke satu jalur. Hasilnya dua kemungkinan: workflow berhenti diam-diam, atau workflow terus jalan dengan data salah.

Saya lebih suka cara pandang yang lain. Otomasi yang sehat punya tiga jalur sejak awal: jalur normal, jalur pengecualian yang sudah dikenali, dan jalur ke manusia untuk kasus yang belum dikenali. Ketiga jalur itu dirancang dengan serius, dan jalur ketiga tidak diperlakukan sebagai tanda kegagalan.

Istilah yang akan sering muncul:

• Kasus pengecualian (exception): kejadian yang tidak sesuai asumsi jalur normal.
• Jalur normal (happy path): urutan langkah ketika semua data lengkap dan semua layanan merespons.
• Human-in-the-loop (HITL): desain yang mewajibkan persetujuan manusia sebelum langkah tertentu dijalankan.

Catatan jujur. Artikel ini ditulis 2 November 2026. Fitur n8n yang dibahas diambil dari dokumentasi resmi n8n per tanggal itu. Studi kasus Worldwide Express bersumber dari blog AWS yang ditulis tim AWS bersama seorang petinggi ShipStation Global, grup yang menaungi Worldwide Express. Semua angka hasil dari kasus itu adalah klaim vendor dan pelanggannya sendiri, dan tulisan itu tidak menyebut audit independen. Artikel ini juga tidak membahas cara konfigurasi langkah demi langkah.

Artikel ini untuk kamu yang sudah punya satu atau dua workflow berjalan, entah di n8n, Make, Zapier, atau alat lain, dan mulai kewalahan dengan kasus yang meleset. Kalau kamu baru belajar membuat workflow pertama, simpan dulu artikel ini. Fokuslah membuat jalur normalnya jalan, lalu kembali ke sini sebelum workflow dipakai untuk urusan uang atau pelanggan.

Dua jenis pengecualian: error teknis dan kasus bisnis

Langkah pertama yang paling sering terlewat adalah memisahkan dua jenis masalah yang kelihatannya sama. Keduanya membuat workflow tidak menghasilkan yang diharapkan. Cara menanganinya sangat berbeda.

Error teknis

Error teknis terjadi ketika sistem gagal menjalankan langkahnya. Contohnya API pihak ketiga merespons lambat, koneksi terputus, kuota permintaan habis, kredensial kedaluwarsa, atau memori server tidak cukup. Dokumentasi n8n tentang penanganan error menyebut penyebab umum kegagalan eksekusi adalah kesalahan pengaturan node dan workflow yang kehabisan memori.

Ciri error teknis: kalau kondisi luarnya pulih, langkah yang sama bisa berhasil tanpa diubah. Banyak di antaranya bersifat sementara. Sebagian lagi permanen sampai ada orang yang memperbaiki, seperti kredensial yang dicabut.

Kasus bisnis

Kasus bisnis terjadi ketika sistem jalan normal, tetapi datanya tidak masuk aturan. Pesanan dengan alamat yang tidak lengkap. Tagihan pemasok yang nominalnya berbeda dari kontrak. Pelanggan yang meminta refund di luar masa garansi. Semua API merespons dengan sukses, dan tidak ada pesan error merah di layar.

Ciri kasus bisnis: mengulang langkah yang sama berapa kali pun tidak mengubah hasilnya. Data yang salah tetap salah. Kasus seperti ini butuh keputusan, entah dari aturan tambahan atau dari manusia.

Kenapa pemisahan ini menentukan

Kesalahan yang paling mahal adalah memperlakukan kasus bisnis seperti error teknis. Misalnya, workflow diatur untuk mencoba ulang tiga kali ketika validasi data gagal. Yang terjadi hanya tiga kali kegagalan yang sama, lalu workflow berhenti. Sebaliknya, error teknis yang diperlakukan seperti kasus bisnis membuat orang di tim menerima tiket untuk masalah yang sebenarnya pulih sendiri lima menit kemudian.

Ada juga kelompok ketiga yang licin: kasus yang teknisnya sukses, datanya terlihat wajar, tetapi hasilnya salah. Contohnya model AI yang mengklasifikasikan email dengan yakin padahal keliru. Kasus ini tidak memicu error apa pun. Satu-satunya cara menangkapnya adalah pemeriksaan sampel oleh manusia atau aturan validasi pada keluarannya.

Pelajaran dari kasus Worldwide Express

Contoh nyata yang baru terbit adalah tulisan di blog AWS Machine Learning tertanggal 30 Oktober 2026. Isinya tentang Worldwide Express, perusahaan logistik yang kini bagian dari ShipStation Global, dan cara mereka mengotomasi pengecualian tagihan pengiriman. Saya ambil kasus ini karena masalahnya persis kasus bisnis, dan desainnya menunjukkan pemisahan jalur yang jelas.

Masalahnya

Menurut tulisan itu, sekitar 14 persen tagihan dalam angkutan LTL (less-than-truckload, pengiriman barang yang berbagi satu truk dengan muatan pelanggan lain) gagal dicocokkan tiga arah. Pencocokan tiga arah artinya membandingkan pesanan pembelian, bukti penerimaan barang, dan tagihan dari pengangkut. Kalau ketiganya tidak cocok, tagihan masuk antrean pengecualian.

Mereka membagi pengecualian ke tiga kategori:

• Ketidakcocokan baris tagihan. Jumlah atau kode layanan berbeda dengan catatan pengiriman.
• Selisih harga. Pengangkut menagih tarif yang berbeda dari harga kontrak.
• Biaya tambahan tak terduga. Misalnya biaya liftgate, biaya pengantaran ke rumah, atau penimbangan ulang yang tidak ada di penawaran awal.

Setiap pengecualian sebelumnya diproses manual dalam lima langkah: mengenali jenisnya, mencari akar masalah, mengirim email ke pengangkut, menunggu jawaban, lalu mengeksekusi penyelesaian di sistem manajemen transportasi mereka. Tiap pengangkut punya struktur tarif dan prosedur sengketa sendiri. Tulisan AWS menyebut otomasi berbasis aturan (RPA) cocok untuk alur yang terstruktur dan bisa ditebak. Penyelesaian pengecualian ini justru butuh penilaian sesuai konteks, misalnya menafsirkan kebijakan biaya tambahan tiap pengangkut.

Desainnya

Solusinya memakai tiga agen AI, masing-masing untuk satu kategori pengecualian. Agen adalah program berbasis model bahasa yang bisa membaca konteks, memanggil alat, dan memberi rekomendasi. Setiap agen mengambil aturan tagihan milik pengangkut yang bersangkutan dari basis pengetahuan sebelum memberi rekomendasi. Agen terhubung ke sistem lewat API yang sama dengan yang dipakai analis manusia.

Bagian yang paling relevan untuk kita adalah dua hal ini. Pertama, ada langkah persetujuan manusia. Pada awal peluncuran, peninjau manusia menyetujui rekomendasi agen lewat antarmuka sistem yang biasa mereka pakai sebelum rekomendasi itu difinalkan. Menurut tulisan itu, persetujuan massal baru menjadi default setelah akurasi melewati 99 persen. Kedua, setiap penolakan dari peninjau dicatat, dan tim memperbaiki instruksi agen serta basis pengetahuannya berdasarkan riwayat penolakan itu.

Hasil yang mereka klaim

Semua angka berikut adalah klaim yang dilaporkan di blog AWS:

Ada satu ketidakkonsistenan yang perlu kamu tahu. Di bagian hasil, tulisan itu menyebut 10.000 pengecualian sebagai "sekitar 50 persen". Di kutipan wakil presiden FinOps mereka, angkanya "lebih dari 40 persen" pengecualian mingguan. Bisa jadi keduanya diukur pada waktu atau dasar yang berbeda, tetapi tulisan itu tidak menjelaskannya. Saya tidak bisa mengonfirmasi angka mana yang tepat.

Yang bisa ditiru tanpa anggaran besar

Kamu tidak butuh tiga agen AI untuk mengambil pelajarannya. Ada empat hal yang bisa diterapkan bahkan di workflow kecil:

1. Pengecualian dipecah per kategori, dan setiap kategori punya penanganan sendiri. Satu jalur "lain-lain" untuk semua kasus adalah resep kekacauan.
2. Aturan disimpan terpisah dari logika workflow. Di kasus itu, aturan tiap pengangkut ada di basis pengetahuan. Di skala kecil, ini bisa berupa satu Google Sheet berisi ambang selisih yang boleh diterima.
3. Manusia menyetujui di awal, lalu perlahan dilepas. Kepercayaan dibangun dengan data akurasi, bukan dengan keyakinan.
4. Setiap penolakan manusia adalah data. Catat alasannya, karena dari situlah aturan berikutnya lahir.

Bagian akhir tulisan AWS juga menyarankan memulai dari jenis pengecualian yang paling berulang, membuktikan akurasinya, lalu memperluas. Saran itu masuk akal untuk skala berapa pun.

Alat di n8n: dari retry sampai error workflow

Sekarang ke alat yang lebih membumi. Saya pakai n8n sebagai contoh karena dokumentasinya terbuka untuk umum. Prinsipnya bisa dibawa ke Make atau Zapier, tetapi nama dan perilaku fiturnya perlu kamu cek di dokumentasi alat itu sendiri.

Pengaturan di tiap node

Halaman Work with nodes di dokumentasi n8n mencantumkan beberapa pengaturan node yang berhubungan langsung dengan pengecualian:

• Retry On Fail. Ketika node gagal, n8n menjalankannya ulang. Ini cocok untuk error teknis sementara seperti koneksi putus atau server tujuan sedang sibuk.
• On Error > Stop Workflow. Workflow berhenti total saat terjadi error. Ini perilaku paling aman untuk langkah yang tidak boleh dilewati.
• On Error > Continue. Workflow tetap lanjut ke node berikutnya dengan data valid terakhir. Pilihan ini paling berbahaya, karena error bisa lewat tanpa ada yang tahu.
• On Error > Continue (using error output). Workflow lanjut, tetapi informasi error dikirim lewat cabang terpisah. Di cabang itu kamu bisa mencatat kasus, mengirim notifikasi, atau mengalihkan ke antrean manual.

Pendapat saya: untuk node yang memanggil layanan luar, gabungkan Retry On Fail dengan Continue (using error output). Retry menyerap gangguan sesaat. Kalau tetap gagal, error output memastikan item yang gagal tidak hilang. Saya tidak menyarankan Continue biasa untuk workflow yang menyentuh uang, stok, atau data pelanggan.

Satu catatan lagi. Pengaturan Always Output Data membuat node tetap mengeluarkan item kosong walau tidak ada hasil. Dokumentasi n8n sendiri memperingatkan bahwa pengaturan ini bisa memicu perulangan tanpa akhir bila dipasang di node IF.

Error workflow sebagai jaring pengaman

Pengaturan per node menangani kasus yang sudah kamu duga. Untuk kasus yang tidak terduga, n8n menyediakan error workflow. Ini workflow terpisah yang diawali node Error Trigger dan dipilih di pengaturan workflow utama. Ketika eksekusi workflow utama gagal, error workflow berjalan.

Beberapa fakta dari dokumentasi resminya yang sering membuat orang bingung:

• Satu error workflow bisa dipakai bersama oleh banyak workflow. Jadi cukup buat satu "pusat pemberitahuan" untuk seluruh instance.
• Error Trigger tidak berjalan saat workflow dijalankan manual dari editor. Ia hanya aktif ketika workflow otomatis gagal.
• Workflow yang berisi Error Trigger secara default menjadikan dirinya sendiri sebagai error workflow.
• Data yang diterima berisi nama workflow, pesan error, node terakhir yang dijalankan, dan tautan ke eksekusi yang gagal. Tautan eksekusi hanya ada bila eksekusinya tersimpan di database.
• Kalau kegagalan terjadi di node trigger workflow utama, isi datanya berbeda. Informasi eksekusinya lebih sedikit, dan detail lebih banyak ada di bagian trigger.

Poin terakhir berkaitan dengan pengaturan workflow lain. Halaman Configure workflow settings punya opsi untuk menyimpan atau tidak menyimpan eksekusi produksi yang gagal. Kalau opsi itu dimatikan demi menghemat penyimpanan, notifikasi error kamu kehilangan tautan untuk menelusuri masalahnya. Saya sarankan eksekusi gagal selalu disimpan.

Stop And Error untuk kasus bisnis

Di sinilah dua jenis pengecualian tadi bertemu. Kasus bisnis tidak memicu error, jadi error workflow tidak akan pernah tahu. Node Stop And Error mengisi celah itu. Node ini sengaja menggagalkan eksekusi pada kondisi yang kamu tentukan dan mengirim pesan error buatanmu ke error workflow.

Contoh pemakaiannya: tagihan dengan selisih di atas ambang yang kamu tetapkan dialihkan ke Stop And Error dengan pesan yang jelas, misalnya nomor tagihan dan besar selisihnya. Error workflow lalu mengirim pesan itu ke kanal tim keuangan. Dengan begitu kasus bisnis yang diam berubah menjadi sinyal yang terlihat.

Diagram di atas adalah cara memetakan workflow yang saya sarankan. Setiap item yang masuk diperiksa aturan. Yang lolos masuk jalur normal. Yang tidak lolos tetapi jenisnya dikenali masuk jalur aturan otomatis. Sisanya dikirim ke manusia. Error teknis di langkah mana pun dicoba ulang dulu, lalu diteruskan ke error workflow bila tetap gagal.

Kapan manusia harus masuk

Jalur ke manusia sering dirancang paling akhir, padahal ia yang menentukan apakah tim mau memakai otomasinya. Kalau kasus yang diteruskan ke manusia datang tanpa konteks, petugas harus membuka tiga aplikasi untuk memahami satu masalah. Setelah beberapa minggu, mereka mulai mengabaikan notifikasi.

Kriteria dari dokumentasi n8n

Dokumentasi n8n tentang human-in-the-loop untuk tool AI menyebut empat kondisi yang cocok untuk persetujuan manusia. Saya sarankan memakai daftar ini apa adanya sebagai titik awal:

• Tindakan yang tidak bisa dibatalkan. Menghapus data, mengirim komunikasi ke pihak luar, atau melakukan pembelian.
• Ada kewajiban kepatuhan. Industri yang diatur regulasi kadang mewajibkan persetujuan manusia.
• Nilai keputusannya besar. Dampak bisnisnya cukup tinggi sehingga satu kesalahan terasa mahal.
• Kepercayaan sedang dibangun. Mulai dengan peninjauan manusia, lalu kurangi seiring bukti akurasi bertambah.

Butir terakhir sama persis dengan pola Worldwide Express tadi. Bedanya, di sana keputusan melepas peninjauan didasarkan pada angka akurasi yang dipantau, bukan perasaan.

Bentuk persetujuan di n8n

Ada beberapa cara menghentikan workflow sampai manusia memutuskan. Node Wait bisa melanjutkan eksekusi setelah selang waktu tertentu, pada tanggal dan jam tertentu, setelah menerima panggilan webhook, atau setelah formulir dikirim. Saat menunggu, data eksekusi dipindahkan ke database dan dimuat lagi ketika syaratnya terpenuhi. Ada juga opsi batas waktu tunggu, supaya kasus tidak menggantung selamanya.

Untuk AI Agent, n8n menyediakan langkah Human review pada tool. Workflow berhenti sebelum tool tertentu dijalankan, lalu permintaan persetujuan dikirim lewat kanal pilihan. Dokumentasinya mencantumkan sembilan kanal: Chat bawaan n8n, Slack, Discord, Telegram, Microsoft Teams, Gmail, WhatsApp Business Cloud, Google Chat, dan Microsoft Outlook. Peninjau memilih setuju atau tolak. Kalau ditolak, tindakan dibatalkan dan agen diberi tahu.

Khusus Slack, halaman Approvals menjelaskan operasi Send and Wait for Response dengan tipe respons Approval. Ada opsi untuk membatasi siapa yang boleh menyetujui dan mencatat siapa yang menekan tombol. Satu peringatan penting dari dokumentasinya: kalau daftar penyetuju dikosongkan, siapa pun yang melihat pesan bisa menyetujui. Fitur ini juga butuh instance n8n yang bisa diakses Slack lewat HTTPS publik, jadi instance di localhost tidak akan bisa menerima balasan.

Isi pesan yang layak dikirim ke manusia

Persetujuan yang baik bisa diputuskan dalam satu kali baca. Menurut saya isinya minimal:

• Apa kasusnya dan kategori pengecualiannya.
• Data pembanding, misalnya nilai di tagihan dan nilai di kontrak.
• Rekomendasi sistem beserta alasannya, bila ada.
• Tautan ke catatan aslinya.
• Batas waktu, dan apa yang terjadi kalau tidak ada yang menjawab.

Butir terakhir sering terlupa. Kalau tidak ada yang merespons dalam dua hari, apakah kasusnya otomatis ditolak, diteruskan ke atasan, atau dibiarkan? Keputusan itu harus ditulis saat merancang, bukan saat masalahnya muncul.

Cara memilih strategi untuk tiap jenis kasus

Setelah semua alat di atas, pertanyaannya tinggal satu: untuk satu jenis kasus tertentu, pilih yang mana? Saya memakai urutan pertanyaan sederhana.

1. Apakah ini error teknis yang bisa pulih sendiri? Kalau ya, pakai retry. Kalau tetap gagal setelah retry, teruskan ke error workflow.
2. Apakah ini kasus bisnis yang polanya jelas dan berulang? Kalau ya, tulis aturannya dan tangani otomatis. Contoh: selisih harga di bawah ambang tertentu langsung diterima.
3. Apakah dampaknya kecil dan bisa dibatalkan? Kalau ya, biarkan otomatis, tetapi catat setiap kejadian untuk ditinjau berkala.
4. Selain itu, kirim ke manusia dengan konteks lengkap.

Kesalahan yang paling sering

Beberapa pola yang menurut saya perlu dihindari:

• Satu notifikasi untuk semua jenis error. Kalau semua pesan berbunyi sama, tim cepat lelah dan mulai mengabaikan. Bedakan minimal antara "perlu tindakan sekarang" dan "cukup dicatat".
• Retry tanpa batas untuk masalah data. Mengulang validasi yang gagal hanya membuang waktu eksekusi dan kuota API.
• Jalur manusia tanpa pemilik. Antrean pengecualian yang tidak punya penanggung jawab bernama hanya memindahkan masalah ke tempat yang tidak dilihat orang.
• Tidak mengukur. Tanpa angka berapa kasus yang masuk tiap jalur, kamu tidak tahu kapan sebuah aturan layak ditambah atau peninjauan manusia layak dikurangi.
• Menganggap AI menyelesaikan semua pengecualian. Agen AI menambah satu sumber pengecualian baru: jawaban yang terdengar yakin tetapi salah. Ia tetap butuh jalur tinjau.

Mengukur dengan sederhana

Kamu tidak butuh dasbor mahal. Cukup satu tabel log dengan kolom tanggal, jenis kasus, jalur yang diambil, dan hasil akhirnya. Dari tabel itu ada tiga angka yang paling berguna: proporsi kasus per jalur, waktu penyelesaian kasus di jalur manusia, dan seberapa sering keputusan manusia berbeda dari rekomendasi sistem. Angka ketiga adalah sinyal paling jujur tentang kapan sebuah aturan sudah bisa dipercaya.

Ringkasan dan langkah berikutnya

Kasus pengecualian adalah bagian dari desain, dan workflow yang belum memikirkannya sebenarnya belum selesai. Pisahkan error teknis dari kasus bisnis, beri setiap jenis kasus jalurnya sendiri, dan biarkan manusia memegang keputusan yang mahal atau tidak bisa dibatalkan.

Checklist sebelum workflow masuk produksi

• Daftar kasus yang pernah meleset sudah ditulis dan diberi label "sistem" atau "data"
• Node yang memanggil layanan luar memakai retry dan punya cabang error output
• Tidak ada node berisiko yang memakai On Error > Continue biasa
• Error workflow sudah dibuat dan dipasang di pengaturan workflow
• Eksekusi produksi yang gagal disimpan, supaya notifikasi punya tautan penelusuran
• Kasus bisnis yang tidak memicu error dialihkan lewat Stop And Error atau antrean manual
• Setiap persetujuan manusia punya penyetuju bernama dan batas waktu
• Ada log sederhana untuk menghitung kasus per jalur

Cheat sheet

Kalau kamu sedang menyusun workflow baru, coba tuliskan kebutuhanmu sekaligus dengan jalur pengecualiannya, misalnya "kalau selisih di atas sekian, kirim ke tim keuangan untuk disetujui". n8n Workflow Generator di eduwebmu bisa membantu menyusun kerangka workflow dari deskripsi seperti itu. Periksa hasilnya dengan checklist di atas, terutama bagian error workflow dan pemilik jalur manusia, sebelum dipakai di produksi.