Review workflow sebelum publish: tata kelola otomasi untuk tim

Review workflow di n8n adalah fitur yang mewajibkan satu versi workflow disetujui reviewer sebelum dipublikasikan. Fitur ini hadir sejak n8n 2.37.0, khusus paket Enterprise, dan masih berstatus Preview. Yang diperiksa hanya node dan koneksi. Kredensial, variabel, dan pengaturan workflow tetap berubah tanpa persetujuan siapa pun.

Tesis saya: fitur review hanyalah satu lapis tata kelola, dan lapis yang paling sering bocor justru ada di luar jangkauannya. Tim yang belum punya kebiasaan memberi nama versi, memisahkan draf dari produksi, dan menjaga kredensial tidak akan tiba-tiba rapi hanya karena ada tombol Approve. Sebaliknya, tim kecil tanpa paket Enterprise tetap bisa punya proses review yang layak.

Yang perlu diluruskan dulu

Banyak orang mengira "review workflow" berarti n8n memeriksa logika workflow secara otomatis. Tidak begitu. Fitur ini murni alur persetujuan antarmanusia: seseorang mengajukan versi, orang lain melihat perbedaannya, lalu menyetujui atau meminta perubahan. n8n tidak menilai apakah workflow kamu benar.

Kesalahpahaman kedua: review dianggap mengunci semua hal yang berkaitan dengan workflow. Halaman resmi Review workflows justru menyebut daftar hal yang tidak ikut direview. Bab "Yang tidak ikut direview" membahasnya, karena di situlah risiko terbesar untuk tim.

Catatan jujur. Artikel ini ditulis 2 November 2026. Semua fakta diambil dari dokumentasi resmi n8n, dan belum dari uji langsung di instance Enterprise. Fitur review masih berstatus Preview, dan n8n sendiri menyarankan untuk belum mengandalkannya di workflow produksi. Detailnya bisa berubah sebelum rilis umum.

Artikel ini untuk kamu yang memakai n8n bersama dua orang atau lebih, entah di kantor, agensi, atau tim operasional bisnis. Kalau kamu satu-satunya pembuat workflow, sebagian besar isinya tetap berguna sebagai disiplin pribadi, tapi fitur review sendiri tidak relevan.

Draft, publish, dan versi: fondasi sebelum review

Sebelum membahas review, pahami dulu model kerja n8n saat ini. Menurut halaman Save and publish workflows, n8n menyimpan otomatis setiap perubahan, biasanya dalam 1 sampai 5 detik. Semua suntingan tetap berstatus draf sampai kamu menekan Publish.

Publish artinya mengunci satu versi tertentu untuk produksi. Eksekusi produksi, seperti webhook, jadwal, dan event dari aplikasi lain, selalu memakai versi yang sedang dipublikasikan. Suntingan terbarumu tidak ikut jalan sampai dipublikasikan ulang. Ini sudah merupakan bentuk pengaman: mengedit tidak sama dengan mengubah produksi.

Ada beberapa detail yang sering terlewat:

• Satu editor dalam satu waktu. Kalau rekan sedang mengedit, kamu hanya melihat mode baca. Kunci edit lepas saat ia berhenti atau tidak aktif.
• Pengaturan workflow ikut terbit sendiri. Dokumentasi menyebut, bila kamu hanya mengubah pengaturan workflow, n8n memublikasikan ulang versi tersebut tanpa tindakan tambahan.
• Publish bisa sebagian. Bila satu trigger gagal aktif, misalnya karena aplikasi tersambung sedang tidak tersedia, status menjadi Published, partial. Trigger lain tetap jalan.

Lapis berikutnya adalah riwayat versi. Halaman View change history menjelaskan bahwa n8n membuat versi baru setiap kali workflow disimpan, setiap kali versi lama dipulihkan, dan setiap kali menarik perubahan dari Git. Perubahan pengaturan workflow tidak membuat versi baru.

Masalahnya ada di masa simpan. Semua pengguna hanya bisa melihat versi 24 jam terakhir. n8n Cloud Pro mendapat lima hari. Riwayat penuh hanya tersedia di Enterprise. Penyelamatnya adalah named version, yaitu versi yang diberi nama dan deskripsi. Versi bernama tidak pernah dihapus otomatis, dan fitur ini ada di Cloud Pro, Cloud Enterprise, serta self-hosted Business dan Enterprise.

Cara kerja workflow reviews di n8n

Menurut dokumentasi resmi, workflow reviews tersedia untuk n8n Cloud Enterprise dan self-hosted Enterprise, mulai versi 2.37.0. Admin instance menyalakannya di Settings > Security & policies. Setelah aktif, review bersifat opsional: pengguna masih bisa publish langsung, kecuali workflow itu sedang punya review terbuka.

Alurnya begini. Dari menu Publish, pembuat workflow memilih Submit for review. Ia mengisi nama versi, judul review, dan menunjuk satu reviewer. Review itu terikat pada satu versi tersimpan yang disebut pinned version. Kamu boleh terus mengedit, tapi versi yang direview tidak berubah sampai kamu mengirim perubahan baru ke review yang sama.

Status yang perlu kamu kenali:

Selama review terbuka, n8n memblokir publish dari editor, dari public API, dan dari server MCP n8n. Satu workflow hanya boleh punya satu review terbuka. Unpublish tetap bisa dilakukan, tapi tidak menutup review.

Di halaman detail review ada dua tab. Tab Activity berisi deskripsi dan komentar. Tab Changes menampilkan diff visual antara versi yang sedang live dan versi yang direview. Diff adalah tampilan perbandingan yang menandai node yang ditambah, diubah, atau dihapus.

Soal izin, ada dua hal yang menurut saya bagus. Reviewer cukup punya izin workflow:read, tidak perlu izin publish. Lalu, saat disetujui, publish dicatat atas nama pengaju, bukan reviewer. Jejak audit jadi jujur: yang membuat perubahan tetap tercatat sebagai pemiliknya. Yang berhak memutuskan adalah reviewer yang ditunjuk, admin proyek, atau admin instance. Pengaju tidak bisa menyetujui karyanya sendiri, kecuali ia juga memegang salah satu peran itu.

Ada empat keterbatasan yang wajib kamu tahu sebelum mengandalkannya:

1. n8n tidak mengirim email atau notifikasi eksternal saat reviewer ditunjuk atau saat reviewer meminta perubahan. Reviewer harus rajin membuka menu Reviews.
2. Review yang terbuka belum bisa dibatalkan atau ditarik. n8n menyebut fitur ini direncanakan untuk rilis mendatang.
3. Komentar belum bisa ditempelkan ke node tertentu.
4. Opsi Review required di menu Publish hanya tersimpan di browser pengguna itu. Opsi ini tidak memaksa rekan lain mengajukan review.

Pendapat saya: poin pertama paling berbahaya di praktik. Review yang tidak ada yang tahu sama dengan workflow yang tertahan. Tentukan jalur pemberitahuan sendiri, misalnya pesan di grup tim setiap kali mengajukan review.

Yang tidak ikut direview, dan kenapa itu penting

Bagian ini yang paling jarang dibaca, padahal paling menentukan. Dokumentasi n8n menyatakan review hanya mencakup isi satu workflow, yaitu node dan koneksi pada versi yang diajukan. Lima hal berikut tidak masuk diff, tidak menunggu persetujuan, dan langsung berlaku pada workflow yang sedang live:

• Pengaturan workflow, seperti zona waktu, error workflow, dan urutan eksekusi.
• Kredensial yang dipakai workflow.
• Variabel.
• Data tables, yaitu tabel data bawaan n8n.
• Sub-workflow yang dipanggil. Masing-masing punya review sendiri, kalau ada.

Bayangkan skenario ini. Workflow pengiriman invoice sudah lolos review dan live. Lalu seseorang mengganti kredensial email ke akun lain, atau mengubah zona waktu sehingga jadwal bergeser tujuh jam. Tidak ada review yang tersentuh. Perubahan itu langsung berlaku di produksi.

Jadi saya tidak menyarankan menganggap review sebagai pengaman tunggal. Review menjaga logika workflow. Kredensial dan sub-workflow perlu dijaga lewat pembagian akses: siapa boleh mengubah kredensial, dan siapa boleh menyunting workflow anak yang dipanggil banyak workflow lain.

Ada satu sinyal lagi bahwa fitur ini masih bergerak. Halaman review menyebut satu review mencakup satu workflow. Sementara itu, catatan rilis n8n versi 2.45 sudah memuat perubahan "Show multiple workflows in the review detail view" yang menampilkan beberapa workflow dalam satu review. Dari sumber resmi yang saya baca, belum jelas kapan perilaku ini berlaku untuk semua pengguna, jadi anggap belum terverifikasi.

Tata kelola tanpa paket Enterprise

Workflow reviews hanya ada di paket Enterprise. Kalau tim kamu memakai paket lain, apakah berarti tidak bisa punya proses review? Bisa, dengan alat yang sudah ada dan sedikit disiplin. Ini urutan yang saya sarankan, dari yang paling murah.

1. Pisahkan pembuat dan pemberi izin publish. Model draf dan publish n8n sudah memisahkan suntingan dari produksi. Tinggal sepakati aturan tim: siapa pun boleh mengedit, tapi hanya satu atau dua orang yang menekan Publish setelah melihat perubahannya.

2. Wajibkan nama versi. Kalau paketmu mendukung named versions, setiap publish harus punya nama dan deskripsi singkat. Ini cara termurah membuat catatan perubahan yang tidak hilang setelah 24 jam.

3. Pakai source control bila tersedia. Untuk tim yang lebih serius, n8n punya fitur source control dan environments yang menghubungkan instance ke Git, tersedia di paket Business dan Enterprise. Dokumentasi n8n menyebut pola umum berupa lingkungan pengembangan dan lingkungan produksi yang terpisah. Halaman Compare versions menjelaskan diff visual saat push atau pull: node yang ditambah, diubah, dan dihapus diberi tanda berbeda. Diff ini ada di n8n Cloud Enterprise serta self-hosted Business dan Enterprise. Satu catatan: menurut dokumentasi, nilai kredensial dan variabel tidak ikut disinkronkan ke Git, jadi keduanya tetap perlu dijaga lewat pembagian akses.

4. Buat ritual review manual. Sebelum publish, pembuat workflow mengirim ringkasan perubahan ke rekan. Rekan membaca workflow dan bertanya hal sederhana: trigger apa, data siapa yang tersentuh, kredensial mana yang dipakai, dan apa yang terjadi kalau gagal.

Saya pilih urutan ini karena biayanya naik bertahap. Poin 1 dan 4 gratis dan bisa mulai besok. Poin 3 baru masuk akal bila tim sudah punya lebih dari satu instance atau sering bertabrakan saat mengedit.

Yang tidak saya sarankan: menunggu paket Enterprise baru mulai merapikan proses. Fitur review hanya mempercepat kebiasaan yang sudah ada. Tanpa kebiasaan itu, tombol Approve akan ditekan tanpa dibaca.

Ringkasan dan langkah berikutnya

Checklist tata kelola workflow tim

• Tahu paket n8n yang dipakai tim, dan fitur mana yang tersedia di paket itu
• Ada kesepakatan siapa yang boleh menekan Publish
• Setiap publish diberi nama versi dan deskripsi singkat
• Akses ubah kredensial dibatasi pada orang tertentu
• Sub-workflow yang dipakai banyak workflow punya penanggung jawab jelas
• Ada jalur pemberitahuan di luar n8n untuk permintaan review
• Kalau memakai workflow reviews, tim sadar fitur ini masih Preview

Cheat sheet fitur dan paket

Review apa pun, otomatis atau manual, gagal kalau reviewer tidak paham isi workflow yang dibacanya. Ini masalah nyata ketika workflow dibuat orang lain dan berisi puluhan node. n8n Workflow Explainer di eduwebmu bisa membantu reviewer memahami alur sebuah workflow sebelum memberi persetujuan. Tetap cocokkan penjelasannya dengan lima hal di luar review di atas, karena bagian itu tidak terlihat di diagram workflow.