Otomasi, Persetujuan, dan Perintah Eksternal

Tiga alat operasional membantu menangani percakapan dan integrasi yang berulang: aturan otomasi yang bereaksi pada peristiwa, alur persetujuan sebelum aksi sensitif, dan perintah eksternal yang memicu tindakan terintegrasi.

Tujuan

• Membuat aturan otomasi yang menjalankan aksi (menugaskan agen, mengubah status/prioritas, menambah label) saat peristiwa terjadi.
• Menguji dan memantau eksekusi aturan beserta kegagalannya.
• Membuat kebijakan persetujuan serta alur menyetujui/menolak aksi.
• Membuat dan menjalankan perintah eksternal dengan idempotensi dan pengulangan.

Untuk siapa

• Owner/admin: membuat/mengubah/menghapus aturan otomasi, mengujinya, menyetujui/menolak dan membatalkan permintaan persetujuan, serta mengirim perintah (approve_actions, dispatch_commands).
• Agent: melihat aturan dan eksekusinya; membuat permintaan persetujuan; membuat/mengirim perintah yang diizinkan; melihat daftar perintah.
• Viewer/anggota lain: melihat aturan, eksekusi, dan daftar persetujuan sesuai akses workspace.

Prasyarat

• Peran workspace sudah ditetapkan (lihat Mengelola pengguna, tim, dan inbox).
• Izin terkait: approve_actions (persetujuan) dan dispatch_commands (perintah) — owner/admin.
• Untuk perintah eksternal yang berefek langsung (mis. refund, batalkan pesanan): kebijakan persetujuan aktif menyetujui permintaan, dan adaptor untuk jenis perintah terdaftar (lihat Batasan).

Alur kerja

1. Membuat aturan otomasi

1. Buka pengaturan Otomasi (owner/admin).
2. Buat aturan dengan:
   • nama dan event_type (peristiwa pemicu);
   • kondisi (JSON);
   • aksi berurutan — tiap aksi: assign (assignee/team), status, priority, atau add_label;
   • prioritas (nilai lebih tinggi menang) dan status aktif/nonaktif;
   • cooldown_seconds (bawaan 60) dan batas eksekusi per percakapan (jika ada).
3. Simpan aturan.

Aturan hanya terpicu pada dua jenis peristiwa: pesan masuk yang diterima (inbound webhook) dan peristiwa n8n.<action> dari alur eksternal. Status percakapan dan peristiwa lain hanya mencatat acara keluar dan tidak memicu aturan. Otomasi tidak memakai AI; semua aksi bersifat mekanis.

2. Menguji dan memantau aturan

1. Gunakan aksi uji (test) pada aturan untuk menjalankannya terhadap data contoh.
2. Buka daftar eksekusi aturan untuk melihat apakah aturan cocok (matched), aksi yang diambil (actions_taken), dan pesan kesalahan (error_message) bila ada.
3. Aksi yang tidak dikenal ditandai skipped (jenis aksi tak didukung); aksi yang gagal dicatat per-aksi, sementara evaluasi aturan tetap berlanjut ke aksi lain.

3. Mengelola kebijakan persetujuan

1. Buka pengaturan kebijakan persetujuan (owner/admin).
2. Untuk tiap jenis aksi (action_type), tentukan:
   • require_approval (perlu persetujuan);
   • min_approvers (jumlah penyetuju minimal untuk kuorum);
   • allowed_roles (peran yang boleh menyetujui);
   • expires_after (masa berlaku permintaan).
3. Simpan (upsert); kebijakan berlaku untuk permintaan aksi berikutnya dengan jenis tersebut.

4. Membuat dan memutuskan permintaan persetujuan

1. Buat permintaan persetujuan dengan jenis aksi dan muatan (payload) yang relevan (operator/agent).
2. Penyetuju (peran dalam allowed_roles, bukan pembuat permintaan) menyetujui atau menolak; penolakan wajib menyertakan alasan.
3. Permintaan mencapai kuorum min_approvers → disetujui; masa berlaku habis → kadaluwarsa; pembuat dapat membatalkan permintaannya sendiri.
4. Pantau status: pending, approved, rejected, expired, cancelled.

5. Mengirim dan menjalankan perintah eksternal

1. Buat perintah dengan command_type dan idempotency_key. Kunci idempotensi unik per workspace; kunci yang sama mengembalikan perintah yang sudah ada (aman dipakai ulang).
2. Untuk jenis perintah berisiko (mis. refund, cancel_order), pastikan permintaan persetujuan terkait sudah disetujui; tanpa itu eksekusi ditolak.
3. Jalankan perintah. Status berpindah pending → dispatched → completed; kegagalan memicu pengulangan (maks. 3, jeda tumbuh 1, 2, 4 … menit) hingga failed atau cancelled.
4. Pantau daftar perintah dan jejak audit peristiwanya (buat/gagal/selesai).

Tanda berhasil

• Aturan otomasi tampil aktif; eksekusi menampilkan aksi yang diambil pada peristiwa masuk yang cocok.
• Uji aturan mengembalikan hasil deterministik tanpa efek permanen.
• Permintaan persetujuan terlihat oleh penyetuju yang diizinkan; keputusan tercatat beserta penyetuju dan waktu.
• Perintah terkirim dengan idempotensi; status akhir completed atau failed terpantau di daftar.

Jika terjadi masalah

Gejala	Penyebab	Pemulihan
403 saat menyimpan/mengubah aturan	manage-rule hanya owner/admin	Hubungi owner workspace
403 saat menyetujui/menolak	Tidak memiliki approve_actions	Minta penyetuju yang diizinkan
403 saat mengirim perintah	Tidak memiliki dispatch_commands	Minta owner/admin
Eksekusi perintah gagal no adapter	Tidak ada adaptor terdaftar untuk jenis perintah	Siapkan/daftarkan adaptor (lihat Batasan)
Eksekusi perintah berisiko ditolak	Permintaan persetujuan terkait belum approved	Selesaikan alur persetujuan dulu
Tidak bisa menyetujui permintaan sendiri	Penyetuju tidak boleh = pembuat permintaan	Minta anggota lain menyetujui
Kuorum tidak tercapai	Jumlah penyetuju < min_approvers	Tambah penyetuju sesuai allowed_roles
Aturan tidak memicu	Peristiwa yang terjadi bukan pemicu (hanya pesan masuk + n8n.<action>)	Periksa event_type dan status aturan aktif

Batasan

• Otomasi — melihat aturan/eksekusi tersedia bagi semua anggota; membuat/mengubah/menghapus/menguji hanya owner/admin. Pemicu terbatas pada pesan masuk dan peristiwa n8n.<action>; tidak ada peristiwa AI. Aksi didukung: assign, status, priority, add_label; lainnya ditandai skipped.
• Persetujuan — approve_actions untuk menyetujui/menolak (owner/admin); pembuatan permintaan, pembatalan, dan daftar tersedia untuk anggota workspace. Penyetuju tidak boleh sama dengan pembuat; kuorum dan peran diatur kebijakan.
• Perintah eksternal — mengirim = dispatch_commands (owner/admin). Eksekusi menuntut adaptor jenis perintah yang terdaftar; tanpa adaptor, perintah gagal dengan no adapter for ... meskipun status permintaan sudah disetujui. Saat ini belum ada adaptor yang terdaftar di proses server, sehingga perintah tidak dapat benar-benar dieksekusi sampai adaptor dipasang — kondisi ini dikonfigurasi (configuration-required), bukan siap pakai.
• Perintah berisiko (refund, cancel_order) menolak eksekusi kecuali permintaan persetujuan terkait berstatus approved.
• Fitur perintah eksternal membutuhkan adaptor; tanpa pemasangan, seluruh eksekusi berstatus gagal. Siapkan adaptor sebelum mengandalkan alur ini.
• Kontrak permintaan lengkap ada di Referensi API.

Tugas terkait

• Kampanye dan Template Pesan — persetujuan sebelum aksi kampanye
• Mengelola pengguna, tim, dan inbox
• Laporan, ekspor, dan CSAT
• Referensi API