Summary
Add traditional SaaS-grade user management capabilities so admins can view invite status, resend invites, reset passwords, deactivate users, and perform other lifecycle actions from the admin panel.
Problem statement
Admins currently lack visibility into the state of sent invitations and have no self-serve tools to take action on users (resend invites, force password resets, deactivate accounts, etc.), forcing them to contact support or work around the product for routine user management tasks.
π¦ Definition of ready
Before entering a cycle, confirm:
- [ ] Problem statement is clear
- [ ] Acceptance criteria are defined
- [ ] Scope & non-goals are explicit
- [ ] Linked to relevant context
- [ ] Can be completed by one person in one sprint
If any box is unchecked β do not pull into sprint
Acceptance criteria
- [ ] Admins can see a list of all pending invitations, including invitee email, invite date, and expiry status
- [ ] Admins can resend an expired or pending invitation from the UI
- [ ] Admins can revoke a pending invitation before it is accepted
- [ ] Admins can trigger a password reset email for any active user
- [ ] Admins can deactivate (suspend) a user, immediately revoking their access without deleting their data
- [ ] Admins can reactivate a previously deactivated user
- [ ] Admins can change a user's role (e.g. member β admin) from the user management table
- [ ] Admins can remove a user from the workspace entirely
- [ ] All user management actions are logged in an audit trail visible to admins
If this checklist is complete, the issue is done.
Scope
In scope
- Pending invitations table with status, sent date, expiry, and per-invite actions (resend, revoke)
- Password reset trigger (sends reset email to user)
- User deactivation / reactivation
- Role change from user table
- User removal from workspace
- Audit log entries for all of the above actions
Out of scope
- SSO / SAML provisioning and deprovisioning
- Bulk user import / CSV upload
- Fine-grained permission sets beyond existing role types
- User impersonation / "log in as user"
- Self-serve account deletion by end users
Context & links
- [ ] Fathom (customer feedback):
- [ ] PRD / Project:
- [ ] Incident:
- [ ] Design:
- [ ] Technical decision record:
Implementation notes (optional)
- Invitation state should cover: pending, accepted, expired, revoked
- Deactivation should invalidate active sessions immediately (consider token invalidation strategy)
- Password reset should reuse the existing reset flow; this is just an admin-triggered entry point
- Audit log can be appended to an existing audit trail if one exists, or scoped as a new lightweight table
β
Definition of done
- [ ] Acceptance criteria are met
- [ ] Code is reviewed & merged
- [ ] Tests pass (functional + design where applicable)
- [ ] Feature is deployed
- [ ] Docs / release notes updated if needed