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.