Kondisi
Condition adalah pengecekan opsional yang berjalan setelah trigger aktif dan sebelum task dimulai. Ia menjawab: "Adakah sesuatu yang layak dikerjakan sekarang?" Jika tidak, run berhenti dengan tenang.
"Cek SLA semua cabang setiap pagi. Kalau ada yang di bawah 80%, analisis penyebabnya dan kirim ke WhatsApp saya."
Tanpa condition, agent akan mengirim pesan ke user setiap pagi entah ada masalah atau tidak. Dengan condition, user hanya dikabari saat itu penting.
Rule terstruktur, bukan tebakan
User menjelaskan condition dengan kata-kata; agent mengubahnya menjadi rule terstruktur yang dievaluasi Qlar sendiri. Sebuah condition terdiri dari:
| Bagian | Rincian |
|---|---|
| Description | Condition dalam kata-kata, agar mudah dibaca orang. |
| Rules | Hingga 5. Setiap rule membandingkan satu nilai dengan target, misalnya SLA < 80 atau Region = "Jakarta". |
| Logic | All: semua rule harus terpenuhi, atau any: salah satu saja. |
Sebuah rule punya value checked (apa yang dilihat), sebuah comparison, dan sebuah value pembanding:
| Jenis nilai | Perbandingan |
|---|---|
| Number | <, ≤, >, ≥, =, ≠ |
| Text | =, ≠, contains, does not contain |
| Yes / No | =, ≠ |
Angka dibaca dengan toleran — 1.000.000, 80%, dan 80,5 semuanya dipahami.
Dari mana datanya
Agent sendiri yang membaca datanya — dengan tool dan skill yang sudah dimiliki agent Anda, seperti SQL Database Reader, custom API, atau knowledge base-nya. Di setiap run ia mengambil nilai terkini, melaporkannya ke Qlar, dan Qlar memutuskan met atau not met. Agent tidak memutuskan apakah condition terpenuhi; ia hanya melaporkan apa yang ditemukannya.
Dua aturan melindungi dari jawaban yang salah:
- Nilai harus berasal dari hasil tool yang nyata di run ini. Jika agent mencoba melaporkan angka tanpa membaca data apa pun, laporannya ditolak dan ia harus membaca datanya dulu. Ia tidak boleh memperkirakan atau memakai ulang angka dari percakapan sebelumnya.
- Nilai yang tidak bisa dibaca dilaporkan sebagai unknown, bukan dikarang.
Artinya condition hanya sebaik tool di belakangnya. Jika agent Anda tidak punya tool yang bisa membaca angkanya, ia tidak bisa mengecek condition-nya. Uji pertanyaan yang persis sama ("Berapa SLA setiap cabang hari ini?") di chat lebih dulu — jika agent bisa menjawabnya, ia bisa mengeceknya.
Apa yang dilakukan setiap hasil
| Hasil | Yang terjadi |
|---|---|
| Met | Task berjalan, lalu action. |
| Not met | Run berhenti. Tidak ada conversation yang dibuat dan tidak ada pesan WhatsApp yang dikirim. Dicatat di history sebagai Condition not met — yang normal, bukan kegagalan. |
| Unknown | Condition ada tetapi sebuah nilai tidak bisa dibaca. Diperlakukan sebagai met, sehingga user tidak dibiarkan tanpa kabar. Jika ini terjadi tiga kali berturut-turut, user mendapat notifikasi peringatan untuk memeriksa automation. |
| No condition | Automation tidak punya; task berjalan setiap kali. |
Mengedit condition
Di halaman Automations milik user, sebuah condition bisa diubah kata-katanya, diubah targetnya, atau dihapus. Condition tidak bisa ditambahkan atau diganti dengan pengecekan lain di sana — untuk itu user meminta agent dalam percakapan, yang kembali melewati langkah ringkasan-dan-konfirmasi.
Contoh
| User berkata | Condition |
|---|---|
| "Kalau SLA cabang mana pun di bawah 80%…" | SLA < 80 |
| "Hanya kalau saldo melebihi 1 miliar…" | Saldo > 1000000000 |
| "Kalau wilayah Jakarta punya lebih dari 5 tiket terbuka, atau ada tiket kritis…" | Tiket terbuka > 5, atau tiket Critical > 0 (logic: any) |
| "Kalau ada stok di bawah minimum di gudang mana pun…" | Margin stok terendah < 0 |
Buatlah condition tetap sederhana. Hingga lima rule yang digabung dengan all/any mencakup sebagian besar kebutuhan; yang lebih rumit lebih baik ditangani di dalam task itu sendiri — minta agent untuk "analisis dan laporkan hanya kalau …".