বাংলা সারসংক্ষেপ

Maker submit → threshold check → PENDING_APPROVAL → checker → অনুমোদন/প্রত্যাখ্যান। থ্রেশহোল্ড (BDT): বুকিং 200K, রিফান্ড 100K, ক্রেডিট লিমিট 500K, JE 50K, পেআউট 1M, সরবরাহকারী ব্যাঙ্ক পরিবর্তন (সর্বদা)।

বিস্তারিত (English)

Chapter 13.5 — Approval Workflows

Context

Many operations require a second pair of eyes beyond the initiating user — the maker-checker pattern. This chapter visualises the approval workflow as it applies across the platform: bookings over threshold, refunds over threshold, credit-limit changes, supplier bank-detail changes, journal entries above threshold, payouts, period close, and write-offs.

Text definitions of specific thresholds live in the respective module chapters; this chapter shows the common workflow shape.

Roles

Role	Involvement
Initiator (Maker)	Creates the request
Approver (Checker)	Reviews and decides
Notifier	System — surfaces request to approver
Auditor	Reviews after-the-fact via audit log

Core invariants

Maker ≠ Checker. The same user cannot both create and approve.
Reason required. Both maker and approver capture free-text reasons.
Threshold-driven entry. Below threshold → auto-approved (no human approver); at or above → workflow.
Time-bound. Requests expire after a configurable TTL.
Audit trail mandatory. Every state change goes to the audit log.

Generic state machine

stateDiagram-v2 [*] --> DRAFT: Maker drafts DRAFT --> PENDING_APPROVAL: Submit PENDING_APPROVAL --> APPROVED: Approver OK PENDING_APPROVAL --> REJECTED: Approver declines PENDING_APPROVAL --> WITHDRAWN: Maker withdraws PENDING_APPROVAL --> EXPIRED: TTL passes APPROVED --> EXECUTED: Downstream effect committed APPROVED --> CANCELLED: Cancelled post-approval (rare) REJECTED --> [*] WITHDRAWN --> [*] EXPIRED --> [*] EXECUTED --> [*]

Generic sequence

sequenceDiagram autonumber actor M as Maker actor C as Checker participant T as travoBooks participant N as Notification M->>T: Submit operation (over threshold) T->>T: Detect threshold breach T->>T: Create approval_request (state=PENDING_APPROVAL) T->>N: Notify eligible approvers N->>C: Email / in-app / SMS C->>T: Open approval inbox C->>T: Review payload + audit context alt Approve C->>T: Approve + reason T->>T: Verify Approver ≠ Initiator T->>T: Execute downstream effect T->>N: Notify Maker (and stakeholders) else Reject C->>T: Reject + reason T->>N: Notify Maker end Note over T: Audit log entries on every transition

Threshold examples

The platform's partner_approval_thresholds table defines per-partner thresholds. Examples (BDT):

Operation	Default threshold	Approver role
Single booking	200,000	Mid-Office Supervisor
Single refund	100,000	Mid-Office Supervisor
Customer credit-limit increase	500,000	Controller
Supplier bank-detail change	(any)	Controller
Manual journal entry	50,000	Accountant Supervisor
Payout	1,000,000	Treasurer
Period close	(any)	Controller
Write-off	25,000	Controller

Thresholds can be tiered: - 200K–500K → Supervisor. - 500K–2M → Controller. - > 2M → Controller + Director.

Multi-step approval supported.

Specific approval flows

Booking over threshold

flowchart TD A[Agent submits booking] --> B{Amount > threshold?} B -->|No| C[Auto-issue] B -->|Yes| D[state = PENDING_APPROVAL] D --> E[Approver receives notification] E --> F{Decision} F -->|Approve| G[Booking issuance proceeds] F -->|Reject| H[Back to DRAFT] F -->|TTL expires| I[Booking auto-cancels]

Refund approval

Identical shape; approver_role often differs (refund-specific approver).

Customer credit-limit change

flowchart TD A[AM updates customer credit limit] --> B{New limit > threshold?} B -->|No| C[Apply immediately + audit] B -->|Yes| D[Submit for Controller approval] D --> E{Controller decision} E -->|Approve| F[Apply + audit + notify] E -->|Reject| G[Discard]

Supplier bank-detail change

Special case: always requires approval regardless of amount, due to vendor-fraud risk (Chapter 3.2). Additional control: 30-minute payout hold post-approval.

flowchart TD A[Supplier requests bank change] --> B[AM submits update] B --> C[PENDING_APPROVAL — Controller] C --> D{Controller verifies callback to known supplier contact} D -->|Verified| E[Approve] D -->|Unverified| F[Reject — initiate fraud-check] E --> G[Apply change + activate 30m payout hold] G --> H[Send confirmation to supplier's known email] H --> I[Hold lapses; payouts resume]

Journal entry over threshold

flowchart TD A[Accountant drafts JE] --> B{Sum > threshold?} B -->|No| C[Post immediately] B -->|Yes| D[PENDING_APPROVAL — Senior Accountant] D --> E{Decision} E -->|Approve| F[Post JE] E -->|Reject| G[Back to DRAFT]

Payout

Cash leaves the platform; always approver-gated above small thresholds.

sequenceDiagram actor TR as Treasury Initiator actor TM as Treasury Approver participant T as travoBooks participant B as Bank TR->>T: Draft payout (supplier, amount, account) T->>T: Validate bank account, recent change holds, sanctions TR->>T: Submit for approval T->>TM: Notify TM->>T: Approve (with reason) T->>B: Submit wire instruction B-->>T: Wire reference T->>T: state=SENT; post JE B-->>T: Wire confirmed (T+1) T->>T: state=CONFIRMED

Period close

The close operation itself requires maker-checker (Chapter 5.10).

Approver eligibility

The system computes eligible approvers from: - Role membership matching the required approver role. - Active (not on leave). - Not the maker. - Has access to the resource (branch / partner scope).

If no eligible approver exists, the request raises a configuration alert (often during onboarding, before any approver is assigned).

Delegation & escalation

Delegation: an approver can delegate to a named alternative for a time window.
Escalation: if no decision in (configurable) hours, escalate to a higher tier.
Pull-back: approvers can re-assign requests within the eligible pool.

SLA

Default response SLA: 4 business hours during partner business hours.
Configurable per request type.
SLA breach triggers escalation + dashboard flag.

Approval bypass / emergency

For genuine emergencies (e.g., need to issue a critical ticket immediately): - An emergency override path exists for partner_admin role. - Override creates a partner_emergency_override record with extended audit (witness user, justification, post-hoc review). - All overrides reviewed weekly by controller. - Excessive overrides trigger policy review.

Database tables touched

Table	Role
`approval_requests`	Header per request
`approval_decisions`	Per-decision audit
`partner_approval_thresholds`	Configuration
`audit_logs`	Every transition
`notifications`	Approver alerts

Common pitfalls

⚠️ Same user as maker and checker via role-juggling. Engine enforces by user-id identity.
⚠️ Approver auto-approving without reading payload. UX shows full diff; reason field forces engagement.
⚠️ Stale thresholds. Review annually; inflation drifts thresholds.
⚠️ No eligible approver configured. Catch at onboarding.
🔒 Approval-flow bypass attempts are themselves audited; suspicious patterns trigger security review.