Kali ini saya akan membahas sesuatu yg biasanya dianggap sederhana tapi dalam penggunaan end user sering menjadi proses rumit jika perancangan structur data tidak tepat.

Dalam pengembangan aplikasi bisnis, kita sering menemukan proses di mana sebuah data tidak boleh langsung aktif setelah dibuat atau diubah oleh satu pengguna. Data tersebut harus melalui proses pemeriksaan dan persetujuan beberapa tim/pihak/user terlebih dahulu sebelum data tersebut digunakan.

Salah satu pola yang umum digunakan adalah Maker-Checker-Signer. Secara sederhana ke-3 role user tersebut memiliki tugas masing-masing sebagai berikut:

Maker bertugas membuat atau mengajukan perubahan data.
Checker bertugas memeriksa data yang diajukan Maker.
Signer memberikan persetujuan akhir sebelum data resmi digunakan.

Flow-nya terlihat sederhana:

Maker
  ↓
Checker
  ↓
Signer
  ↓
Approved

Namun, dari sisi database, implementasinya tidak sesederhana menambahkan kolom maker_id, checker_id, dan signer_id pada data pengajuan.

Jika struktur database dirancang terlalu sederhana sejak awal, masalah biasanya mulai muncul ketika aplikasi membutuhkan fitur reject, revisi, resubmit, audit trail, multiple approval, atau perubahan workflow.

Pada artikel ini kita akan membahas bagaimana merancang database untuk approval Maker–Checker–Signer yang lebih rapi, aman, dan scalable.

Contoh Kasus: Approval Master Product

Agar lebih mudah dipahami, kita gunakan contoh Master Product.

Misalnya saat ini terdapat produk:

Kode Produk : PRD001
Nama        : Product A
Harga       : Rp100.000
Status      : ACTIVE

Kemudian Maker ingin mengubah harga menjadi:

Rp100.000 → Rp120.000

Perubahan tersebut tidak boleh langsung mengubah data Master Product.

Flow bisnisnya adalah:

Maker mengajukan perubahan
        ↓
Checker memeriksa
        ↓
Signer menyetujui
        ↓
Master Product diperbarui

Di sinilah desain database menjadi penting.

1. Kesalahan Umum: Menyimpan Semua Approval di Tabel Master

Pendekatan paling sederhana biasanya adalah menambahkan informasi approval langsung ke tabel master_product. Contohnya saya akan membuat dalam ini yaitu pengajuan/approval data master produk sebagai berikut:

CREATE TABLE master_product (
    product_id BIGINT PRIMARY KEY,
    product_name VARCHAR(150),
    price DECIMAL(15,2),

    maker_id BIGINT,
    maker_note TEXT,
    maker_at DATETIME,

    checker_id BIGINT,
    checker_note TEXT,
    checker_at DATETIME,

    signer_id BIGINT,
    signer_note TEXT,
    signer_at DATETIME
);

Untuk aplikasi yang sangat sederhana, struktur seperti ini memang dapat bekerja. Masalahnya muncul ketika workflow berkembang dan setiap aksi yang dilakukan user approval tidak terekam utuh atau terhapus.

Bayangkan proses berikut:

Maker Submit
      ↓
Checker Reject
      ↓
Maker memperbaiki
      ↓
Checker Approve
      ↓
Signer Reject
      ↓
Maker memperbaiki lagi
      ↓
Checker Approve
      ↓
Signer Approve

Pertanyaannya:

Di mana kita menyimpan note Checker yang pertama?

Jika checker_note di-update, informasi sebelumnya akan hilang. Kita juga akan kesulitan menjawab pertanyaan seperti:

Siapa yang pertama kali melakukan reject?
Apa alasan Checker mengembalikan data?
Berapa kali Maker melakukan revisi?
Siapa yang melakukan approval sebelumnya?

Karena itu, informasi approval sebaiknya tidak menjadi bagian langsung dari Master Product.

2. Pisahkan Master Data dan Approval Process

Jadi ibaratkan, ada sebuah meja makan Pelanggan dimana harus disajikan makanan dan minuman yang dipesan. Lalu akan dibuatkan menu masakan sesuai pesanan Pelanggan. Maka, manajer chef, koki di dapur, dan pelayan harus menyiapkan sebelum masuk meja makan, Ketiganya harus saling setuju dari mulai rasa di nilai Manajer Chef, aroma dan cara penyajian sudah dipersiapkan Koki dan semuanya dilakukan di “DAPUR” yg kemudian disajikan oleh pelayan ke meja pelanggan,

Inti dari analogi terebut adalah ketiga petugas restoran tersebut melakukan semuanya di DAPUR, tidak memasak atau menyiapkan makanan di meja makan Pelanggan. Prinsip yang saya rekomendasikan adalah:

Master table hanya menyimpan data yang sudah resmi atau approved.

Sedangkan perubahan yang belum mendapatkan approval disimpan secara terpisah. Arsitekturnya menjadi:

Dengan pendekatan ini kita mempunyai tiga tanggung jawab berbeda:

master_product
→ data resmi yang digunakan aplikasi

product_change_request
→ perubahan yang sedang diajukan

product_approval_history
→ riwayat aktivitas approval

Pemisahan tanggung jawab ini membuat struktur database jauh lebih mudah dikembangkan.

3. Master Product Hanya Menyimpan Data Approved

Tabel pertama adalah tabel bisnis utama yang digunakan aplikasi end user atau data akhir yang sanagat penting yang akan dilakukan penambahan atau perubahan. Biasanya data utama yang paling sering digunakan untuk transaction atau sejenisnya.

Dibawah ini saya akan membuat contoh case untuk sebuah aplikasi managment inventori yang penambahan atau pengurangan atau perubahan data, semuanya harus melalui persetujuan 3 jabatan yaitu maker, checker dan signer.

Contohnya:

CREATE TABLE master_product (
    product_id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,

    product_code VARCHAR(50) NOT NULL,
    product_name VARCHAR(150) NOT NULL,
    description TEXT NULL,

    price DECIMAL(15,2) NOT NULL DEFAULT 0,
    status VARCHAR(20) NOT NULL DEFAULT 'ACTIVE',

    version INT UNSIGNED NOT NULL DEFAULT 1,

    created_at DATETIME NOT NULL,
    created_by BIGINT UNSIGNED NOT NULL,

    updated_at DATETIME NULL,
    updated_by BIGINT UNSIGNED NULL,

    PRIMARY KEY (product_id),

    UNIQUE KEY uk_master_product_code (product_code),
    KEY idx_master_product_status (status)
);

Misalnya data aktif saat ini:

product_id   : 100
product_code : PRD001
product_name : Product A
price        : 100000
status       : ACTIVE
version      : 3

Inilah data yang boleh digunakan oleh aplikasi. Ketika Maker mengajukan harga Rp120.000, jangan langsung mengubah price menjadi 120000.

Data Master Product tetap atau tidak berubah misalnya: price = 100000 sampai seluruh proses approval selesai.

4. Simpan Perubahan Maker Sebagai Change Request

Selanjutnya kita membutuhkan tempat untuk menyimpan perubahan yang diajukan Maker.

Misalnya:

CREATE TABLE product_change_request (
    request_id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,

    request_no VARCHAR(50) NOT NULL,
    product_id BIGINT UNSIGNED NULL,

    request_type VARCHAR(20) NOT NULL,

    before_data JSON NULL,
    proposed_data JSON NOT NULL,

    base_version INT UNSIGNED NULL,

    status VARCHAR(30) NOT NULL,
    current_step VARCHAR(20) NOT NULL,

    submitted_by BIGINT UNSIGNED NOT NULL,
    submitted_at DATETIME NOT NULL,

    completed_at DATETIME NULL,

    created_at DATETIME NOT NULL,
    updated_at DATETIME NULL,

    PRIMARY KEY (request_id),

    UNIQUE KEY uk_product_request_no (request_no),

    KEY idx_product_request_product (product_id),
    KEY idx_product_request_status (status),

    CONSTRAINT fk_product_request_product
        FOREIGN KEY (product_id)
        REFERENCES master_product(product_id)
);

Misalnya Maker mengubah:

Nama  : Product A → Product A Premium
Harga : 100000 → 120000

Kita dapat menyimpan snapshot data sebelumnya:

{
    "product_name": "Product A",
    "price": 100000,
    "status": "ACTIVE"
}

pada:

before_data

Sedangkan perubahan yang diajukan disimpan pada:

proposed_data

seperti:

{
    "product_name": "Product A Premium",
    "price": 120000,
    "status": "ACTIVE"
}

Dengan demikian kita memiliki dua versi yang jelas:

CURRENT DATA                    PROPOSED DATA

Product A                       Product A Premium
Rp100.000          →            Rp120.000
ACTIVE                          ACTIVE

Checker dan Signer juga akan jauh lebih mudah melihat apa yang sebenarnya berubah.

5. Gunakan Request Type

Approval tidak selalu berkaitan dengan UPDATE, bisa juga Maker mungkin ingin melakukan action:

CREATE
UPDATE
DELETE
ACTIVATE
DEACTIVATE

Karena itu kita bisa menyimpan jenis permintaan pada:

request_type

Contohnya:

request_id   : 10001
request_no   : PRQ-20260907-0001
product_id   : 100
request_type : UPDATE

Pendekatan ini memungkinkan satu mekanisme approval digunakan untuk berbagai jenis perubahan Master Product.

6. Pisahkan Current Status dan Current Step

Saya juga menyarankan membedakan antara status request dan siapa yang sedang harus melakukan tindakan.

Contohnya:

status       : IN_PROGRESS
current_step : CHECKER

atau menggunakan business state yang lebih eksplisit:

WAITING_CHECKER
WAITING_SIGNER
APPROVED
RETURNED
REJECTED
CANCELLED

Contoh flow:

DRAFT
  │
  │ Maker Submit
  ▼
WAITING_CHECKER
  │
  │ Checker Approve
  ▼
WAITING_SIGNER
  │
  │ Signer Approve
  ▼
APPROVED

Setelah status menjadi APPROVED, barulah proposed_data diterapkan ke master_product.

7. Jangan Hanya Menggunakan Status REJECTED

Ada satu detail yang sering terlewat. Tidak semua penolakan berarti proses selesai. Misalnya Checker mengatakan: Harga yang dimasukkan salah, silakan diperbaiki. Dalam kasus tersebut sebenarnya request dikembalikan, bukan ditolak permanen.

Karena itu sebaiknya bedakan:

RETURNED

dan:

REJECTED

RETURNED berarti:

Checker
   ↓
RETURN
   ↓
Maker
   ↓
REVISE
   ↓
RESUBMIT
   ↓
Checker

Sedangkan REJECTED berarti request benar-benar selesai dan tidak dilanjutkan.

Perbedaan kecil ini sangat membantu ketika sistem mulai memiliki workflow yang kompleks.

8. Semua Aktivitas Masuk ke Approval History

Sekarang bagian yang sangat penting yaitu audit trail. Tujuannya sudah pasti agar semua perubahan tercatat secara detail mulai dari siapa yang melakukan action, kapan waktu penambahan/perubahan, dan biasanya ada detail perangkat atau IP yang dicatat sebagai bukti tambahan.

Buat tabel terpisah:

CREATE TABLE product_approval_history (
    approval_history_id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,

    request_id BIGINT UNSIGNED NOT NULL,

    step VARCHAR(20) NOT NULL,
    actor_id BIGINT UNSIGNED NOT NULL,

    action VARCHAR(20) NOT NULL,
    note TEXT NULL,

    action_at DATETIME NOT NULL,

    PRIMARY KEY (approval_history_id),

    KEY idx_product_approval_request (
        request_id,
        action_at
    ),

    CONSTRAINT fk_product_approval_request
        FOREIGN KEY (request_id)
        REFERENCES product_change_request(request_id)
);

Setiap aktivitas menghasilkan record baru.

Misalnya:

Step	Actor	Action	Note
MAKER	101	SUBMIT	Mohon diperiksa
CHECKER	201	RETURN	Harga tidak sesuai
MAKER	101	RESUBMIT	Harga sudah diperbaiki
CHECKER	201	APPROVE	Data sudah sesuai
SIGNER	301	APPROVE	Approved

Sekarang kita mempunyai timeline:

08:30 Maker
      CREATE

08:45 Maker
      SUBMIT
      "Mohon diperiksa"

09:15 Checker
      RETURN
      "Harga tidak sesuai"

10:00 Maker
      RESUBMIT
      "Harga sudah diperbaiki"

10:20 Checker
      APPROVE
      "Data sudah sesuai"

10:45 Signer
      APPROVE
      "Approved"

Tidak ada history yang ditimpa.

9. Approval History Sebaiknya Append-Only

Untuk data audit, prinsip yang baik adalah:

Insert aktivitas baru, jangan mengubah aktivitas lama.

Misalnya Checker sebelumnya memberikan:

RETURN
"Harga tidak sesuai"

jangan kemudian diubah menjadi:

APPROVE
"Sudah sesuai"

Sebaliknya buat record baru.

09:15 CHECKER → RETURN
10:20 CHECKER → APPROVE

Dengan begitu database dapat menceritakan apa yang benar-benar terjadi, bukan hanya kondisi terakhir. Untuk sistem dengan kebutuhan audit yang ketat, akses UPDATE dan DELETE terhadap history bahkan dapat dibatasi.

10. Maker Juga Bagian dari History

Kadang approval history hanya mencatat Checker dan Signer. Menurut saya Maker juga perlu dicatat. Karena Maker melakukan aktivitas penting seperti:

CREATE
SUBMIT
REVISE
RESUBMIT
CANCEL

Maka audit trail lengkap bisa menjadi:

MAKER   → CREATE
MAKER   → SUBMIT
CHECKER → RETURN
MAKER   → REVISE
MAKER   → RESUBMIT
CHECKER → APPROVE
SIGNER  → APPROVE

Dengan begitu kita mempunyai perjalanan request secara utuh.

11. Pisahkan Role dan Action

Hindari membuat action seperti:

MAKER_SUBMIT
CHECKER_APPROVE
CHECKER_REJECT
SIGNER_APPROVE
SIGNER_REJECT

Lebih baik pisahkan:

step

dengan:

action

Contohnya:

step   : CHECKER
action : APPROVE

atau:

step   : CHECKER
action : RETURN

Karena keduanya mempunyai arti berbeda:

step menjawab tahapan/role mana yang melakukan proses
action menjawab apa yang dilakukan

Struktur ini lebih fleksibel ketika workflow berkembang.

12. Terapkan Segregation of Duties

Maker–Checker–Signer bukan sekadar tiga nama role. Salah satu tujuan pola ini adalah memisahkan tanggung jawab.

Idealnya:

Maker   : User A
Checker : User B
Signer  : User C

Hindari kondisi:

User A membuat request
↓
User A memeriksa request sendiri
↓
User A approve request sendiri

Backend perlu memastikan Maker tidak dapat melakukan approval terhadap request miliknya sendiri apabila business rule memang mengharuskan pemisahan tugas.

Misalnya:

if request.SubmittedBy == currentUser.ID {
    return errors.New("maker cannot approve their own request")
}

Validasi seperti ini jangan hanya dilakukan di frontend tapi wajib untuk dilakukan di Backend. Menyembunyikan tombol Approve dari UI bukanlah security control yang cukup. API/backend tetap harus melakukan validasi authorization.

13. Gunakan Versioning untuk Mencegah Lost Update

Ada satu kasus menarik yang kemungkinan bisa terjadi pada suatu flow bisnis yaitu ketika ada beberapa user Maker dan melakukan approval secara bersamaan. Walaupun bisa dihandle dengan cara memblok pengajuan jika data sedang aktif pengajuan berjalan. Bisa dilakukan menggunakan version.

Misalnya:

Product A
price   = Rp100.000
version = 3

Maker membuat request:

Rp100.000 → Rp120.000

Request tersebut menyimpan:

base_version = 3

Tetapi sebelum request mendapatkan approval final, ternyata Master Product telah berubah melalui proses lain:

Product A
price   = Rp110.000
version = 4

Sekarang request lama masih mengatakan:

base_version = 3

sedangkan master:

version = 4

Jika request lama langsung diterapkan, kita berpotensi menimpa perubahan terbaru.

Karena itu sebelum final approval lakukan validasi:

request.base_version == master.version

Jika:

3 != 4

berarti terjadi version conflict. Sistem dapat menghentikan approval dan meminta data diperiksa kembali.

Konsep ini dikenal sebagai optimistic locking dan sangat berguna untuk master data yang dapat diedit oleh banyak proses atau pengguna.

14. Final Approval Harus Menggunakan Database Transaction

Ketika Signer melakukan final approval, ada beberapa operasi database yang harus berhasil sebagai satu kesatuan.

Secara sederhana:

BEGIN TRANSACTION

1. Lock approval request
2. Pastikan status WAITING_SIGNER
3. Validasi authorization Signer
4. Validasi Maker ≠ Checker ≠ Signer
5. Lock Master Product
6. Validasi base_version
7. Insert approval history
8. Update Master Product
9. Increment version
10. Update request menjadi APPROVED
11. Set completed_at

COMMIT

Mengapa perlu transaction?

Bayangkan sistem melakukan:

UPDATE request → APPROVED

berhasil

kemudian:

UPDATE master_product

gagal

Database akhirnya mempunyai kondisi:

Request       : APPROVED
Master Product: belum berubah

Data menjadi tidak konsisten.

Dengan transaction:

semuanya berhasil

atau:

semuanya dibatalkan

15. Bagaimana Jika Approval Digunakan Banyak Master Data?

Sampai di sini desain kita masih spesifik untuk Product:

product_change_request
product_approval_history

Ini cukup baik jika hanya Product yang membutuhkan approval.

Tetapi dalam aplikasi enterprise biasanya requirement berkembang.

Hari ini:

Product

Besok:

Product
Merchant
Store
Category
Pricing
Bank Account
Configuration
User

semuanya membutuhkan Maker–Checker–Signer.

Jangan sampai akhirnya database memiliki:

product_approval_history
merchant_approval_history
store_approval_history
pricing_approval_history
bank_account_approval_history
category_approval_history
...

Pada kondisi tersebut kita dapat membuat approval menjadi lebih generic.

16. Membuat Generic Approval Engine

Kita dapat membuat:

approval_request
approval_history

yang dapat digunakan berbagai domain.

Contoh sederhananya:

CREATE TABLE approval_request (
    request_id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,

    request_no VARCHAR(50) NOT NULL,

    entity_type VARCHAR(50) NOT NULL,
    entity_id BIGINT UNSIGNED NULL,

    request_type VARCHAR(20) NOT NULL,

    before_data JSON NULL,
    proposed_data JSON NOT NULL,

    base_version INT UNSIGNED NULL,

    status VARCHAR(30) NOT NULL,
    current_step VARCHAR(30) NOT NULL,

    submitted_by BIGINT UNSIGNED NOT NULL,
    submitted_at DATETIME NOT NULL,

    completed_at DATETIME NULL,

    created_at DATETIME NOT NULL,
    updated_at DATETIME NULL,

    PRIMARY KEY (request_id),

    UNIQUE KEY uk_approval_request_no (request_no),

    KEY idx_approval_entity (
        entity_type,
        entity_id
    ),

    KEY idx_approval_status (
        status,
        current_step
    )
);

Contoh isi:

request_id	entity_type	entity_id	request_type
1001	PRODUCT	123	UPDATE
1002	STORE	76	UPDATE
1003	BANK_ACCOUNT	90	CREATE
1004	PRICING	81	UPDATE

Kemudian semuanya menggunakan:

approval_history

yang sama.

Arsitekturnya menjadi:

                     APPROVAL ENGINE
                           │
             ┌─────────────┴─────────────┐
             │                           │
      approval_request            approval_history
             │
             │ entity_type
             │ entity_id
             │
     ┌───────┼────────┬─────────┬─────────────┐
     ▼       ▼        ▼         ▼             ▼
  Product   Store  Merchant   Pricing    Bank Account

Pendekatan ini jauh lebih scalable jika approval merupakan fitur umum di dalam aplikasi.

17. Jangan Terlalu Cepat Membuat Generic Approval

Walaupun generic approval terlihat lebih canggih, bukan berarti semua aplikasi harus langsung menggunakannya.

Jika requirement hanya:

Master Product
     ↓
Maker
     ↓
Checker
     ↓
Signer

dan tidak ada indikasi modul lain akan menggunakan workflow yang sama, struktur:

product_change_request
product_approval_history

justru lebih sederhana dan mudah dipahami.

Prinsipnya:

Jangan membuat abstraction hanya karena kita bisa membuatnya. Buat abstraction ketika memang ada pola yang perlu digunakan kembali.

Generic approval engine menjadi masuk akal ketika workflow yang sama mulai digunakan oleh banyak domain.

18. Bagaimana Jika Workflow Berubah?

Sekarang kita mempunyai:

Maker
  ↓
Checker
  ↓
Signer

Tetapi beberapa bulan kemudian bisnis meminta:

Maker
  ↓
Checker Level 1
  ↓
Checker Level 2
  ↓
Signer

Atau Product membutuhkan:

Maker → Checker → Signer

sedangkan Pricing membutuhkan:

Maker → Checker → Supervisor → Signer

Jika kemungkinan tersebut cukup besar, jangan hardcode semua workflow di source code.

Kita dapat mengembangkan approval engine lebih jauh dengan tabel:

approval_workflow
approval_workflow_step

Contohnya:

approval_workflow
-------------------------
workflow_id
workflow_code
workflow_name
entity_type
status

dan:

approval_workflow_step
-------------------------
workflow_step_id
workflow_id
step_order
step_code
role_code

Contoh datanya:

PRODUCT_APPROVAL

1 | MAKER
2 | CHECKER
3 | SIGNER

Sedangkan workflow lain:

HIGH_VALUE_PRICING

1 | MAKER
2 | CHECKER
3 | SUPERVISOR
4 | SIGNER

Sekarang urutan approval menjadi configuration-driven, bukan sepenuhnya hardcoded.

19. Gambaran Struktur Database Akhir

Untuk aplikasi yang cukup kompleks, arsitektur akhirnya kurang lebih:

                       ┌────────────────────┐
                       │ approval_workflow  │
                       └─────────┬──────────┘
                                 │
                                 ▼
                    approval_workflow_step
                                 │
                                 ▼
Maker ───────────────▶ approval_request
                                 │
                    ┌────────────┴────────────┐
                    │                         │
                    ▼                         ▼
             approval_history          Current State
                    │
                    │ FINAL APPROVAL
                    ▼
              MASTER DATA
                    │
      ┌─────────────┼─────────────┐
      ▼             ▼             ▼
   Product        Store        Pricing

Tanggung jawab masing-masing menjadi jelas:

Master table

Menyimpan data resmi/latest approved.

Approval request

Menyimpan perubahan yang sedang diajukan.

Approval history

Menyimpan seluruh perjalanan request sebagai audit trail.

Approval workflow

Menentukan workflow yang digunakan.

Approval workflow step

Menentukan urutan dan role yang harus melakukan approval.

20. Checklist Best Practice Approval Database

Sebelum mengimplementasikan Maker–Checker–Signer, beberapa hal berikut layak diperiksa:

Jangan langsung mengubah Master Data sebelum final approval.
Pisahkan Master Data dengan pending/change request.
Simpan setiap aktivitas ke approval history.
Jangan overwrite history approval sebelumnya.
Bedakan role/step dengan action.
Bedakan RETURNED dengan REJECTED.
Catat aktivitas Maker, bukan hanya Checker dan Signer.
Terapkan segregation of duties di backend.
Simpan timestamp setiap action.
Simpan note/reason untuk action yang membutuhkan alasan.
Gunakan snapshot before dan proposed data jika diperlukan.
Gunakan versioning untuk mencegah lost update.
Gunakan database transaction saat final approval.
Gunakan generic approval engine jika workflow digunakan banyak domain.
Gunakan configurable workflow jika tahapan approval dapat berubah.

Kesimpulan

Membuat sistem Maker–Checker–Signer sebenarnya bukan sekadar menambahkan tiga role pengguna dan tombol Approve atau Reject.

Hal yang lebih penting adalah bagaimana kita mendesain database sehingga dapat menjawab:

Siapa yang membuat perubahan?

Data apa yang berubah?

Bagaimana kondisi data sebelumnya?

Siapa yang memeriksa?

Apa keputusan Checker?

Apa alasan data dikembalikan?

Berapa kali Maker melakukan revisi?

Siapa yang memberikan final approval?

Kapan setiap aktivitas dilakukan?

Data versi mana yang akhirnya menjadi data aktif?

Untuk sistem sederhana, struktur:

master_product
product_change_request
product_approval_history

sudah menjadi fondasi yang baik.

Sedangkan jika approval digunakan oleh banyak modul, kita dapat mengembangkannya menjadi:

approval_workflow
approval_workflow_step
approval_request
approval_history

sebagai sebuah generic approval engine.

Intinya, Master Data sebaiknya merepresentasikan data yang sudah resmi, sementara proses menuju persetujuan disimpan secara terpisah sebagai request dan audit trail.

Dengan pemisahan tersebut, database tidak hanya lebih rapi, tetapi juga lebih mudah diaudit, lebih aman terhadap perubahan data, dan jauh lebih siap ketika workflow bisnis berkembang di kemudian hari.

Cara Merancang Database Approval Maker-Checker-Signer yang Benar dan Scalable

Contoh Kasus: Approval Master Product

1. Kesalahan Umum: Menyimpan Semua Approval di Tabel Master

2. Pisahkan Master Data dan Approval Process

3. Master Product Hanya Menyimpan Data Approved

4. Simpan Perubahan Maker Sebagai Change Request

5. Gunakan Request Type

6. Pisahkan Current Status dan Current Step

7. Jangan Hanya Menggunakan Status REJECTED

8. Semua Aktivitas Masuk ke Approval History

9. Approval History Sebaiknya Append-Only

10. Maker Juga Bagian dari History

11. Pisahkan Role dan Action

12. Terapkan Segregation of Duties

13. Gunakan Versioning untuk Mencegah Lost Update

14. Final Approval Harus Menggunakan Database Transaction

15. Bagaimana Jika Approval Digunakan Banyak Master Data?

16. Membuat Generic Approval Engine

17. Jangan Terlalu Cepat Membuat Generic Approval

18. Bagaimana Jika Workflow Berubah?

19. Gambaran Struktur Database Akhir

20. Checklist Best Practice Approval Database

Kesimpulan

Membangun Fitur Export Data Asynchronous dengan Cursor-Based Pagination

Cara Merancang Database Approval Maker-Checker-Signer yang Benar dan Scalable

Contoh Kasus: Approval Master Product

1. Kesalahan Umum: Menyimpan Semua Approval di Tabel Master

2. Pisahkan Master Data dan Approval Process

3. Master Product Hanya Menyimpan Data Approved

4. Simpan Perubahan Maker Sebagai Change Request

5. Gunakan Request Type

6. Pisahkan Current Status dan Current Step

7. Jangan Hanya Menggunakan Status REJECTED

8. Semua Aktivitas Masuk ke Approval History

9. Approval History Sebaiknya Append-Only

10. Maker Juga Bagian dari History

11. Pisahkan Role dan Action

12. Terapkan Segregation of Duties

13. Gunakan Versioning untuk Mencegah Lost Update

14. Final Approval Harus Menggunakan Database Transaction

15. Bagaimana Jika Approval Digunakan Banyak Master Data?

16. Membuat Generic Approval Engine

17. Jangan Terlalu Cepat Membuat Generic Approval

18. Bagaimana Jika Workflow Berubah?

19. Gambaran Struktur Database Akhir

20. Checklist Best Practice Approval Database

Kesimpulan

Membangun Fitur Export Data Asynchronous dengan Cursor-Based Pagination

Extensions VS Code yang Wajib Diinstall Backend Engineer

GORM Mempermudah Akses Database dalam Membangun Aplikasi

Arti Dari Kode Status Respon HTTP yang Perlu Kamu Tau