Odoo Automated Actions dan Scheduled Actions Tanpa Coding

Odoo bisa mengotomatiskan banyak pekerjaan rutin tanpa developer: membuat tindak lanjut, mengirim email, memperbarui field, dan menjalankan tugas terjadwal. Alatnya adalah automation rules (sering masih disebut automated actions), server actions, dan scheduled actions. Artikel ini menjelaskan fungsi masing-masing, kapan ia berhenti menjadi “tanpa kode”, dan kesalahan yang sebaiknya dihindari.

Jawaban singkat

• Automation rules bereaksi saat sesuatu terjadi pada sebuah record (dibuat, diubah, tanggal tertentu tiba, email masuk), lalu menjalankan satu atau beberapa action.
• Server actions adalah bagian “apa yang dilakukan”: mengubah record, membuat record, mengirim email, menjalankan Python, dan lainnya. Server action juga bisa dijalankan manual lewat tombol atau menu.
• Scheduled actions adalah pengatur waktu. Ia menjalankan pekerjaan setiap X menit, jam, hari, atau bulan, terlepas dari aktivitas pengguna.

Sebagian besar aturan bisnis sederhana (misalnya, “saat quotation dikonfirmasi, buat activity tindak lanjut untuk account manager”) tidak butuh kode sama sekali. Begitu butuh logika sungguhan, Anda menulis Python, dan itu mengubah beban pemeliharaannya.

Automation rules: trigger, kondisi, action

Menurut dokumentasi Odoo tentang automation rules, sebuah rule terdiri dari trigger, kondisi opsional, dan satu atau lebih action.

Kategori trigger meliputi:

• Values updated: tag ditambahkan, atau sebuah field diberi nilai tertentu.
• Email events: email diterima atau dikirim.
• Timing conditions: berdasarkan field tanggal, setelah pembuatan, atau setelah pembaruan terakhir, dengan delay (delay negatif menjalankan action sebelum tanggal tersebut).
• Custom: on save, on deletion, atau on UI change.
• External: dipicu sistem luar lewat webhook.

Kondisi mempersempit cakupan. Domain “before update” memeriksa record sebelum perubahan, dan kondisi tambahan memeriksanya sesudahnya. Inilah yang mencegah rule berjalan pada setiap record di sistem.

Action yang bisa dipasang, menurut dokumentasi yang sama, antara lain mengubah record, membuat activity, mengirim email atau SMS, mengirim WhatsApp (butuh template), menambah atau menghapus follower, membuat record, menjalankan kode, mengirim notifikasi webhook, dan menjalankan action yang sudah ada. Bila Anda memasang beberapa action, semuanya berjalan sesuai urutan yang Anda tentukan.

Server actions: blok pembangun

Secara teknis, referensi developer Odoo untuk actions menjelaskan server actions (ir.actions.server) dengan empat tipe utama:

Tipe	Fungsi
Execute code	Menjalankan Python dari field code
Create record	Membuat record di model lain dari nilai field yang Anda tentukan
Update record	Mengubah record saat ini dari nilai field
Multi (execute several)	Menjalankan daftar action lain secara berurutan

Tiga dari empat tipe ini murni konfigurasi, bukan pemrograman. Hanya “execute code” yang menuntut pertimbangan developer. Server action juga bisa dipakai ulang: action yang sama dapat dipanggil dari automation rule, tombol, atau menu Action di list view.

Scheduled actions: tugas berdasarkan waktu

Scheduled actions (ir.cron dalam model teknis) berjalan pada frekuensi tetap. Referensi developer mencantumkan pengaturan utamanya: nama, angka dan tipe interval (menit sampai bulan), model, kode atau server action yang dijalankan, waktu panggilan berikutnya, dan prioritas.

Di developer mode, Anda menemukannya di Settings, Technical, Scheduled Actions. Pemakaian umum:

• Pembersihan malam hari untuk record draft yang basi
• Email pengingat mingguan untuk item yang terlambat
• Sinkronisasi berkala dengan sistem luar

Dua perilaku yang perlu diketahui:

• Batching. Pekerjaan panjang diharapkan melaporkan progres agar scheduler dapat memprosesnya per potongan. Secara default ia menangani hingga 10 batch per run, lalu memulai run lain bila pekerjaan masih tersisa.
• Penanganan kegagalan. Dokumentasi menyebut tiga error atau timeout berturut-turut membuat sebuah run dilewati dan dihitung gagal, dan lima kegagalan berturut-turut yang membentang minimal tujuh hari menonaktifkan action dan memberi tahu administrator database. Jadi tugas yang rusak bisa berhenti diam-diam bila tidak ada yang memantau.

Automation rule berbasis waktu juga bergantung pada scheduler. Secara default, menurut dokumentasi, ia diperiksa setiap 240 menit, dan untuk delay di bawah 2.400 menit frekuensi pemeriksaan dihitung ulang agar delay pendek lebih terpenuhi. Jadi “kirim satu jam setelah dibuat” tidak berjalan tepat sampai ke menit. Jika ketepatan waktu penting, uji dulu.

Apa yang realistis dilakukan tanpa kode

Kandidat yang baik:

1. Tugas tindak lanjut. Saat opportunity mencapai tahap tertentu, buat activity untuk pemiliknya.
2. Notifikasi. Saat invoice terlambat melewati delay tertentu, kirim email dari template.
3. Default field dan tagging. Saat customer dibuat di negara tertentu, tambahkan tag atau tetapkan salesperson.
4. Pengingat persetujuan. Saat purchase order belum dikonfirmasi melewati tenggat, buat activity untuk manajer.
5. Serah terima lewat webhook. Beri tahu tool eksternal saat record berubah (lihat peringatan di bawah).

Kandidat yang kurang cocok: perhitungan lintas banyak record, logika bercabang, pemanggilan API eksternal dengan autentikasi, atau perbaikan data massal. Semua itu butuh kode, pengujian, dan penanggung jawab.

Kesalahan yang perlu dihindari

• Tidak memilih field pada “when updating field”. Dokumentasi memperingatkan bahwa action bisa berjalan beberapa kali per record. Selalu batasi trigger update.
• Rule yang memicu rule lain. Satu automation mengubah field, lalu memicu automation lain, dan seterusnya. “On UI change” adalah kasus khusus: menurut dokumentasi, ia hanya bekerja dengan execute code dan hanya untuk edit manual, bukan saat rule lain mengubah field.
• Webhook tanpa keahlian. Dokumentasi tidak menyarankannya tanpa pengetahuan teknis, karena webhook yang salah konfigurasi dapat mengganggu database dan pemulihannya bisa memakan waktu.
• Python yang tersembunyi. Kode di dalam action tersimpan di database, bukan di version control. Dokumentasikan, dan uji di salinan sebelum produksi.
• Lupa cakupan dukungan. Dokumentasi Odoo mencatat bahwa pemeliharaan kode kustom tidak termasuk dalam paket harga Standard atau Custom dan dikenai biaya tambahan. Jika Anda menulis kode, harus ada yang memilikinya, termasuk saat upgrade versi.

Posisinya di edisi Odoo Anda

Automation rules didokumentasikan sebagai bagian dari dokumentasi Odoo Studio, yang menjelaskan pembuatannya lewat Studio. Edisi dan paket berubah antarversi, jadi cek apa yang termasuk di paket dan opsi hosting Anda sebelum merancang solusinya.

Cara memulai yang masuk akal

1. Daftar lima tindak lanjut manual yang paling sering diulang tim Anda.
2. Bangun satu sebagai automation rule dengan trigger sempit dan kondisi yang jelas.
3. Uji di salinan atau pada beberapa record, dan pantau chatter serta log.
4. Baru setelah itu tambahkan rule berikutnya. Simpan register sederhana: nama rule, pemilik, tujuan, tanggal.
5. Tinjau scheduled actions setiap kuartal, dan pastikan ada yang diberi peringatan bila ada yang gagal.

Jika sebuah rule butuh kode, perlakukan seperti kustomisasi lainnya: dokumentasikan, uji, dan tunjuk pemiliknya.

Mari bicarakan

Jika Anda ragu apakah suatu proses cocok dijadikan rule tanpa kode, modul kustom kecil, atau sebaiknya tetap manual, Teknologia Solutions bersedia membahasnya bersama Anda, tanpa biaya dan tanpa kewajiban. Ceritakan apa yang ingin Anda otomatiskan, dan kami akan memberi pandangan yang jujur.

---

Sumber: Dokumentasi Odoo 18: Automation rules; Referensi developer Odoo 18: Actions. Perilaku, nilai default, dan isi paket berbeda antarversi dan edisi Odoo, jadi verifikasi detailnya ke sumber primer dan kontrak Anda sebelum mengandalkannya.