Pelajari cara membangun aplikasi web persetujuan internal tanpa kode kustom: peta langkah, desain formulir, pengaturan peran, otomatisasi routing, tambahkan jejak audit, dan luncurkan dengan aman.
Aplikasi web persetujuan internal adalah sistem untuk memindahkan sebuah permintaan dari “seseorang butuh sesuatu” menjadi “keputusan dibuat—dan kita bisa membuktikannya nanti.” Yang terbaik melakukan beberapa pekerjaan inti secara konsisten, meskipun proses spesifik berbeda antar tim.
Kebanyakan alur persetujuan internal mencakup:
Pola yang sama muncul di banyak proses:
Alat tanpa kode sering cocok karena memungkinkan tim meluncurkan cepat, iterasi mingguan, dan menjaga kepemilikan di tangan orang yang menjalankan proses. Anda dapat membangun formulir, aturan routing, notifikasi, dan dasbor tanpa menunggu antrean pengembangan tradisional.
Libatkan engineer jika ada kasus pinggiran seperti routing kondisional yang sangat kompleks (banyak cabang), kebutuhan residensi data ketat, kendala SSO khusus, atau integrasi kompleks yang butuh middleware dan penanganan error yang kuat. Di banyak organisasi, no-code masih bisa menangani UI sementara engineering mengisi gap.
Jika Anda ingin sesuatu yang lebih mendekati “kustom” tanpa komitmen build penuh, platform vibe-coding seperti Koder.ai bisa menjadi solusi perantara: Anda mendeskripsikan alur lewat chat, dan platform menghasilkan app (umumnya React di frontend, Go + PostgreSQL di backend) dengan opsi ekspor source code, deployment/hosting, snapshot, dan rollback—berguna ketika proses persetujuan Anda mulai sederhana tapi perlu dikokohkan seiring waktu.
Sebelum membuka builder, pilih satu alur persetujuan internal untuk ditangani pertama. Tujuannya membuktikan nilai dengan cepat, lalu gunakan pola yang sama untuk alur persetujuan lain.
Kandidat awal yang baik biasanya memiliki:
Contoh: permintaan pembelian di bawah ambang, persetujuan cuti, review konten/legal untuk template tertentu, atau onboarding vendor dasar.
Jelaskan dengan spesifik apa arti “pengajuan” dalam proses formulir-ke-persetujuan Anda:
Jika pemberi persetujuan rutin menanyakan detail yang sama, jadikan itu wajib di v1.
Tuliskan setiap orang (atau peran) yang terlibat dan di mana keputusan terjadi: reviewer, approver, keuangan, legal, dan setiap delegate untuk cuti. Catat juga keputusan “edge” seperti “kembalikan untuk edit” atau “minta info tambahan”, karena itu memicu sebagian besar tindak lanjut.
Pilih 2–3 hasil yang dapat diukur:
Dengan start, finish, dan metrik keberhasilan yang didefinisikan, pilihan otomatisasi alur kerja menjadi lebih jelas.
Sebelum menyentuh builder, petakan jalur persetujuan di satu halaman. Ini mencegah workflow yang “hampir bekerja”—di mana permintaan tersangkut, diarahkan ke orang yang salah, atau berputar tanpa akhir jelas.
Mulai dengan kerangka yang mudah dibaca keras:
Submit → Review → Approve/Reject → Close
Untuk tiap langkah, beri nama siapa yang melakukannya (peran atau tim), apa yang perlu mereka lihat, dan apa yang bisa mereka putuskan. Jika Anda tidak bisa mendeskripsikan satu langkah dalam satu kalimat, biasanya ada beberapa aksi yang harus dipisah.
Jelas apakah review terjadi:
Flow paralel perlu aturan untuk “selesai”: semua harus setuju, salah satu cukup, atau mayoritas. Pilih sekarang—mengubahnya nanti sering memaksa rebuild.
Penolakan bisa berarti:
Pilih yang benar untuk kepatuhan dan pelaporan. “Edit dan kirim ulang” umum, tetapi tetap rekam keputusan asli.
Petakan jalur non-happy upfront:
Jika Anda menangkap ini di atas kertas dulu, pembangunan menjadi konfigurasi bukan tebak-tebakan.
Aplikasi persetujuan no-code bekerja terbaik ketika model data sederhana, konsisten, dan mudah dilaporkan nanti. Sebelum membangun layar, putuskan record apa yang Anda simpan dan bagaimana relasinya.
Untuk sebagian besar alur persetujuan internal, Anda bisa menutupi 90% kebutuhan dengan beberapa tabel (atau koleksi):
Jaga Request sebagai sumber kebenaran tunggal. Semua lain mengacu padanya.
Tentukan field yang harus ada untuk routing dan pengambilan keputusan. Field wajib tipikal:
Semua lainnya bisa dimulai opsional. Anda selalu bisa menambahkan nanti setelah melihat apa yang benar-benar diminta approver.
Putuskan sejak awal dokumen apa yang harus disimpan (penawaran, kontrak, screenshot) dan berapa lama.
Gunakan set status kecil dan jelas agar semua menginterpretasikan progress sama:
Draft → Submitted → In Review → Approved / Rejected → Completed
Hindari membuat terlalu banyak status kustom awal. Field status konsisten membuat filter, pengingat, dan pelaporan jauh lebih mudah.
Aplikasi persetujuan yang baik menang atau kalah dari sisi usability. Jika orang enggan mengajukan permintaan atau tidak tahu apa yang terjadi selanjutnya, mereka akan kembali ke email.
Sebagian besar alur dapat dicakup dengan sedikit halaman:
Jaga navigasi sederhana: “New request”, “My requests”, “Needs my approval”, dan “Settings” (untuk admin).
Mulai dengan field wajib minimum, lalu gunakan field kondisional untuk menjaga formulir tetap pendek. Misalnya: hanya tampilkan “Detail vendor” jika “Tipe pembelian = Vendor baru”, atau tampilkan “Alasan pengecualian” hanya jika sebuah kotak kebijakan tidak dicentang.
Inilah kelebihan alat no-code: Anda bisa show/hide bagian berdasarkan dropdown, jumlah, atau departemen—tanpa membuat formulir terpisah.
Pada setiap record permintaan, tampilkan:
Indikator progres sederhana plus baris “Menunggu: <nama/peran>” menghilangkan sebagian besar pesan “Ada kabar?”
Tambahkan teks bantu singkat dan contoh di bawah field yang rumit (“Lampirkan penawaran yang ditandatangani (PDF)”, “Gunakan cost center seperti 4102-Operations”). Gunakan validasi untuk mencegah pengerjaan ulang yang bisa dihindari: lampiran wajib untuk tipe request tertentu, rentang jumlah yang diperbolehkan, dan pesan error yang jelas.
Tujuannya lebih sedikit pertanyaan klarifikasi, keputusan lebih cepat, dan record yang lebih rapi untuk pelaporan.
Jika aplikasi persetujuan adalah sebuah gedung, peran dan izin adalah kunci dan gembok. Aturan routing adalah tanda lorong yang memastikan setiap request mendarat di meja yang tepat—tanpa dikejar manual.
Mulai dengan set kecil peran yang akan Anda gunakan ulang di banyak workflow:
Tulis apa yang tiap peran bisa lakukan dalam bahasa sederhana sebelum menyentuh builder.
Persetujuan rusak ketika semua orang bisa melihat atau mengedit semuanya. Definisikan izin di tiap tahap:
Default praktis: setelah submit, kunci field kunci (jumlah, vendor, tanggal), dan izinkan edit hanya lewat aksi “send back”.
Mengunci nama tidak skalabel. Lebih baik aturan routing seperti:
Ini menjaga workflow akurat meski orang bergabung, keluar, atau pindah tim.
Persetujuan sering macet karena cuti dan beban inbox. Tambahkan:
Aturan ini melindungi throughput tanpa mengorbankan kontrol.
Otomatisasi mengubah formulir sederhana menjadi alur persetujuan internal yang dapat diandalkan. Tujuannya sederhana: ketika request berubah status, orang berikutnya harus segera menerima tugas yang tepat—tanpa pengejaran manual atau copy-paste link.
Atur aturan seperti: Draft → Submitted → Manager Review → Finance Review → Approved/Rejected. Setiap perubahan status harus otomatis:
Jaga aturan routing mudah dibaca. Jika perlu pengecualian (mis. “Jika jumlah > $5,000, tambahkan persetujuan CFO”), definisikan sebagai kondisi jelas terkait field data.
Minimal, kirim dua jenis pesan:
Gunakan kanal yang sudah dicek perusahaan—email plus Slack/Teams jika tersedia. Jaga pesan singkat dan konsisten agar tidak terasa spam.
Persetujuan macet ketika tidak ada yang bertanggung jawab terhadap waktu. Tambahkan:
Buat eskalasi dapat diprediksi (dan terlihat) agar approver percaya sistem.
Otomatisasi juga harus menghentikan mode kegagalan umum:
Pengaman ini mengurangi pengerjaan ulang dan memastikan setiap request mengikuti jalur yang sama.
Aplikasi persetujuan hanya bekerja jika semua orang bisa melihat apa yang menunggu, apa yang macet, dan apa yang sudah selesai—tanpa bertanya. Dasbor mengubah “Di mana request ini?” menjadi jawaban swalayan.
Buat satu tempat yang bisa dipercaya reviewer setiap hari. Tampilan inbox Anda harus mencakup:
Jaga setiap baris bisa diambil tindakan: pemohon, departemen, jumlah/tipe, tanggal diajukan, tanggal jatuh tempo, dan satu-klik approve/reject.
Sebagian besar tindak lanjut dapat diprediksi: “Tunjukkan semua request tertunda dari Sales bulan ini,” atau “Cari PO yang saya ajukan Selasa lalu.” Buat filter untuk:
Jika alat Anda mendukung, tambahkan saved views seperti “Pending tim saya” atau “Antrian finance.”
Dasbor tidak perlu menunjukkan setiap field untuk berguna. Fokus pada metrik operasional:
Gunakan hitungan dan durasi teragregasi agar pemimpin bisa melihat langkah yang lambat tanpa melihat konten sensitif.
Walaupun belum pakai tool BI, permudah pelaporan:
Ini mengurangi permintaan ad-hoc dan membantu membuktikan workflow membaik dari waktu ke waktu.
Jika persetujuan berdampak pada pengeluaran, risiko, atau komitmen pelanggan, Anda butuh bukti—bukan hanya “Approved” sebagai status akhir. Tata kelola paling mudah (dan murah) ditambahkan saat merancang workflow, bukan setelah orang mulai mengandalkannya.
Aplikasi Anda harus merekam riwayat yang jelas dari siapa melakukan apa, dan kapan. Minimal, log:
Buat view log audit bisa dilihat oleh admin dan reviewer, tapi jangan buka untuk semua orang secara default.
Persetujuan tanpa konteks membingungkan di kemudian hari. Tambahkan komentar opsional saat approval, dan field alasan penolakan yang wajib. Ini mencegah outcome “Rejected” yang samar dan mempercepat pengiriman ulang karena pemohon tahu apa yang perlu diperbaiki.
Polanya praktis:
Gunakan pendekatan least-privilege sehingga orang hanya melihat yang mereka perlukan:
Jika alat Anda mendukung row-level permissions, gunakan itu. Jika tidak, pisahkan workflow sensitif ke app yang berbeda.
Putuskan lebih awal berapa lama menyimpan record (mis. 1–7 tahun tergantung kebijakan), bagaimana penghapusan bekerja (soft-delete sering lebih aman), dan siapa yang meninjau akses tiap kuartal. Dokumentasikan aturan ini di halaman internal singkat dan tautkan dari app (mis. /policies/approvals).
Alur persetujuan jarang hidup sendiri. Cara tercepat mendapat adopsi adalah menghubungkan app Anda ke sistem yang sudah dipakai: login, data HR, catatan keuangan, antrian ticketing, dan messaging.
Jika perusahaan Anda sudah memakai Google Workspace, Microsoft Entra ID (Azure AD), Okta, atau serupa, aktifkan SSO agar karyawan tidak perlu kata sandi baru.
Di luar kenyamanan, SSO membantu kontrol akses: Anda bisa memetakan grup (mis. “Finance”, “People Ops”, “IT”) ke peran di app persetujuan, mengurangi admin manual dan risiko orang salah melihat request sensitif.
Sebagian besar request butuh data referensi:
Gunakan konektor native jika tersedia supaya formulir bisa autofill dan aturan routing bisa membuat keputusan lebih tepat (mis. routing berdasarkan departemen atau ambang pengeluaran).
Jika tool Anda tidak punya integrasi built-in, Anda tetap bisa menghubungkan tanpa membangun aplikasi kustom penuh. Banyak platform mengizinkan:
Jaga payload sederhana: request ID, pemohon, keputusan, timestamp, dan field kunci yang dibutuhkan sistem target.
Integrasi bisa gagal—token kadaluarsa, API rate-limit, field berubah. Bangun:
Ini mencegah hasil “disetujui tapi tidak pernah dieksekusi” yang cepat merusak kepercayaan.
Menguji workflow persetujuan internal bukan hanya “tombolnya jalan?” Tapi apakah orang nyata bisa memindahkan request nyata dari awal sampai akhir tanpa kebingungan atau solusi pengganti.
Buat beberapa request realistis dan jalankan seluruh proses:
Amati bottleneck: field yang tidak jelas, konteks yang hilang untuk approver, dan langkah yang memaksa orang kembali ke email/chat.
Mulai dengan grup kecil—satu tim atau satu tipe request—dan jalankan pilot cukup lama untuk menemui edge case (biasanya 2–4 minggu). Jadwalkan cek-in singkat mingguan dan kumpulkan feedback di satu tempat (form atau doc bersama). Prioritaskan perbaikan yang mengurangi bolak-balik: kejelasan field, aturan routing, dan timing notifikasi.
Jaga dokumentasi pendek dan praktis:
Publikasikan di tempat yang sudah dikunjungi pengguna (mis. halaman internal seperti /help/approvals).
Perluas satu grup pada satu waktu. Gunakan metrik awal—waktu siklus, alasan penolakan, waktu di tiap langkah—untuk menyempurnakan aturan dan field formulir. Iterasi kecil (mingguan atau dua mingguan) menjaga kepercayaan tinggi dan mencegah workflow menjadi solusi pengganti.
Walau memakai alat no-code, alur persetujuan bisa berantakan tanpa beberapa guardrail. Ini mode kegagalan yang sering memperlambat tim—dan cara praktis mencegahnya.
Insting umum adalah menangkap semua detail “untuk berjaga-jaga.” Hasilnya formulir tidak ada yang mau isi dan jalur persetujuan sulit dipelihara.
Mulai sederhana: field minimum untuk membuat keputusan, dan jalur persetujuan sesingkat mungkin yang masih memenuhi kebijakan. Luncurkan, amati titik macet, lalu tambahkan hanya yang benar-benar diperlukan.
Aturan routing, daftar approver, dan akses berbasis peran butuh pemilik yang jelas. Jika tidak ada yang mengurus workflow, pengecualian menumpuk, akses kadaluarsa, dan persetujuan terblokir saat seseorang mengubah peran.
Tunjuk pemilik proses bernama (dan backup). Taruh perubahan aturan di proses perubahan ringan (bahkan checklist singkat), dan jadwalkan review bulanan grup approver dan izin.
Jika pemohon tidak bisa melihat status atau approver berikutnya, mereka akan mengejar orang secara manual—mengalahkan tujuan otomatisasi.
Sertakan halaman status dengan: tahap saat ini, waktu terakhir diperbarui, approver berikutnya (atau tim), dan SLA estimasi. Tambahkan dasbor sederhana agar manajer bisa melihat titik macet.
Workflow nyata punya edge case: permintaan mendesak, approver cuti, atau pengecualian kebijakan.
Bangun penanganan pengecualian yang aman: flag “urgent” yang memicu jalur cepat terdefinisi, aturan delegasi, dan override terkontrol yang memerlukan alasan dan direkam di jejak audit.
Jika Anda mengantisipasi perubahan sering pada logika workflow (ambang baru, approver tambahan, tipe request baru), pertimbangkan pendekatan build yang mudah diiterasi tanpa kehilangan tata kelola. Misalnya, tim menggunakan Koder.ai untuk menghasilkan dan mengembangkan app workflow internal dengan cepat dari spesifikasi berbasis chat, sambil tetap menjaga opsi ekspor source code dan penegakan kontrol lebih ketat saat proses matang.
Mulailah dengan satu alur kerja yang high pain, low complexity:
Contoh: permintaan pembelian di bawah ambang tertentu, persetujuan cuti, atau alur permintaan akses dasar. Buktikan nilai dulu, lalu ulangi pola yang sama untuk alur lain.
Tangkap data minimum yang diperlukan untuk mengarahkan dan memutuskan. Field wajib umum:
Jika pemberi persetujuan sering meminta detail tertentu (mis. nama vendor atau penawaran), jadikan itu wajib di versi pertama.
Sebagian besar aplikasi hanya butuh beberapa layar inti:
Sederhanakan navigasi agar pengguna mudah menemukan “New request”, “My requests”, dan “Needs my approval”.
Gunakan set status kecil dan standar agar filter, pengingat, dan laporan mudah:
Jika perlu detail lebih, tampilkan langkah saat ini (mis. “Manager review”) sebagai field terpisah daripada menambah banyak status kustom.
Pilih berdasarkan apakah urutan penting atau kecepatan lebih penting:
Untuk review paralel, tetapkan aturan penyelesaian: semua harus setuju, siapa saja, atau mayoritas—mengubah aturan ini nanti sering memaksa pengerjaan ulang.
Putuskan apa arti “ditolak” bagi proses Anda:
Bahkan dengan edit/kirim ulang, simpan catatan audit keputusan asli dan alasan penolakan.
Definisikan peran dan izin per tahap:
Guardrail praktis: setelah dikirim, kunci field kunci (jumlah/vendor/tanggal) dan hanya izinkan perubahan lewat aksi “send back”.
Gunakan aturan berbasis organisasi daripada mengunci nama orang:
Ini membuat routing tetap akurat saat orang pindah peran atau tim.
Tambahkan aturan pencegah macet sejak awal:
Buat perilaku eskalasi terlihat dan konsisten agar sistem terasa dapat diprediksi.
Catat cukup detail untuk menjawab “siapa melakukan apa, kapan, dan mengapa”:
Tetapkan ekspektasi retensi dini (mis. 12–24 bulan untuk permintaan operasional, lebih lama untuk keuangan/legal) dan gunakan prinsip least-privilege agar pengguna hanya melihat yang perlu mereka lihat.
