Managing users, roles, and permissions
How access control works in practice, from role permissions to role-based menus and business-scoped data access.
Permissions are checked server-side on every domain API
The shared permission utility loads the signed-in profile, its role, and the current business, then validates the requested permission name against the `role_permissions` table.
That pattern appears across business, document, dashboard, profile, package, permission, and prompt routes.
Menu visibility is also role-driven
Top and bottom navigation menus are fetched from role menu tables rather than hard-coded in the client. In other words, what a user sees in navigation is intentionally part of the permission model.
Document access is business-scoped
Many APIs automatically filter by `businessId` from the permission check. The documentation should explain that some users work only inside their assigned business, while super admins and broader roles can see wider data.
Observed role families
The codebase repeatedly branches on six visible role families.
- CLIENT
- CLIENT_APPROVAL_1
- CLIENT_APPROVAL_2
- PAYMENT_OFFICER
- REJECT_OFFICER
- SUPER_ADMIN
Continue with adjacent workflows
Managing businesses, packages, and timezones
What super admins can configure at the business level and how those settings affect document operations.
Approval levels and rejection logic
The real two-step approval model in Datamonster, including role separation, counts, pending queues, and reject officer visibility.
Dashboard views by role
What each role sees on the main dashboard and why the dashboard is really a routing layer into operational queues.