User Task
User Task adalah task yang dikerjakan oleh manusia dengan bantuan sistem atau aplikasi. Ini adalah tipe task yang paling umum ditemukan dalam diagram BPMN — karena sebagian besar proses bisnis masih melibatkan manusia yang berinteraksi dengan sistem.
Simbol: Ikon siluet orang di sudut kiri atas persegi panjang sudut membulat
Definisi yang Tepat
User Task menjawab pertanyaan: "Siapa yang harus mengerjakan ini, dan melalui sistem apa?"
Kata kunci untuk mengenali User Task:
- Seorang karyawan mengisi formulir di aplikasi
- Seorang manajer menyetujui permintaan di sistem workflow
- Seorang analis mereview data di dashboard
- Seorang petugas memverifikasi dokumen di aplikasi
Perbedaan inti dengan tipe task lain:
- Bukan Manual Task — karena ada sistem yang membantu (formulir online, workflow engine, aplikasi)
- Bukan Service Task — karena ada manusia yang terlibat, bukan otomasi penuh
Komponen Konfigurasi User Task
Dalam implementasi di BPMS (Camunda, Flowable, Activiti), User Task memiliki properti berikut:
Assignee — Siapa yang Mengerjakan
Mendefinisikan siapa yang mendapat task ini. Ada beberapa cara:
| Cara Assign | Contoh | Kapan Digunakan |
|---|---|---|
| User langsung | wisnu.manupraba | Task selalu dikerjakan orang tertentu |
| Group/Role | supervisor-kredit, tim-legal | Task bisa dikerjakan siapa saja dalam grup |
| Expression dinamis | ${pemohon} | Ditentukan saat runtime berdasarkan data proses |
| Kosong (unassigned) | — | Task masuk ke pool, siapa yang ambil yang mengerjakan |
Candidate Users & Candidate Groups
Berbeda dari Assignee tunggal, candidate berarti task bisa diklaim oleh siapa saja dari daftar atau grup tersebut — seperti antrian tiket di helpdesk.
Due Date — Batas Waktu
Menentukan kapan task harus selesai. Bisa berupa:
- Tanggal tetap:
2025-12-31 - Ekspresi dinamis:
${now() + duration('P2D')}(2 hari dari sekarang) - Berguna untuk integrasi dengan fitur reminder dan eskalasi otomatis
Priority — Prioritas
Nilai numerik (0–100) yang menentukan urutan tampil di daftar task pengguna. Semakin tinggi angka, semakin prioritas.
Form — Antarmuka Pengguna
User Task biasanya terhubung dengan form yang diisi pengguna. Ada dua pendekatan:
| Pendekatan | Keterangan |
|---|---|
| Embedded Form | Form didefinisikan langsung di BPMS |
| External Form | Form berada di aplikasi eksternal, BPMS hanya menyimpan data |
| Form Key | Referensi ke form di sistem lain |
Pola Penggunaan yang Umum
Pola 1: Review dan Persetujuan
Pola paling klasik. Seorang atasan atau reviewer melihat informasi dan membuat keputusan.
[Ajukan Permintaan] → ◇ → [Review oleh Supervisor] → ◇ Disetujui?
↑ User Task ├─ Ya → ...
Assignee: supervisor-dept └─ Tidak → ...
Properti khas:
- Form menampilkan data yang sudah diisi di step sebelumnya (read-only)
- Hanya field keputusan yang aktif (Setuju/Tolak + komentar)
- Due date biasanya 1–2 hari kerja
Pola 2: Input Data
Pengguna mengisi informasi baru yang belum ada sebelumnya.
[Start] → [Input Data Pelanggan] → [Validasi Otomatis] → ...
↑ User Task
Assignee: petugas-pendaftaran
Form: Formulir Data Pelanggan (semua field aktif)
Pola 3: Klaim dari Antrian
Tidak ada assignee tetap — task diletakkan di "antrian" dan petugas yang tersedia mengambilnya.
[Masuk Antrian Helpdesk] → [Tangani Tiket]
↑ User Task
Candidate Group: tim-support
Assignee: dikosongkan (diisi saat diklaim)
Pola 4: Multi-Level Approval
User Task digunakan berantai untuk approval berjenjang.
[User Task: Staff mengisi] → [User Task: Supervisor approve]
→ [User Task: Manager approve] → [User Task: Direktur approve]
Contoh Konteks Indonesia
Perbankan: Persetujuan Kredit
Lane: Analis Kredit
[User Task: Analisis Kelayakan Kredit]
- Assignee: ${analisKredit}
- Due Date: P3D (3 hari)
- Form: Form analisis 5C (Character, Capacity, Capital, Collateral, Condition)
- Outcome variable: hasilAnalisis (Layak / Tidak Layak / Perlu Review)
Pemerintahan: Validasi Berkas Perizinan
Lane: Petugas Front Office
[User Task: Verifikasi Kelengkapan Berkas]
- Candidate Group: petugas-fo
- Due Date: P1D (1 hari kerja)
- Form: Checklist berkas berdasarkan jenis perizinan
- Outcome: berkasLengkap (true/false) + catatanKekurangan
Manufaktur: Quality Control
Lane: QC Inspector
[User Task: Inspeksi Produk]
- Candidate Group: tim-qc
- Form: Form checklist inspeksi dengan foto
- Outcome: hasilInspeksi (Lulus / Gagal / Perlu Perbaikan)
- Priority: ${if(urgentOrder, 80, 50)}
Kesalahan Umum
1. Menggunakan User Task untuk Proses Otomatis
Jika tidak ada manusia yang terlibat, gunakan Service Task, bukan User Task. User Task yang tidak pernah ditampilkan ke pengguna adalah desain yang salah.
2. User Task Tanpa Form
User Task tanpa form membuat pelaksana tidak tahu apa yang harus dikerjakan. Selalu definisikan form atau minimal task description.
3. Assignee Nama Orang, Bukan Role
Jangan tulis assignee: budi.santoso untuk proses yang digunakan jangka panjang. Gunakan role/group agar proses tetap berjalan saat orang berganti.
4. Tidak Ada Due Date
User Task tanpa due date tidak bisa dipantau SLA-nya dan tidak memicu eskalasi otomatis. Selalu definisikan batas waktu.
User Task vs. Receive Task
Keduanya "menunggu input manusia" — tapi berbeda:
| Aspek | User Task | Receive Task |
|---|---|---|
| Pengguna berinteraksi | Langsung di BPMS/form | Tidak harus — bisa via sistem lain |
| Mekanisme selesai | Pengguna submit form | Pesan diterima dari sistem |
| Contoh | "Approve di portal" | "Terima email konfirmasi dari vendor" |
Selanjutnya: Manual Task →