Skip to content
Flows
App Builder Intermediate · 45-90 minutes

Admin Dashboard

Build a real admin dashboard with live data tables, stats, filters, and actions that actually mutate data.

Start Route · 6 steps

The route

6 steps to Done

  1. 01

    Define admin scope and data

    Decide exactly what the admin manages so the dashboard is concrete, not decorative.

    Preview prompt + verify gate ▾

    Define the admin dashboard spec for this app. List: the entities admins manage (e.g. users, orders, content), the 4-6 stats that matter (with the exact query behind each), the table columns per entity, the row actions (view/edit/disable/delete) and what each changes in the database, and who counts as admin. Every stat and action must map to real data - no decorative metrics.

    • Entities to manage are listed
    • Each stat has a defined query
    • Each row action states its database effect
    • Admin access rule is defined
  2. 02

    Build admin layout and access control

    Stand up the admin shell and lock it down before adding data.

    Preview prompt + verify gate ▾

    Create the admin dashboard layout and protect it. Requirements: an /admin route with sidebar or tab navigation for each managed entity; access restricted to admin users (route guard AND backend enforcement on every admin endpoint - non-admins get 403); a visible 'access denied' experience for non-admins; loading skeletons for the shell. State how a user becomes admin in this app (flag on the user record) and create one admin account for testing.

    • Non-admin users cannot open /admin
    • Admin API endpoints reject non-admins with 403
    • A test admin account exists and works
  3. 03

    Implement real stats cards

    Stats must come from live queries so the dashboard tells the truth.

    Preview prompt + verify gate ▾

    Implement the stats row with real data. Requirements: each stat card runs its defined database query (counts, sums, recent activity); a backend endpoint returns all stats in one call; loading skeletons while fetching; an error state if the endpoint fails; numbers formatted sensibly. Prove correctness: create/change one record and show the affected stat updating on refresh.

    • Each stat matches a hand-checked database count
    • Adding a record changes the relevant stat
    • Loading and error states render properly
  4. 04

    Build the data table with search and filters

    The core admin surface: browse real records with search, filters, and pagination.

    Preview prompt + verify gate ▾

    Implement the main data table. Requirements: rows come from a paginated backend endpoint (server-side pagination); search box filters by the key text fields; at least two filters (e.g. status, date range) applied server-side; column sorting on at least two columns; empty state when no results; loading state on every fetch; error state with retry. Show total result count.

    • Search narrows results correctly
    • Filters combine with search
    • Pagination fetches new pages from the server
    • Empty and error states display
  5. 05

    Add working row actions

    Admin actions must mutate the database and survive refresh.

    Preview prompt + verify gate ▾

    Implement row actions on the table. Requirements: a detail view (drawer or page) showing the full record; edit with a validated form that persists changes; disable/enable or delete with a confirmation dialog; optimistic or refetch-based UI update after each action; visible success toast and error handling on failure. Every action must persist - verify by refreshing after each one.

    • Edits persist after a full refresh
    • Delete/disable asks for confirmation
    • Failures show a visible error, and the row is not silently wrong
  6. 06

    QA the dashboard end to end

    Verify truthfulness: stats, tables, and actions must reflect the database exactly.

    Preview prompt + verify gate ▾

    Run a full admin QA pass and report PASS/FAIL with evidence: stats match hand-checked queries; search+filter+pagination return correct sets; each row action persists after refresh; a non-admin is blocked from the UI and gets 403 from admin APIs; empty and error states render (test by clearing filters to nonsense and killing the network in devtools). Fix all failures and re-run.

    • All stats verified against direct queries
    • Actions persist across refresh
    • Non-admin block verified at UI and API level
    • All failures fixed and re-tested