R RockAI docs
/

Platform admin

Platform overview

The platform admin console is the operator-only surface at /admin. It's where you manage plans, watch usage across every workspace, retry failed jobs, and impersonate customers for support. Only users with role = super_admin can see it — everyone else gets a 404 (not 403) so the panel doesn't even reveal it exists.

Becoming a super admin

The flag is the users.role column, cast to the PlatformRole enum which has two cases: customer (the default for every signup) and super_admin. There's no UI to grant it — it's set by hand via tinker or a one-shot migration on a new deployment: 

php artisan tinker --execute 'User::where("email", "you@company.com")->update(["role" => "super_admin"]);'

Demoting works the same way (role = "customer"). There's no notification — the next page load will show or hide the admin nav.

Layout

The admin sidebar lists ten sections:

  • Dashboard — KPIs across all workspaces, system health summary.
  • Workspaces — every workspace, their plan, owner, member count, conversation usage.
  • Users — every user across the platform, their workspaces, last seen.
  • Agents — every agent on the platform, with workspace + publish state.
  • Conversations — every conversation. Useful for support.
  • Leads — every lead.
  • Plans — Stripe-synced plan CRUD. See Plans & Stripe sync.
  • Subscriptions — every active subscription. Reverse-lookup workspaces by Stripe subscription ID.
  • Usage — month-over-month conversation count by workspace.
  • Queue Failures — failed jobs with retry / forget controls.

Header actions

The admin header (top bar of every admin page) has:

  • Site Health pill — green / amber / red. Hover for the breakdown — failed jobs, Stripe config, LLM provider, vector store, mail driver, Reverb keys, cache. See Site health & failed jobs.
  • Notifications dropdown — unread alerts from two streams:
    • Health failures (critical / warning severity) — failed jobs, missing Stripe key, missing LLM provider, mail not configured, etc. These paint the bell red and increment the site_health.issues_count.
    • Business events (info severity, last 24 hours) — new users signed up, new workspaces created, new paid subscriptions, new leads captured platform-wide. Info severity only; the bell stays neutral but you see what just happened.
    Cached 60 seconds. Both streams merge into one dropdown — health failures appear first, biz events below.
  • Global search — searches workspaces, users, agents, conversations, leads with one keystroke.

Daily admin digest

Opt-in via Settings → System → Mail → Daily admin digest (checkbox). When enabled, every super_admin receives an email at 09:00 UTC summarising the previous 24 hours:

  • New users signed up
  • New workspaces created
  • New paid subscriptions
  • New leads captured
  • Conversations active right now

The scheduled command is php artisan admin:send-daily-digest; it short-circuits with an "info" log line when the setting is off, so you can leave the schedule wired without spamming installs that opted out. --force bypasses the flag for one-off previews; --dry-run computes the digest and prints it without sending mail.

Impersonation

From the Workspaces or Users page, click Impersonate. A few things happen:

  1. Your admin session is preserved.
  2. You become the target user inside their workspace.
  3. A persistent You're impersonating X banner appears at the top of every page until you stop.
  4. A row is logged in audit_logs so the action is traceable.

Click Stop impersonating in the banner to drop back to your admin session. The banner is intentionally hard to miss — there's no shortcut to dismiss it without ending the impersonation.

Search

Press / from anywhere in the admin panel. The global search dropdown opens with sections:

  • Workspaces (by name).
  • Users (by email).
  • Agents (by name + workspace).
  • Conversations (by message text).
  • Leads (by name + email).

Each result links straight to the resource. The customer surface has the same search but scoped to the current workspace.

Audit log

Every admin action — plan create/update/delete, impersonation start/stop, workspace changes — writes to the audit_logs table for forensic traceability. There's no UI page for browsing audit logs in v1; query the table directly when you need to investigate.