Administration
Users & roles
Admin → Users is where you promote support staff. It's a deliberately small screen: people arrive by signing in, and the only thing you change is their role.
How people appear here
There is no invite flow. A person shows up in the list once one of these happens:
- They sign in themselves, by magic link, Google, or GitHub.
- Someone files a ticket for their email through the widget.
- Your backend creates a ticket for their email through the API.
In every case the account is created with the customer role. To onboard an agent, have them sign in once, then promote them.
someone@example.comcreates a confirmed account for that address. Those people appear in this list having never visited your helpdesk — that's expected, and it's how their ticket history stays attached to them.The users screen
/admin/users lists every profile, newest first, with three columns: User (display name), Email, and Role.
Promote someone to agent
- Ask them to sign in once so their profile exists.
- Open Admin → Users and find them by email.
- Change the role dropdown to Agent — it saves immediately.
- They now see Inbox and Feedback in the header on their next page load. No sign-out needed.
The same dropdown demotes. There is no separate flow and no confirmation step.
/admin becomes unreachable for everyone and recovery requires running SQL against the database directly. Always keep at least two admins.Every role change is recorded in the audit log with who did it and what the role was before.
The admin dashboard
/adminshows five live counters, each a link to where you'd act on it:
| Tile | Counts | Goes to |
|---|---|---|
| Open tickets | Every ticket with status Open, across all apps | /inbox |
| Unassigned | Open or Pending tickets with no assignee | /inbox |
| Open feedback | Feedback posts still at status Open | /feedback |
| Apps | Total apps | /admin/apps |
| Users | Total profiles | /admin/users |
Unassignedis the one to watch daily — it's the closest thing to a “nobody has picked this up” alarm. The numbers are workspace-wide with no per-app breakdown and no date filtering.
The audit log
Lunax records significant admin actions to an audit table: app creation, logo changes, API key creation and revocation, role changes, ticket updates, and feedback status changes. Each entry stores who did it, what changed, and when.
audit_logs table in Supabase. Note that agents can read it too, not just admins.What you can't do
- Invite someone by email — they must sign in first.
- Deactivate, suspend, or delete a user. Demoting to customer is the closest option.
- Give someone agent access to one app only — roles are workspace-wide.
- Create a user manually from the admin UI.
- Edit anyone's name, email, or avatar — those come from their sign-in provider.
- See when someone last signed in.