ISMAIL MASSERAN
3.9 KiB
The differences are actually quite small, but they're important because they reflect the real business process more accurately.
Earlier Design
I initially assumed:
Management
|
Approve/Reject
|
Board
|
Pass/Fail
|
General Manager
|
Approve/Reject
Therefore I proposed:
application_management_reviews
application_board_evaluations
application_gm_decisions
or later:
application_reviews
- MANAGEMENT
- BOARD
- GM
because I thought the GM was making a decision.
Current Design
After your clarification:
The outcome is already known after board evaluation.
The GM only prints the result letter and notifies the applicant.
The workflow is actually:
Management
|
Approve/Reject
|
Board
|
Pass/Fail
|
General Manager
(Print letter)
(Send email)
The GM is no longer a reviewer.
Therefore:
Removed
application_gm_decisions
because there is no GM decision to store.
Added
application_notifications
because the GM's responsibility is administrative:
- Generate acceptance/rejection letter
- Send email
- Mark notification completed
Example:
| application_id | letter_generated_at | email_sent_at |
|---|---|---|
| 1001 | 2026-06-01 10:00 | 2026-06-01 10:05 |
Status Changes
Earlier
MANAGEMENT_REJECTED
GM_REJECTED
APPROVED
ACCOUNT_CREATED
Current
MANAGEMENT_REJECTED
BOARD_FAILED
BOARD_PASSED
NOTIFICATION_PENDING
COMPLETED
because the board determines the outcome.
Review Tables
Earlier
I proposed three tables:
application_management_reviews
application_board_evaluations
application_gm_decisions
Then simplified to:
application_reviews
with:
MANAGEMENT
BOARD
GM
Current
Still:
application_reviews
but only:
MANAGEMENT
BOARD
No GM stage.
What I Would Simplify Even Further
Looking at your process, I'd actually make it even leaner.
membership_applications
Add outcome fields directly:
membership_applications
-----------------------
id
status
management_result
board_result
notification_sent_at
submitted_at
completed_at
Where:
management_result
-----------------
PENDING
APPROVED
REJECTED
board_result
------------
PENDING
PASS
FAIL
Then you might not even need application_reviews if:
- One management review only
- One board evaluation only
You could store everything directly on the application record.
Example:
| application | mgmt | board |
|---|---|---|
| APP001 | APPROVED | PASS |
| APP002 | APPROVED | FAIL |
| APP003 | REJECTED | NULL |
My Recommendation
For your described workflow, I'd use:
membership_applications
application_applicants
application_heirs
application_documents
application_references
application_reviews
application_notifications
users
members
and remove:
application_management_reviews
application_board_evaluations
application_gm_decisions
application_workflow_logs
unless you have a compliance/audit requirement.
Why remove application_workflow_logs?
If your workflow is fixed and simple:
- Management reviews once.
- Board evaluates once.
- GM sends notification once.
Then:
application_reviews
already tells you who reviewed and when.
A workflow log becomes useful only when you need things like:
Reopened
Returned for correction
Resubmitted
Reassigned
Escalated
Withdrawn
If those scenarios don't exist, it's additional complexity without much benefit.
So the "latest" design is mainly different because the GM is no longer treated as a decision-maker, only as a notification handler. That removes an entire approval layer from the data model and simplifies the workflow considerably.