Skip to main content
When you edit a role under Settings → Access → Roles & Permissions, you see a list of modules, and each module has a row of checkboxes. This page covers the two modules that control platform-level administration — User Management (the “Users” and “Roles” modules) and Tenant Management (the “Tenant Admin” module) — with a plain description of what turning each checkbox on actually lets someone do. There are 2 modules and 10 checkboxes in User Management, and 1 module and 5 checkboxes in Tenant Management. Every module here follows the same five-checkbox pattern: Add (create new), Edit (change existing), Delete (remove), View (see it), View All (see everyone’s, not just your own) — there are no module-specific actions in this area, unlike Loans or Reports elsewhere on the platform. Where to manage this: Settings → Access → Roles & Permissions. These are high-privilege, organization-wide modules — anyone with Edit on Roles can change what every other role (including their own) is allowed to do, and anyone with Delete on Users can remove other people’s accounts. Grant them sparingly.

​
User Management

​
1. Roles

This is the permission that controls the role editor itself — the same screen you’re reading about right now. Because of that, it’s one of the most sensitive checkboxes on the platform: whoever has it can change what any other role (including roles held by SuperAdmins) is allowed to do.
Verified enforcement gap: the endpoints behind this module (GET /api/admin/roles, DELETE /api/admin/roles/{roleId}) don’t check these permission checkboxes at all. They’re gated only by a hardcoded check that the caller holds the built-in SuperAdmin or Admin identity role — not by whether their role has roles:read or roles:delete granted. In practice, toggling View or Delete here has no effect: only membership in SuperAdmin/Admin controls access to those two actions today.

​
2. Users

This governs the user list and the actions available from it — looking someone up, editing their profile, deactivating their account, or granting them a one-off extra permission outside of their assigned role.
Verified enforcement gap: the same pattern applies here. GET /api/admin/users (the user list), PUT /api/admin/users/{userId} (edit), and DELETE /api/admin/users/{userId} (delete) carry no permission check tied to these checkboxes — they inherit the controller-wide hardcoded requirement that the caller be in the SuperAdmin or Admin identity role. Assigning a role with only users:read (and not the SuperAdmin/Admin identity role) does not currently grant access to these screens.

​
Tenant Management

​
1. Tenant Admin

Hitaji 360 is multi-tenant: each organization (“tenant”) that signs up gets its own space, and can subscribe to one or more products (Sacco360, HR, Edu360, and so on). This module covers the admin-side actions around that — listing tenants, linking or unlinking a user from a tenant, suspending/reactivating a user’s membership in a tenant, and provisioning the standard set of roles for a tenant when it subscribes to a new product. It does not cover the separate, standalone Tenant Management application (a different product used for commercial subscription management) — this is the auth-service’s own tenant-administration surface, reached from the same role editor as everything else here.
Verified enforcement gap: GET /api/admin/tenants (the tenant list behind View) has the same issue as Roles and Users above — it’s gated purely by the hardcoded SuperAdmin/Admin identity-role check, not by the tenant-admin:read claim this checkbox grants. Separately, the role-provisioning endpoint (POST /api/admin/tenants/{tenantId}/provision-roles) runs the opposite mismatch: it’s open to any authenticated caller regardless of role or permission claims (used by automated service-to-service calls), so Add here doesn’t gate it either, in the other direction — it’s less restrictive than the checkbox implies, not more.