Admin panel

The single landing page for everything an admin manages. user approvals, request queues, the financial ledger, content, infrastructure, the audit log. Organized in five groups, gated by role and plan.

Who sees it

There are two ways in. A full admin (the admin or system_admin role) gets the whole hub. A scoped admin (someone granted a custom role like Architectural Chair or Treasurer) reaches only the admin sub-pages their grant covers. every other /admin/* page redirects them back out, and each page enforces that itself, not just the outer guard.

The /admin hub shows the Admin Panel landing only when you have at least one tool tile to open. A scoped admin whose work lives on a converged page (an Architectural Chair working from /architectural, say) has no hub tiles, so visiting /admin sends them to /dashboard instead of an empty panel. The adoption scoreboard and the other "run the community" cards on the hub are for full admins only. Board members and regular residents have no admin access unless granted a role.

The five groups

The admin page is a grid of links grouped by topic, not a separate dashboard with its own widgets. Each link opens the dedicated admin sub-page for that feature. The groups:

People & Access covers user management (approve / deny pending registrations, change roles), invite codes (generate single-use or multi-use codes), and the property roster (CSV import, lat/lng, occupancy type).

Requests & Compliance covers estoppel requests, the compliance dashboard, and dues administration. Community issues, architectural reviews, and violations are managed inline on their own pages now, so they aren’t separate cards here. Most admin time still gets spent across these queues.

Community Content holds the financial dashboard (budgets per year, categories, PDF import) and the welcome kit (the post-onboarding orientation cards new residents see).

Directory & Infrastructure holds chat-channel management. (Amenity reservations are administered inline on the Reservations page now.)

System holds the emergency-alert composer (one active alert at a time, broadcast to every account), the audit log (the read-only history of every admin action), and the data-rights requests, content reports, and posting-appeals queues. For system_admins this group also includes Site Settings.

Why some items don’t appear

Two filters can hide items from this grid even though they exist as URLs.

Plan tier. items whose feature isn’t included on the community’s current plan are removed entirely. The corresponding admin pages still exist, but the nav and this grid don’t advertise them. an upgrade lights them back up.

Community mode. when an admin toggles the community on into the community-mode demo / placeholder state, payment-flow items (dues, violations, architectural, community issues, estoppel, financials, compliance) are hidden from residents and from the relevant slots on this grid. The admin can still reach them via direct URL if needed.

Audit history

Every meaningful admin action across the portal is recorded in the audit log (creates, edits, deletes, status changes, role changes, approvals, refunds). The log is the source of truth when figuring out who did what and when, and most admin sub-pages link directly into the audit log filtered for the relevant entity. The catch-all entry sits in this page’s System group.