Administrasi

Automation

Aturan otomatis: arahkan tiket, tanggapi status dan SLA, tutup tiket yang lama terselesaikan.

Aturan automation menjalankan pekerjaan berulang tanpa klik manual: mengarahkan tiket baru ke tim, menaikkan prioritas atau memindahkan tim saat SLA terancam, memberi tahu petugas dan ketua tim, mengirim webhook ke sistem lain, dan menutup tiket yang lama terselesaikan. Aturan dikelola di Administrasi → Automation oleh pengguna dengan izin Kelola aturan automation (bawaan: Admin workspace dan Admin service desk). Auditor bisa melihat aturan dan jejaknya tanpa mengubah.

Bentuk aturan

Setiap aturan terdiri dari pemicu, kondisi, dan tindakan. Pratinjau di bawah formulir menuliskannya sebagai satu kalimat, misalnya "Bila status berubah ke Menunggu pada tiket dengan subjek memuat “printer”, maka pindah ke tim Infrastruktur; beri tahu ketua tim."

PemicuKapan berjalan
Tiket baru dibuatSaat tiket dibuat. Satu-satunya tindakan: mengisi tim.
Status tiket berubahSetiap kali status berubah, oleh orang maupun sistem. Bisa dibatasi status asal dan status tujuan.
SLA mendekati tenggatSaat waktu kerja yang terpakai pada target respons pertama atau penyelesaian mencapai ambang berisiko kebijakan SLA tiket (bawaan 80 % dari target).
SLA terlanggarSaat tenggat target terlewati.
Tetap terselesaikan N hariInsiden yang tetap Terselesaikan selama N hari kalender sejak penyelesaian terakhir (1–90 hari).

"Mendekati tenggat" dihitung dalam jam kerja kalender SLA tiket, sama dengan tenggatnya. Waktu di luar jam kerja dan waktu dijeda tidak dihitung. Ambangnya diatur per kebijakan di Kebijakan SLA dan sama dengan yang dipakai saringan antrean "SLA berisiko", dasbor, dan email berisiko.

Kondisi sama untuk semua pemicu: jenis tiket, kanal masuk, prioritas, site, layanan terdampak, dan kata kunci di subjek. Kondisi dinilai atas keadaan tiket saat aturan berjalan. Prioritas yang dinilai adalah prioritas saat itu, bukan saat tiket dibuat.

Untuk pemicu Status tiket berubah dengan tujuan Menunggu saja, ada kondisi tambahan Alasan menunggu (menunggu pengguna, vendor, atau internal). Dengan kondisi ini, aturan "ditunda vendor → pindah ke tim Infrastruktur" tidak ikut memindahkan tiket yang sedang menunggu jawaban pelapor.

Tindakan

TindakanYang terjadi
Ubah prioritasPrioritas diganti ke nilai yang Anda pilih. Tidak ada nilai bawaan dan tidak ada "naikkan satu tingkat".
Ubah timTiket dipindah ke tim lain. Petugas tetap bila ia anggota tim baru. Bila bukan, tiket kembali ke antrean tim, dan tiket Dikerjakan menjadi Ditugaskan.
Tutup tiketHanya untuk pemicu "Tetap terselesaikan N hari": Terselesaikan menjadi Ditutup.
Kirim notifikasi internalEmail ke petugas tiket, ke ketua tim (anggota tim tiket yang berperan Team Lead), atau keduanya.
Kirim webhookPeristiwa automation.rule_triggered.v1 ke satu langganan webhook (lihat di bawah).

Satu aturan boleh berisi beberapa tindakan, dan setiap jenis paling banyak sekali. Tindakan selalu dijalankan berurutan: prioritas, tim, tutup, lalu notifikasi dan webhook. Dengan begitu, notifikasi dan webhook menggambarkan keadaan sesudah perubahan.

Perubahan oleh aturan tercatat di linimasa tiket dengan pelaku Sistem dan keterangan "otomatis oleh aturan “…”", serta di log audit.

Prioritas dan SLA

Mengubah prioritas, baik oleh aturan maupun manual, menghitung ulang target SLA dari kebijakan yang sudah dipakai tiket. Ada dua jaminan:

  • Timer tidak direset. Waktu kerja yang sudah terpakai dan awal hitungan tetap. Yang berubah hanya angka target dan tenggatnya.
  • Pelanggaran tidak hilang. Target yang tenggatnya sudah terlewat ditandai terlanggar sebelum target diubah. Bila prioritas dinaikkan sehingga target baru yang lebih ketat langsung terlewat, target itu juga ditandai terlanggar saat itu juga, dan tetap terlanggar walau prioritas diturunkan lagi. Kartu SLA tetap menulis "Terlewat … tetap dihitung terlanggar", dan laporan tetap menghitungnya terlanggar, walau target baru lebih longgar.
  • Prioritas tanpa target menangguhkan, bukan mengakhiri. Bila aturan atau petugas mengubah ke prioritas tanpa target lalu kembali ke prioritas bertarget, target aktif kembali dengan waktu terpakai yang sama (lihat SLA dan tenggat).

Tutup otomatis

Tutup otomatis tidak aktif secara bawaan. Tombol Contoh: tutup otomatis 7 hari mengisi formulir dengan aturan "insiden Terselesaikan 7 hari tanpa balasan publik → tutup" dalam keadaan nonaktif. Aturan baru tersimpan setelah Anda menekan Simpan.

  • Dasar hitungan: N hari kalender, termasuk akhir pekan dan libur, sejak tiket terakhir diselesaikan.
  • Pembatal: balasan publik apa pun sesudah penyelesaian, dari pelapor, petugas, atau integrasi, membatalkan tutup otomatis untuk penyelesaian itu. Tiket baru layak lagi sesudah ditangani dan diselesaikan ulang. Catatan internal tidak membatalkan.
  • Pratinjau: formulir menunjukkan berapa insiden yang saat ini sudah memenuhi syarat. Tiket-tiket itu ikut tertutup begitu aturan aktif, paling banyak 100 per menit.
  • Konfirmasi: menyalakan aturan tutup otomatis, dari formulir maupun dari sakelar Aktif di daftar, selalu menampilkan jumlah itu dan meminta konfirmasi.
  • Kabar ke pelapor: pelapor menerima kabar perubahan status seperti penutupan manual. Portalnya menulis "ditutup otomatis karena tidak ada balasan selama N hari sesudah solusi diberikan".

Hanya insiden yang punya tahap Terselesaikan. Permintaan layanan sudah berakhir di Selesai, Ditolak, atau Dibatalkan.

Webhook aturan vs langganan biasa

Langganan webhook di Administrasi → Integrasi menerima setiap peristiwa bertipe yang dilanggani. Tindakan Kirim webhook pada aturan berbeda:

Langganan biasaTindakan webhook aturan
Kapan dikirimSetiap peristiwa bertipe ituHanya saat aturan cocok
TujuanSemua langganan aktif yang memilih tipe ituSatu langganan yang dipilih di aturan
Tipe peristiwaticket.status_changed.v1, sla.breached.v1, …automation.rule_triggered.v1
Isidata.ticket + perubahandata.ticket + data.automation (aturan, pemicu, source_event_id)

Pengiriman memakai mekanisme Integrasi yang sama: tanda tangan HMAC, enam percobaan, nonaktif otomatis, riwayat, dan kirim ulang.

Mencegah kiriman ganda. Bila langganan yang dipilih juga melanggani tipe peristiwa pemicunya (mis. aturan "status berubah" dikirim ke langganan yang juga menerima ticket.status_changed.v1), satu kejadian menghasilkan dua kiriman. Formulir aturan memperingatkan hal ini. Keduanya membawa event_id asal yang sama: data.automation.source_event_id sama dengan event_id kiriman biasa, sehingga penerima bisa membuang salah satunya. Cara paling sederhana adalah membuat langganan tanpa peristiwa khusus untuk aturan. Kartu langganan di Integrasi menyebut aturan yang mengirim ke sana.

Admin service desk boleh memilih langganan yang sudah dibuat Admin workspace, tetapi tidak bisa melihat URL atau rahasianya. Membuat dan mengubah langganan tetap butuh izin Integrasi. Langganan dan tim yang masih dipakai aturan tidak bisa dihapus sebelum aturannya diubah.

Urutan dan beberapa aturan sekaligus

Aturan dicek dari atas ke bawah:

  • Tiket baru: aturan pertama yang cocok mengisi tim. Tiket yang sudah punya tim dari katalog atau mailbox tidak diubah.
  • Pemicu lain: semua aturan yang cocok berjalan. Bila dua aturan mengubah hal yang sama (tim, prioritas, atau status) untuk kejadian yang sama, aturan yang lebih atas yang berlaku. Tindakan sejenis dari aturan di bawahnya tercatat "sudah diubah aturan “…” untuk kejadian yang sama". Tindakan lain, mis. notifikasi, tetap berjalan.

Batas 100 aturan per workspace berlaku untuk semua pemicu bersama. Daftar aturan bisa dicari berdasarkan nama dan disaring per pemicu. Saat tersaring, urutan tidak bisa diubah, karena urutan berlaku untuk seluruh daftar.

Pengaman

  • Tidak ganda. Satu aturan dijalankan paling banyak sekali per kejadian per tiket, walau worker mengulang atau dua worker berjalan bersamaan.
  • Diperiksa ulang. Aturan pemicu status, SLA, dan N hari dinilai worker beberapa detik sesudah kejadian. Tepat sebelum bertindak, keadaan tiket dibaca ulang. Bila status sudah berubah lagi, target SLA sudah selesai, atau tiket sudah dibalas, aturan dilewati dan alasannya dicatat.
  • Tidak berputar. Tindakan aturan, mis. tutup atau serah-terima, boleh memicu aturan lain satu kali lagi, tetapi tidak memicu aturan itu sendiri. Satu aturan paling banyak berhasil 10 kali per tiket per 24 jam. Kejadian yang lebih tua dari 24 jam saat dinilai (mis. setelah gangguan) dilewati.

Jejak eksekusi

Tab Jejak eksekusi mencatat:

  • Tiket baru: satu baris per tiket yang dibuat saat ada aturan tiket baru aktif.
  • Pemicu lain: satu baris setiap kali aturan cocok dengan kejadiannya, berisi pemicu (mis. "Status berubah dari Dikerjakan ke Menunggu") dan tindakan dengan hasilnya masing-masing ("Ubah tim · dijalankan — Service Desk → Infrastruktur").
  • Dilewati: alasannya ikut dicatat, misalnya "status sudah menjadi Dikerjakan sebelum aturan dijalankan", "ada balasan publik sesudah diselesaikan", atau "tidak ada penerima".

Saring berdasarkan hasil, aturan, atau pemicu, dan cari nomor tiket untuk menjawab "kenapa tiket ini (tidak) berubah?".

Langkah antara "Mulai kerjakan" (Baru → Ditinjau → Ditugaskan → Dikerjakan) juga perubahan status. Karena berlangsung dalam sekejap, aturan yang menunggu "ke Ditinjau" biasanya tercatat dilewati.