Admin Dashboards

The boilerplate includes two admin dashboards: a platform-wide super admin and an organization-level admin for B2B workspaces.

Platform Admin Dashboard

Administrative user deletion schedules the existing GDPR worker and immediately suspends access. Shared Prisma commits suspension, queue request and administrative audit together, after rechecking the active administrator and the target's personal Account. Self-deletion, workspace ownership, another personal-Account member, billing bindings, external payment/subscription evidence or a license require the existing dedicated workflow. A failed deletion request requires review. Repeating an accepted request preserves its processing date; a pending future request is accelerated. This scheduling step does not call Auth or perform the later erasure.

Located at /admin-dashboard, accessible only to active platform admins. The shared authorization check requires is_admin=true and rejects disabled profiles or profiles scheduled for deletion.

User listing, statistics, detail and access-history reads each enforce the shared admin check in core/organizations/admin-user-queries.ts, independently of the layout. Self-action controls compare canonical application IDs, not Auth-provider subjects. Failed reads produce a generic error rather than an empty list, zero statistics or a falsely active user; a confirmed missing profile remains not-found. Only the profile fields needed by the actions are passed to their client component. These reads use shared Prisma; provider activation still requires the separate compatibility gates.

Organization listing and detail use shared Prisma with administrative authority rechecked in the database. Lists default to 50 organizations or 100 members per page; the ceilings and read deadline are owned by config/admin-organizations.ts. Pagination does not change the exact totals, member-limit controls or owner summary. The last 30 days of AI usage are aggregated in the database without truncating activity to 5,000 requests, and replaced subscriptions are excluded. List rows and global statistics share one snapshot; separate page requests may reflect intervening changes. Failed reads show an error rather than misleading empty results. Organization mutations and security-policy integration remain separate migration work.

Admin user creation retains recent-authentication step-up and checks the canonical administrator before provider creation and again before committing application data. The selected Auth adapter returns only a provider principal; explicit, idempotent finalization resolves its canonical application identity. A mapped incomplete identity stays pending until the existing consent and onboarding flow completes. Shared Prisma transactions perform the business preflight and atomically update the profile, assign any internal subscription and initial credits, and record the audit. Profile and personal-Account evidence must match. Administrative assignments are internal records, not proof of an external payment.

Auth creation and setup-link generation remain server-only provider operations outside database transactions. Creation is not a durable, automatically retried workflow: an ambiguous Auth response or a later failure can leave a native provider user and durable pending identity mapping. Failed business completion rolls back its profile, subscription, credit and audit changes together. Inspect the selected provider and centralized diagnostics before any manual retry. A successful response with setupEmailSent=false means provisioning completed but setup delivery did not. Provider calls have separate deadlines in config/admin-user-creation.ts; database transactions use the bounded shared runtime. Setup hashes, provider subjects and native objects never appear in HTTP responses or diagnostics. This executable path does not by itself certify a Database/Auth composition; the compatibility matrix remains blocking until its local-only evidence is complete.

Auto-Admin Assignment

Layouts and API routes use the shared platform-admin authority check:

• Requires a provider-verified email matching the active application identity and app_settings.admin_email
• Promotes only an enabled profile without a scheduled deletion; existing active administrators retain access without an email match
• Commits the promotion and its audit together through shared Prisma; an audit failure leaves the profile unchanged
• Rechecks administrator access before loading the profile and a bounded list of manageable workspaces

Dashboard Pages

The billing reconciliation page is an investigation and audit surface, not a payment-control console. See the Payment Support & Reconciliation runbook before acknowledging or resolving an issue.

KPI Performance

Dashboard queries are optimized for performance:

• Server Component pages render pre-aggregated data from core/admin/* modules instead of inlining service-role query orchestration
• Parallel database queries with Promise.all (9 queries in parallel)
• MRR/ARR calculation from pricingConfig (code-based, not DB)
• Efficient counting with count: 'exact', head: true
• Explicit projections such as select('id') or select('amount') instead of select('*') for production queries
• The isolated app_platform_admin Prisma connection reads only the platform-wide projections granted to its bounded capability

Admin Dashboard Design System

The admin dashboard follows a Data-Dense Dashboard design pattern optimized for information density and at-a-glance insights. The design uses shadcn/ui components with Tailwind CSS v4 theme tokens.

Organization Admin Dashboard

Located at /org-dashboard, accessible to workspace owners and admins.

Pagination

Tables include reusable pagination controls:

• Rows per page selector (5, 10, 20, 50)
• Page navigation (first, previous, next, last)
• "Showing X to Y of Z entries" display
• Page indicator (Page X of Y)
• Independent pagination state per table

Shared Dashboard Context

The private and organization dashboards share request-level context helpers in core/accounts/dashboard-context.ts. They use React.cache() to deduplicate repeated auth/account reads between a layout and its child page during one request.

Both contexts return a server-only canonical actor. Shared Prisma reads profile, memberships and billing facts in one read-only transaction scoped to actor.appUserId; the Auth provider subject is not a fallback. Failed or malformed profile, membership, invitation, billing and member-count receipts raise a generic dashboard error instead of empty or zero results.

Workspace enumeration uses workspaceConfig.dashboard.membershipPageSize (100 by default) and maxMemberships (1,000 by default). It reads in ascending Account ID order until an empty page, including after short pages. Exceeding the configured bound fails rather than presenting a partial selector. The writable active-account cookie selects only a workspace the current actor manages; a missing, stale or foreign selection falls back to the first verified workspace. Profile, presentation memberships and access facts share a repeatable-read snapshot. The exact organization member count is read separately after rechecking manager authority.

The private context uses the same enumeration bounds for personal and workspace memberships. Its account cookie prioritizes an authorized membership for billing access; the selected Account supplies credits, subscription and content scope together. Menu visibility uses one current active/trialing subscription per Account or more than one member, with counts capped at two and returned with each page. Replaced subscriptions do not make an empty workspace visible. Access uses the shared subscription policy, immutable paid entitlements and license validity from the snapshot, without extra billing requests.

Pending invitation lookup requires a verified actor email and returns only a validated, unexpired pending token. Its private SQL capability also checks the active canonical email and verified identity under an active issuer, because an invited recipient may not yet belong to the workspace. An unverified email cannot trigger admin-email auto-promotion; an existing platform-admin profile remains authoritative. Admin-authority failures retain the non-admin fallback.

Both shells receive email and persisted profile display fields, not native Auth metadata or provider identifiers. The persisted full_name remains the display-name fallback when first/last name are absent; missing profile values use the existing email/default-avatar presentation. Native RLS, target-member Auth activity and each Database/Auth composition require their own local evidence before certification. Auth unavailability fails through the current provider-session boundary and never becomes an application identity fallback.

These helpers are not static caches. Both use getCurrentActor() and remain request-scoped protected dynamic reads. Layouts and pages still own redirects: unauthenticated users go to login, users without org-manager membership go back to /private-dashboard, and B2B workspaces without access go to pricing.

The member detail page reads the last sign-in through core/organizations/member-auth.ts. An actor-scoped Prisma transaction checks manager authority and target membership, then resolves the stored provider coordinate through the selected Auth adapter. Missing or ambiguous evidence leaves the timestamp unavailable; an application UUID is never guessed to be a provider subject. Auth metadata and user-global access logs are not exposed. This implementation path does not by itself satisfy the composition-specific local certification.

Organization Dashboard Performance

Organization dashboard analytics and member usage stats are pre-aggregated in SQL instead of loading raw usage rows into the page component. Keep this boundary when adding new dashboard cards:

• core/accounts/dashboard-usage.ts wraps the aggregate readers used by the private dashboard overview, org overview, org analytics, member list, and member detail pages.
• get_org_dashboard_analytics returns 30-day KPIs, previous-period comparisons, daily usage, top members, model/agent breakdowns, active users, latency, and success rate for /org-dashboard/analytics.
• get_org_member_usage_summary returns per-member request count, token total, cost, last AI activity, and chat-session count for member list/detail screens.
• get_account_dashboard_usage_summary powers lightweight overview counters without downloading ai_requests or chat_sessions.
• Supporting indexes cover ai_requests(account_id, user_id, created_at desc), chat_sessions(account_id, user_id, created_at desc), and user_access_logs(user_id, created_at desc).