Approval levels and rejection logic
The real two-step approval model in Datamonster, including role separation, counts, pending queues, and reject officer visibility.
Approval is role-specific
Approval level 1 and approval level 2 do not share a single queue. The APIs and dashboard widgets explicitly separate users who act on first approval from users who act on second approval.
- Level 1 queue: documents with no `approval_1`, no reject markers, and no later approval
- Level 2 queue: documents with `approval_1` present, but no `approval_2` and no reject markers
- Reject officer view: any document with `approval_1_reject` or `approval_2_reject`
Dashboard summaries mirror the backend filters
The dashboard is not estimated client logic. Pending, approved, and rejected lists come from backend queries that already encode role-specific business filters and approval conditions.
Documentation should separate rejection from archival cleanup
A rejected document remains an operational item. The product has dedicated reject APIs, reject dashboards, and reject notes, so the knowledge base should teach how to resolve a reject rather than treating rejection as a terminal dead end.
Continue with adjacent workflows
Managing ready-for-payment priorities
How payment officers see urgent, medium, low, and unset queues after approvals are complete.
Dashboard views by role
What each role sees on the main dashboard and why the dashboard is really a routing layer into operational queues.
Reviewing document detail and line items
How detail view is structured, which accounting and payment fields matter, and how operators correct OCR output.