Admin Dashboard Prompts: 10 Briefs for Metrics, Roles and an Audit Log, Each Tied to a Channel
An admin dashboard prompt on this page is a brief for one surface of an internal admin tool, written to a database that already exists: the Internal Admin Dashboard kit ships a user_roles table with admin and member roles and no insert policy at all, an events table with no update or delete policy, a has_role() helper, and an aggregate function that is deliberately not SECURITY DEFINER so a member's chart counts only the member's rows. Its seven verification queries were executed as a member and then as an admin, and the member results are the proof. The ten briefs below assume those tables and never recreate them.
They are ordered the way a team operating a product would build: the route gate, then the overview, then the event log viewer, then user management. Moderation, view-as-user, saved reports, alerts, a table editor and an activation funnel come after, each reading what the earlier briefs wrote. Every brief has a Data Rules section before its screens, because on Lovable the prompt is where the policy gets decided, and every Pro variant names the channel it serves.
The “Try in Lovable” links on this page are affiliate links: we may earn a commission if you create an account through one. It costs you nothing and does not change which prompts are here.
Roles Table and the Admin Route Gate
What this prompt is for
The dashboard's foundation: roles in their own table, read per request from the database, an admin route that redirects members, and a first admin granted from SQL rather than a button.
When to use it
First, on an empty project, after running the Internal Admin Dashboard kit's schema.sql. Every other dashboard brief assumes the role check exists.
# Context Build the access layer of an internal admin dashboard for [the team running the product]. The database already exists from the Internal Admin Dashboard kit: a user_roles table with admin and member roles and no insert policy, and an append-only events table. Do not recreate them. The rule of the whole dashboard: the role is read from the database on every request, never from client state
Channel-Optimized Pro Version
This prompt has a Pro version optimized for Product-led Growth. Unlock to get product-channel fit guidance and distribution-ready features.
Metrics Overview from Windowed Views
What this prompt is for
The overview page: sign-ups, active users, events and revenue placeholders, each with a window, computed by database views and functions, with zero and unknown told apart.
When to use it
After the gate exists. This is the page the team opens every morning.
# Context Build the metrics overview of the admin dashboard. Every metric has a window (today, 7 days, 30 days) and is computed in the database by a view or a function that respects the caller's role, like the kit's event_counts_by_day(). A metric that cannot be computed shows "unknown", never zero. ## Data Rules - Aggregates are views or functions with a window parameter; no client-side arithmet
Channel-Optimized Pro Version
This prompt has a Pro version optimized for Community-led Growth. Unlock to get product-channel fit guidance and distribution-ready features.
Append-Only Event Log Viewer
What this prompt is for
A viewer for the kit's events table: filters by user, name and time, a detail pane, CSV export for admins, and no path to edit or delete a row.
When to use it
Once the app writes events. The kit's events table has no update or delete policy; this brief is the surface that makes the log useful.
# Context Build the event log viewer of the admin dashboard on the kit's events table. Events are append-only: there is no update or delete policy, and this brief adds none. An admin sees every event; a member sees their own, because the policies say so, and the viewer must not pretend otherwise. ## Data Rules - Reads go through the existing policies; the viewer adds no function that bypasses the
Channel-Optimized Pro Version
This prompt has a Pro version optimized for B2B Sales. Unlock to get product-channel fit guidance and distribution-ready features.
User Management with Audited Role Changes
What this prompt is for
Admin pages for users: search, detail, role change through a function that writes an event, disable and re-enable, and never an insert into user_roles from the client.
When to use it
When a second admin joins or the first support request arrives. Builds on the gate brief's read-only roles page.
# Context Build user management for the admin dashboard. Admins can find a user, see their role and recent events, change their role through a server function that records the change, and disable an account. The kit's user_roles table has no insert policy; role changes go through a function that updates an existing row or is refused. ## Data Rules - change_role(user, new_role, reason): admin only
Channel-Optimized Pro Version
This prompt has a Pro version optimized for Product-led Growth. Unlock to get product-channel fit guidance and distribution-ready features.
Moderation Queue with Recorded Decisions
What this prompt is for
A queue of flagged items with approve, reject and escalate, each decision recorded with who and why, and a per-moderator throughput view.
When to use it
When users can post content and someone has to review it. Builds on the gate and event log briefs.
# Context Build a moderation queue for the admin dashboard. Items enter the queue by a flag from users or a rule; a moderator with the admin role takes an item, decides, and the decision is recorded as an event. Nothing in the queue is deleted; rejected items are hidden by a status the app respects. ## Data Rules - flags: item, reason, by, created_at; moderation_decisions: item, decision, by, rea
Channel-Optimized Pro Version
This prompt has a Pro version optimized for Community-led Growth. Unlock to get product-channel fit guidance and distribution-ready features.
Read-Only View-as-User for Support
What this prompt is for
A support mode where an admin sees the app as one user, read-only, with a visible banner, a time limit and an event written on start and end.
When to use it
When support tickets say 'it looks wrong for me' and screenshots are not enough. Builds on the gate brief.
# Context Add a read-only view-as-user mode to the admin dashboard. An admin starts a session for one user with a reason; for 15 minutes the app renders that user's data through a server-side context, every write is blocked, a banner is visible on every screen, and the start and end are events. ## Data Rules - view_sessions: admin, target user, reason, started_at, ended_at; created by a function,
Channel-Optimized Pro Version
This prompt has a Pro version optimized for Product-led Growth. Unlock to get product-channel fit guidance and distribution-ready features.
Saved Reports with Scheduled Export
What this prompt is for
Report definitions an admin saves: a view, a window and filters, rendered on demand and exported on a schedule to a private bucket, with the definition versioned.
When to use it
When the same questions get asked every Monday. Builds on the metrics brief's views.
# Context Add saved reports to the admin dashboard. A report is a named definition: which view or function, which window, which filters. It renders on demand, exports on a schedule, and every change to the definition is versioned so a report from March can be re-run as it was. ## Data Rules - reports: name, definition (JSON), owner, created_at; report_versions: report, definition, saved_at, by -
Channel-Optimized Pro Version
This prompt has a Pro version optimized for B2B Sales. Unlock to get product-channel fit guidance and distribution-ready features.
Metric Alerts with Thresholds and a Digest
What this prompt is for
Rules on metrics: a view, a comparison and a threshold, evaluated by a scheduled function, with in-app alerts, a digest, and a record of every firing.
When to use it
When someone should know before they open the dashboard. Builds on the metrics and saved reports briefs.
# Context Add alerts to the admin dashboard. An alert rule names an allow-listed metric, a comparison (above, below, change over a window) and a threshold; a scheduled function evaluates every rule, writes an alert_fired event when one crosses, and shows it in-app until acknowledged. ## Data Rules - alert_rules: name, metric (allow-listed), comparison, threshold, window, owner, enabled - alert_fi
Channel-Optimized Pro Version
This prompt has a Pro version optimized for Email Marketing. Unlock to get product-channel fit guidance and distribution-ready features.
Admin Table Editor with Audit and Soft Delete
What this prompt is for
A generic admin editor for named tables: list, edit, create and soft delete, every change written as an event with the before and after values, and columns marked read-only by config.
When to use it
When admins need to fix data without SQL. Builds on the gate and event log briefs; the tables it edits are named in a config, never discovered at runtime.
# Context Add a table editor to the admin dashboard for a named list of tables. Each table in the config declares its editable columns, read-only columns, and whether soft delete is allowed. Every edit is written as an event with the row id, the column, the old value and the new value. ## Data Rules - The config is code: table name, columns, editability, soft-delete column; nothing is discovered
Channel-Optimized Pro Version
This prompt has a Pro version optimized for Email Marketing. Unlock to get product-channel fit guidance and distribution-ready features.
Activation Funnel from Events
What this prompt is for
A funnel from sign-up to activation defined as named events in order, computed per cohort week by a function, with the drop-off step highlighted and the users behind it listable.
When to use it
Once the app writes a handful of named events. This is the chart that decides what to build next.
# Context Add an activation funnel to the admin dashboard. The funnel is an ordered list of event names, defined by an admin, with sign-up as the first step and the activation event as the last. A function computes, per sign-up cohort week, how many users reached each step, respecting the caller's role. ## Data Rules - funnels: name, steps (ordered event names), owner; computed by a function with
Channel-Optimized Pro Version
This prompt has a Pro version optimized for Product-led Growth. Unlock to get product-channel fit guidance and distribution-ready features.
Every Prompt, Every Kit, One Payment
All 10 prompts plus every Pro variant and build kit in one bundle, plus unlimited prompt generation, $199 once. Or sign up free to copy prompts one at a time.
Browse More Categories
Related Resources
The Complete Lovable Bundle
$199 once. Unlimited generation, every prompt, every kit, every future dropEvery prompt, every Pro variant, all four build kits and every future drop, in one Notion workspace. One payment, never a subscription.
Get the 151-Prompt BundleWhich growth channels do these prompts serve?
Every prompt in this category carries a distribution section naming the channel it is built for, so the generated app has a way of being found rather than only a feature set. The chart counts primary and secondary coverage together, computed from the prompt bodies when the site is built.
| Category | prompts |
|---|---|
| B2B Sales / LinkedIn | 6 |
| Email Marketing | 6 |
| Product-led Growth | 5 |
| Community-led Growth | 3 |
Computed from the channel mapping in each prompt at build time; a prompt can serve more than one channel.
What does the dashboard kit's schema give these prompts?
Two tables, one helper, one aggregate and three refusals. Roles live in their own table rather than as a column on a profile row, which is what lets the read policy differ from the write policy: a member reads their own role row, an admin reads all, and nobody inserts, because there is no insert policy and the first admin is granted from the SQL editor by a commented statement. Events are inserted by the acting user, read by the owner or an admin, and never updated or deleted. The has_role() function is SECURITY DEFINER so a policy on user_roles can call it without recursing; event_counts_by_day() is not, so it counts only what the caller may see.
| From the kit | Added by the briefs | |
|---|---|---|
| Tables | user_roles (enum app_role), events with severity and payload | invites, profiles, flags, moderation_decisions, view_sessions, reports, alert_rules, alert_firings, funnels |
| Roles | No insert policy; first admin granted from SQL | Role changes only through change_role(), with a reason, an event, and two refusals: last admin and self |
| Events | Insert as yourself; read own or all as admin; no update, no delete | A viewer that adds no bypass, an export that re-checks the role, corrections as new events |
| Aggregates | event_counts_by_day() not SECURITY DEFINER; query 5 catches the mistake | Windowed views, funnels and alert rules that keep the same property |
| Proof | Seven queries, five as a member, two as an admin | Each brief's safeguard names the policy it must not weaken |
Lovable's own admin panel guide, read on 26 September 2026, makes the same case for the database layer and adds the failure most builders hit first: "a table with RLS enabled but no policies configured will silently return zero rows". The kit's verification query 1 is a member reading events and expecting rows, so an empty result is caught before a page is built on it. The briefs extend the schema with invites, profiles, flags, view sessions, reports, alert rules and funnels, and each names the refusal its function enforces.
How is an admin dashboard brief in this library built?
The one to read is the roles and gate brief, because every other brief assumes it and because its Data Rules section states the dashboard's one rule: the role is read from the database on every request, never from client state. Its Core Features put the guard before any screen, and its Safe-Guard section refuses the three shortcuts Lovable will offer when a page fails to render for a member: an insert policy on roles, a CSS-only hide, and a weakened policy.
- Context: The operators, the kit's tables, and the rule that the role is read per request.
- Data Rules: Server-side role helper; no role trusted from the browser; first admin from SQL.
- Core Features (Priority Order): Sign-in redirect, shell, badge, roles list, health line.
- Screens & States:
- Build Order:
- Safe-Guard Instructions: No insert policy on roles; no CSS-only hiding; no policy weakened to render a page.
- Before Building: Ask, then save to knowledge, then build.
Headings read from the prompt body of ad-roles-and-gate in this library.
The Before Building line is the same as the rest of the library: Lovable asks its questions first and saves the decisions to project knowledge. On the SaaS foundation run that closer produced four questions and a self-tested invite flow; a dashboard brief's questions will be about who the operators are and what they check each morning, which is exactly what should be decided before the schema is extended.
What is the operator loop these briefs build?
Open the overview, read four windowed numbers and the events-per-day chart, look at the alert tray, open the log for anything that fired, find the user, fix the row or change the role with a reason, and let every step write an event. Five of the ten briefs exist to make that loop faster than the Supabase table editor: the overview from views, the log viewer with filters in the URL, user management with audited changes, alerts that fire on computed values only, and the table editor whose config excludes the two protected tables.
- Overview: windowed numbers
- Alert tray: computed values only
- Event log: filter in the URL
- User detail: role change + reason
- Event written: who, what, why
The Core Features sections of the overview, alerts, event log and user management briefs, condensed.
The other five make the loop survive a second admin and a first support ticket: moderation with recorded decisions and no self-review, view-as-user that reads through a filtered context and blocks every write, saved reports mapped to an allow-list, the activation funnel that names the step where users leave, and the gate that all of it sits behind.
Which admin dashboard brief to use
Start with Roles Table and the Admin Route Gate on top of the kit's schema; nothing else works without it. Then Metrics Overview, then the Event Log Viewer, then User Management. That is a working admin tool for one operator.
Add the Moderation Queue when users can post, View-as-User when support tickets say "it looks wrong for me", Saved Reports when the same questions arrive every Monday, and Metric Alerts when someone should know before they open the dashboard.
The Table Editor and the Activation Funnel come last: the editor because it should not exist before the audit log does, and the funnel because it needs a few weeks of named events to say anything.
Suggested build order
Gate, then the read surfaces, then the write surfaces, then the loops that read history. Each brief names the tables it adds and the function that is the only writer, so the order is the order the functions depend on each other.
The gate on the kit's schema
Role read per request; first admin from SQL.
Prompt: Roles Table and the Admin Route Gate
Overview from windowed views
Zero and unknown told apart; no SECURITY DEFINER.
Prompt: Metrics Overview from Windowed Views
The append-only log viewer
No bypass function; export re-checks the role.
Prompt: Append-Only Event Log Viewer
Audited role changes
Reason required; last admin and self refused.
Prompt: User Management with Audited Role Changes
Then the loops that read history
Alerts, reports and the funnel, once there are events to read.
Prompt: Metric Alerts with Thresholds and a Digest
Where admin dashboard prompts usually go wrong
- Asking for an admin dashboard in one sentence. The result is a page with a menu item that only renders for admins, and a member who types the URL gets the data. A hidden menu item is not access control; the kit's policies are, and the briefs put the guard before the screens.
- A role column on the profile row. If a user can edit their profile and the role lives on it, they can edit their role. The kit keeps roles in their own table with no insert policy, and the briefs route every change through a function with a reason.
- Adding SECURITY DEFINER to make a chart work. The chart starts showing every user's events to every user. The kit's verification query 5 catches it; the overview brief forbids it.
- An editable event log. A log that can be rewritten is not a log. The kit has no update or delete policy on events, and the log viewer brief refuses to add one even for a typo; corrections are new events.
Frequently asked
Do I need the Internal Admin Dashboard kit to use these prompts?↓
The briefs assume its two tables, its helper and its policies, so yes for the first one: run schema.sql, grant yourself admin from the SQL editor, and run verify.sql as a member before pasting the gate brief. The prompt is free to download; the schema and verification files ship in full with the bundle. Without the kit, tell Lovable to create the same tables with the same rules, and run the seven queries yourself before building further.
Why is the role in its own table?↓
Because the read policy and the write policy on a roles table need to differ, and a column on a user-editable profile row cannot do that. In the kit a member reads their own role row, an admin reads all, and nobody inserts from the client. The first admin is a commented SQL statement, deliberately not an endpoint.
Which of these prompts have been run?↓
None of the ten on a dashboard project yet. The rule pattern they encode was run: the SaaS foundation prompt built roles and invites with policies checked in the database for 10.4 credits, and the kit schema executes with its verification queries passing as a member and as an admin. The category page says which briefs carry a measured run the day one exists.
What happens if RLS is on but a policy is missing?↓
The query returns nothing and no error, which Lovable's own admin panel guide names as the thing to watch for. The kit's first verification query is a member reading events and expecting their own rows; an empty result there means a policy is missing, not that the log is empty. The briefs treat unknown and zero as different values for the same reason.
Can the digests, alert emails and owner notifications send on the free plan?↓
Not per Lovable's docs read on 26 September 2026: app emails need a paid plan and a verified email domain. The alerts, saved reports, table editor and funnel briefs say so and deliver the digest as the in-app tray or an export until both exist, so the first build does not fail silently.
How does this differ from the backend logic prompts?↓
The backend logic category is the primitives: schema, RLS, functions, jobs. This category is one product built from them for the people who run an app. A founder who wants to see what is happening today runs the kit and these ten; one who wants to sell a dashboard to other teams runs the SaaS foundation first and these ten inside a workspace.
Related reading
- Internal Admin Dashboard kit
The schema, policies and seven verification queries the briefs assume.
- backend logic prompts
The primitives: schema, RLS, functions, jobs.
- CRM app prompts
The sibling category on the CRM kit's schema.
- Lovable SaaS prompts
The machinery for selling the dashboard to other teams.
- Lovable and Supabase
The silent empty result and the missing with-check clause.
- Lovable security
What the scans prove and what only a query as a member does.
- build a SaaS
Foundation, schema, proof, billing.
- SaaS ideas
The dashboard as a chargeable product.
- app ideas
Fifty ideas read from this library, grouped by channel.
- first 100 users
The channels the Pro variants name.
- free build kits with tested RLS
The four kits, counted.
Sources
All checked on 26 September 2026.
Updated .
Written by
Marco Kohns
Founder of ProtoBites - Venture Growth Studio
Growth PM at a Silicon Valley scale-up (a16z and General Catalyst backed), ex-Techstars where he consulted 13 early-stage startups, Reforge-trained. Every prompt on this site comes out of shipping ProtoBites' own portfolio products.
Help shape this product
We're building this in public and your input genuinely matters.
If something felt confusing, missing, or especially useful, I'd love to hear about it. It takes ~30 seconds and helps me improve the parts that matter most.
Share quick feedbackGoes straight to the builder. No marketing questions. No auto-replies.