ISMAIL MASSERAN
284 lines
3.9 KiB
Markdown
284 lines
3.9 KiB
Markdown
The differences are actually quite small, but they're important because they reflect the **real business process** more accurately.
|
|
|
|
## Earlier Design
|
|
|
|
I initially assumed:
|
|
|
|
```text
|
|
Management
|
|
|
|
|
Approve/Reject
|
|
|
|
|
Board
|
|
|
|
|
Pass/Fail
|
|
|
|
|
General Manager
|
|
|
|
|
Approve/Reject
|
|
```
|
|
|
|
Therefore I proposed:
|
|
|
|
```text
|
|
application_management_reviews
|
|
application_board_evaluations
|
|
application_gm_decisions
|
|
```
|
|
|
|
or later:
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
Management
|
|
|
|
|
Approve/Reject
|
|
|
|
|
Board
|
|
|
|
|
Pass/Fail
|
|
|
|
|
General Manager
|
|
(Print letter)
|
|
(Send email)
|
|
```
|
|
|
|
The GM is no longer a reviewer.
|
|
|
|
Therefore:
|
|
|
|
### Removed
|
|
|
|
```text
|
|
application_gm_decisions
|
|
```
|
|
|
|
because there is no GM decision to store.
|
|
|
|
---
|
|
|
|
### Added
|
|
|
|
```text
|
|
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
|
|
|
|
```text
|
|
MANAGEMENT_REJECTED
|
|
GM_REJECTED
|
|
APPROVED
|
|
ACCOUNT_CREATED
|
|
```
|
|
|
|
### Current
|
|
|
|
```text
|
|
MANAGEMENT_REJECTED
|
|
BOARD_FAILED
|
|
BOARD_PASSED
|
|
NOTIFICATION_PENDING
|
|
COMPLETED
|
|
```
|
|
|
|
because the board determines the outcome.
|
|
|
|
---
|
|
|
|
## Review Tables
|
|
|
|
### Earlier
|
|
|
|
I proposed three tables:
|
|
|
|
```text
|
|
application_management_reviews
|
|
application_board_evaluations
|
|
application_gm_decisions
|
|
```
|
|
|
|
Then simplified to:
|
|
|
|
```text
|
|
application_reviews
|
|
```
|
|
|
|
with:
|
|
|
|
```text
|
|
MANAGEMENT
|
|
BOARD
|
|
GM
|
|
```
|
|
|
|
### Current
|
|
|
|
Still:
|
|
|
|
```text
|
|
application_reviews
|
|
```
|
|
|
|
but only:
|
|
|
|
```text
|
|
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:
|
|
|
|
```sql
|
|
membership_applications
|
|
-----------------------
|
|
id
|
|
|
|
status
|
|
|
|
management_result
|
|
board_result
|
|
|
|
notification_sent_at
|
|
|
|
submitted_at
|
|
completed_at
|
|
```
|
|
|
|
Where:
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
membership_applications
|
|
application_applicants
|
|
application_heirs
|
|
application_documents
|
|
application_references
|
|
application_reviews
|
|
application_notifications
|
|
users
|
|
members
|
|
```
|
|
|
|
and remove:
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
application_reviews
|
|
```
|
|
|
|
already tells you who reviewed and when.
|
|
|
|
A workflow log becomes useful only when you need things like:
|
|
|
|
```text
|
|
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.
|