Documentation/Managing Your App/The Admin Panel
The Admin Panel
The in-console Admin Panel page and its Manage Records operator view — what's on them, who can reach them, and how they carry over unchanged to your deployed app.
Overview
"Admin Panel" refers to two related things in Supero, and it's worth separating them up front: the developer console you use to build (app.supero.dev), and a per-tenant operator surface that ships inside your deployed app. This page covers the second one — the Admin Panel page in the console, its Manage Records operator view, who can reach each, and what your own users see once you deploy.
It's aimed at whoever decides which of your team can open and moderate live data, and at developers wiring up transactional services (cart, booking, order, and friends) who want to know what operator tooling they get for free.
Two Admin Surfaces At A Glance
Keep these two apart — they run on different hosts, serve different audiences, and use different permissions.
| Surface | Runs at | Who uses it | What it's for |
|---|---|---|---|
| Developer console | app.supero.dev | You — the builder | Design schemas, import services, generate and deploy your app, manage domain/project settings and team access |
| Admin Panel | https://<your-domain>.supero.dev | Your app's tenant admins | Day-to-day operations on the data your app's users create: records, reservations, orders, subscriptions |
The console has its own Admin Panel page (at /admin-panel) that acts as the on-ramp to the second surface: it shows you your tenant admin URL and links out to it, plus an in-console Manage Records view for working the same data without leaving the console.
The Console Admin Panel Page
From the console sidebar, the Admin Panel page shows a single action card: your tenant admin URL, and two buttons — Open Panel, which opens https://<your-domain>.supero.dev in a new tab, and Manage records, which routes to the in-console operator view at /admin-panel/records.
text
https://acme-corp.supero.devThat URL is derived from your domain name — the top level of the Domain → Project → Tenant → User hierarchy — not from an individual project or tenant. It's connected to your project's schemas and whatever test or production data currently lives in them.
ℹ️ Permission required: tenant:list
Opening /admin-panel requires the tenant:list permission. If your role doesn't have it, the console shows an Access Denied page naming the missing permission and your current role instead of the panel — nothing partially loads.
What's Inside
The Admin Panel page also surfaces the console features your tenant admins can reach once they open the panel — this is the same feature set that ships with your deployed app, not a console-only preview.
| Feature | What it does |
|---|---|
| AI Agent | Natural-language queries over your project's data |
| Connectors | External integrations wired through the Plugin Registry |
| Feature Flags | Toggle and roll out functionality per project or tenant |
| Test Data Generator | AI-generated mock data for your schemas |
| API Docs | Interactive reference for your project's CRUD and service endpoints |
| Data Explorer | Browse and manage records across every schema |
| API Keys | Issue and revoke X-API-Key access tokens |
| Team & RBAC | Manage users, roles, and object-level access policies |
| Usage Analytics | Request volume and performance over time |
| Audit Trail | Compliance logging of who changed what, when |
| Security | Security settings for your workspace |
| Webhooks | Outbound event subscriptions to your own endpoints |
Manage Records: The Operator Panel
Manage Records (/admin-panel/records) is a purpose-built operator view over the transactional services in your project — the 17 backend primitives (attachment, order, booking, payment, and so on) you opt into by extending a base schema with extends: "<service>:base_<name>". Instead of listing every schema flatly, it groups whatever you've extended into six archetypes so an operator can find things by kind of record rather than by schema name.
| Archetype | Services grouped in | What it covers |
|---|---|---|
| Documents | attachment, document_signature | File attachments, e-signatures, scanned uploads |
| Reservations | booking, appointment | Bookings and appointments with conflict detection |
| Lifecycle records | order, cart, task, ticket, payment, approval | Orders, tickets, tasks, and payments with state pipelines |
| Subscriptions | recurring_plan, membership, loyalty_points | Recurring plans, memberships, loyalty balances |
| Submissions | feedback, comment, notification | Feedback, comments, and notifications — a moderation queue |
| Inventory | inventory | Stock levels, reservations, and adjustments |
The archetype grid shows how many of your project's schemas fall into each bucket. Selecting a schema opens a widget scoped to it; the sidebar lets you jump between every transactional schema in the project without going back to the grid.
Grouping is resolved automatically by walking each schema's extends chain up to a base service namespace — including multi-level chains, e.g. your own myapp:premium_order extending myapp:b2b_order extending order:base_order still resolves to Lifecycle records. There's nothing to configure.
Every record shown here is ordinary CRUD data underneath, addressable the same way from the API using the schema's namespace-qualified type:
http
GET https://api.supero.dev/api/v1/crud/acme-corp/myapp:salon_booking
Authorization: Bearer <jwt>ℹ️ Permission required: tenant:update
Opening /admin-panel/records (and its per-schema detail view) requires tenant:update, not tenant:list — a different, narrower permission than the Admin Panel landing page. See the role table below for who has which.
💡 No schemas showing up?
Manage Records only lists schemas that extend one of the 17 transactional base services. If your project doesn't have any yet, import a transactional service from the Services page and extend its base schema — the archetype it belongs to picks it up automatically.
Who Can Access What
The two pages are gated by different permissions, so access doesn't move in lockstep with seniority. Notably, tenant_admin can open Manage Records (it has tenant:update) but not the Admin Panel landing page itself (it lacks tenant:list) — in practice tenant_admin reaches records via the Manage records link inside another page or a direct URL.
| Role | Admin Panel (/admin-panel) | Manage Records (/admin-panel/records) |
|---|---|---|
| domain_admin | Yes | Yes |
| domain_user | Yes | No |
| project_admin | Yes | Yes |
| project_user | Yes | No |
| developer | Yes | No |
| tenant_admin | No | Yes |
| tenant_user | No | No |
| viewer | No | No |
platform_admin and platform_user (Supero-staff-only roles, not customer-assignable) have both permissions and can always reach either page.
The Same Panel, After You Deploy
The Admin Panel page is upfront about the fact that it's showing you a preview: the URL and feature grid you see in the console point at your project's current schemas plus whatever test data you've generated. When you deploy, your tenants get this exact panel — same UI, same feature set, same archetype grouping — now pointed at production data on real infrastructure, with each tenant's records isolated to that tenant.
That holds across all three deploy targets: Supero Cloud (one-click, hosted at *.supero.live), your own AWS or GCP account, and on-premise. You don't build or buy a separate back-office tool for your operators — the Admin Panel and Manage Records are already part of what ships.
Next steps
Related pages:
- •Access Control (RBAC) — the full role catalog and the object-level access_policy/access_rule layer that governs what a role can see and edit inside the records an operator opens
- •Transactional Services — the 17 backend primitives Manage Records groups by archetype, and how to extend their base schemas
- •Projects & Tenants — how the Domain → Project → Tenant hierarchy your tenant admin URL is derived from actually works
- •Cloud Deployment — deploying to Supero Cloud or your own AWS/GCP account, where your tenants' Admin Panel goes live
On this page