Users & Roles

Overview

Rendum uses role-based access control. Every user belongs to exactly one Tenant and carries exactly one role. The role determines which screens and actions are visible. Permissions are enforced at the API middleware level, so a user attempting to bypass the SPA and call an unauthorized endpoint directly will receive 403.

Roles

• OWNER — full administrative control. Can manage users, tenant configuration, billing setup, payer onboarding, contract sign-off, rule overrides, and audit export. Typically held by 1–2 people per tenant.
• ADMIN — same as OWNER except cannot manage other ADMINs or OWNERs and cannot view billing-cycle finance reports. Day-to-day administrative work.
• BILLING_MANAGER — can trigger billing runs, view decision-replay, regenerate audit packages, export rosters, and resolve exceptions. Cannot manage users or payer configuration.
• OPERATIONS — read access to most screens; can resolve exceptions and dismiss alerts. Cannot trigger billing runs or change payer configuration.
• VIEWER — read-only access to dashboards, rosters, and audit trails. No write capability anywhere.

Inviting a new user

1. From the Users screen, click Invite User.
2. Enter the invitee's email address and select their role.
3. Click Send Invitation.

The system sends an invitation email containing a single-use link to a "Set Your Password" page. The link expires after 24 hours. Status shows "Invitation Sent" until the invitee completes the flow; then it flips to "Active".

Editing a user

Click the user's row. You can change:

• Role (subject to the privilege rules above — cannot promote anyone above your own role).
• Active status (deactivate suspends the account immediately; reactivate is one click).
• Org-unit assignment (if Org Units are enabled).

Deactivation does NOT delete the user record. Deleted users are soft-deleted with a 30-day grace window; during that window an OWNER can restore via support.

Change password (self-service)

Every user can change their own password from the user-profile menu (top-right). Requires the current password and a new password meeting the complexity policy (minimum 12 characters, mixed case, one number, one symbol).

Admin password reset

OWNER and ADMIN can reset another user's password from the Users screen. The reset:

• Generates a single-use, 1-hour reset link.
• Sends the link to the user's email.
• Writes an audit row tagged USER_PASSWORD_RESET_BY_ADMIN.

Admins cannot set the user's new password directly — only issue the reset link.

Org units (optional)

If your tenant has Org Units enabled, each user is assigned to one Org Unit. Org-Unit-scoped users see only their unit's payers, rosters, contracts, and decisions. OWNER and ADMIN see all units regardless of assignment.

Login lifecycle

• Email + password (default).
• SAML or OIDC if your tenant has SSO configured.
• Magic-link signup (where enabled).

Every successful login updates the lastLoginAt column. Failed logins are rate-limited at the IP and email level.

Session lifetime

The session JWT is signed by the server (HS256, 32-byte tenant-scoped secret) with a 15-minute default TTL. The SPA silently refreshes on every authenticated API call provided the user is still active. After 24 hours of inactivity the user must log in again — this is non-negotiable per the security posture.

lastLoginAt is updated by explicit sign-in only, not by silent JWT refresh.

Audit footprint

• USER_INVITED
• USER_ACTIVATED
• USER_DEACTIVATED
• USER_ROLE_CHANGED
• USER_PASSWORD_CHANGED
• USER_PASSWORD_RESET_BY_ADMIN
• USER_DELETED
• USER_RESTORED