Admin Dashboard Prompts for Lovable: 10 Briefs on a Roles Table
Prompt builder · four steps · no account
Step 1 of 4
Which one is closest?
Building something else? Describe it to the AI generator
An admin dashboard asked for in one sentence is a menu item that only renders for admins, and a member who types the URL gets the data. These 10 briefs are written to a schema that already exists and was proven: a roles table nobody can insert into from the client, an append-only event log, and an aggregate that counts only what the caller may see. This page shows the schema, the operator loop, and what the first run will record.
By Marco Kohns · Prompts written and run by us
Short answers
Short answers
Where do I start?
Run the Internal Admin Dashboard kit's schema, grant yourself admin from the SQL editor, run verify.sql as a member, then the roles and gate brief. Nothing else works without the gate.
Pick by situation →What does a run cost?
? credits
Not measured for an admin brief yet. The closest measured run, the SaaS foundation with roles checked in the database, cost 10.4 credits; a brief on an existing schema should cost less.
See what we do know →Why is the role in its own table?
Because the read and write policies on roles have to differ, and a column on a profile row the user can edit cannot do that. A member reads their own row, an admin reads all, nobody inserts from the client.
The kit's three refusals →My admin page already exists
Then type its URL as a member. If the data shows, the menu was hidden and nothing was gated. The fix lines below put the guard before the screen without a rebuild.
Fix lines for live apps →10
Admin Dashboard prompts in this category
↳ Copy-paste, free
0of 10
Prompts from this category run in Lovable
↳ Next run: Roles Table and the Admin Route Gate
3runs
Measured so far across the library
↳ 1.8 to 10.4 credits each
0
Upvotes since Jan 2026
↳ One per visitor, self-reported
Data basis: no brief run on a dashboard project yet; every card says so. The policy claims come from the Internal Admin Dashboard kit, whose seven verification queries were executed as a member and then as an admin. The scan findings come from one session on 26 September 2026 in Marco's own workspace, and the credit figures from the three measured runs elsewhere in the library. Docs checked 22 October 2026.
Find a prompt
Which surface of the admin tool are you building?
Cards are sorted by build order. Each says whether we ran it in Lovable, and if not, shows a question mark instead of a guess.
Showing 10 prompts
- Step 1 · Gate
Roles Table and the Admin Route Gate
The access layer of an internal admin dashboard, where the role is read from the database on every request and the first admin is granted only by SQL.
Run it when: first, on the kit's schema, before any admin screen exists.
Not run yet · credits ?Pro version adds the growth-channel instructionsUnlock - Step 2 · Read
Metrics Overview from Windowed Views
An admin metrics overview with 4 windowed cards and an events chart, computed by database views that respect the caller's role and show Unknown apart from zero.
Run it when: operators open something each morning and need four numbers and a chart.
Not run yet · credits ?Pro version adds the growth-channel instructionsUnlock - Step 2 · Read
Append-Only Event Log Viewer
A viewer for the append-only events table with filters kept in the URL, a payload detail pane, admin-only CSV export, and no path to edit or delete.
Run it when: something fired and someone has to find out what, with filters in the URL.
Not run yet · credits ?Pro version adds the growth-channel instructionsUnlock - Step 3 · Write
User Management with Audited Role Changes
Admin user management where role changes go through one function that needs a reason, writes a role_changed event, and refuses to demote the last admin.
Run it when: an admin has to change a role, with a reason, and the change must be audited.
Not run yet · credits ?Pro version adds the growth-channel instructionsUnlock - Step 3 · Write
Moderation Queue with Recorded Decisions
A moderation queue where moderators claim items for 15 minutes, decide with a required reason, and rejected content is hidden by status and kept for appeal.
Run it when: users can post and every decision should be recorded, with no self-review.
Not run yet · credits ?Pro version adds the growth-channel instructionsUnlock - Step 3 · Write
Admin Table Editor with Audit and Soft Delete
An admin table editor driven by a code config, where every edit writes an event with old and new values and user_roles and events stay uneditable.
Run it when: the audit log exists and the Supabase table editor is too blunt for support.
Not run yet · credits ?Pro version adds the growth-channel instructionsUnlock - Support
Read-Only View-as-User for Support
A 15-minute read-only view-as-user mode for support, with a persistent banner, a required reason, and a sessions list the viewed user can see.
Run it when: a ticket says it looks wrong for me and nobody can see what they see.
Not run yet · credits ?Pro version adds the growth-channel instructionsUnlock - History
Saved Reports with Scheduled Export
Saved admin reports defined as data over allow-listed views, versioned on every save so an old report re-runs as it was, with scheduled CSV export.
Run it when: the same questions arrive every Monday.
Not run yet · credits ?Pro version adds the growth-channel instructionsUnlock - History
Metric Alerts with Thresholds and a Digest
Metric alert rules evaluated every 15 minutes by a scheduled function, with an in-app tray, acknowledgements kept in history, and a morning digest.
Run it when: someone should know before they open the dashboard.
Not run yet · credits ?Pro version adds the growth-channel instructionsUnlock - History
Activation Funnel from Events
An activation funnel from ordered event names, computed per sign-up cohort week in the database, with the biggest drop-off named and its users listed for admins.
Run it when: a few weeks of named events exist and the question is where users leave.
Not run yet · credits ?Pro version adds the growth-channel instructionsUnlock
Building the whole admin tool? The bundle has all 10 as one kit in build order, with every Pro version unlocked, plus 142 more prompts.
See what is in the 152-prompt bundleDisclosure: if you create a Lovable account through links on this page, we may earn a commission. It costs you nothing and does not change what we recommend.
Measured run
No admin brief has been run yet. This is what the first run will record.
▍Context
Build the access layer of an internal admin dashboard for the team running the product. The app's backend already has the Internal Admin Dashboard kit: a user_roles table with admin and member roles and no insert policy, the has_role function, and an append-only events table; do not recreate them. The rule for the whole dashboard: the role is read from the database on every request, never from client state.
▍Data Rules
▍Core Features
1. Sign-in with the built-in auth; a signed-out visit to any /admin route redirects to sign-in and returns there afterwards
2. The /admin shell: sidebar, header with the signed-in user and role, and a "Not authorised" page for members that names the role needed
3. A role badge rendered from the server-read role
4. An admin-only /admin/roles page listing users and roles, read-only for now
5. A health line on /admin: database reachable, and the events row count for the last 24 hours
▍Safe-Guard Instructions
- Never add an insert policy to user_roles; a self-service role grant is a privilege escalation
- Admin content is gated by the server; a CSS or client-side check alone is never enough
▍Distribution hooks · Pro
Locked. The Pro version adds the growth-channel instructions for this screen.
- 01
A fresh project in Marco's own workspace, backend enabled
Balance read and screenshotted first. The kit's schema.sql run in the SQL editor, the first admin granted by the commented statement, verify.sql run as a member and then as an admin.
- 02
The brief pasted unedited, in Build mode
Its Context line says the tables exist and the role is read per request. Its Before Building line should make Lovable ask who the operators are and what they check each morning.
- 03
Every question recorded, with the answer given
On the SaaS foundation run the same closing line produced 4 questions. The count goes on the card.
- 04
The three shortcuts refused, on the record
When a page fails to render for a member, Lovable will offer an insert policy on roles, a CSS-only hide, or a weakened policy. The brief forbids all three; the run notes whether it offered any.
- 05
The Security view scanned, free
On the foundation project the chat said the dependencies were clean while the Security view listed 2 high-severity advisories. The view is read, never the chat.
- 06
Balance read again
Credits before minus after, to one decimal, daily credits counted first. Then the row goes into the runs file this page reads.
Credit math
What an admin brief is likely to cost, from the runs we have
No figure for an admin brief yet. The nearest measured run provisioned a backend and roles for 10.4 credits; a brief that builds on tables the kit already created does less work, and Lovable bills Build mode on the work done.
| Plan | Daily build credits | The nearest measured run (10.4) | Unused credits |
|---|---|---|---|
| Free | 5 a day, max 30 a month | Two days of daily credits plus 0.4 of a third, if a brief costs what the foundation did. The kit's SQL and the scans cost no build credits. | Daily credits do not roll over |
| Pro | 5 a day, plus 100 monthly plan credits from $25 | 5 from the day's credits, the rest from plan credits, on a fresh day | Plan credits roll over, expire after 2 months |
| Business | 5 a day, plus 100 monthly plan credits from $50 | Same split as Pro | Same as Pro |
Lovable's own examples, for scale
- “Add authentication”
- 1.20
- Asking the chat for a security scan (our run)
- 1.30
- Deep scan from the Security view
- 0.00
- Running schema.sql in the SQL editor
- 0.00
Sources: Lovable docs, Credits and usage (illustrative) and Security view; the 1.3 is our own reading from the billing page, 26 September 2026. Checked 22 October 2026.
Three ways to spend less
- Grant the first admin from SQL. The kit's commented statement does it in the SQL editor for no build credits. Asking Lovable to build an endpoint for it costs a message and creates the hole the briefs refuse.
- Scan from the Security view, never from the chat. Both scans are free there. The chat message that asks for one is billed and cannot start the Deep scan.
- Keep the aggregate function off SECURITY DEFINER. The shortcut makes a member's chart work by showing every user's events. The kit's query 5 catches it; fixing it later is a rebuild of the overview.
Start here
Which admin dashboard brief should you run first?
Pick the sentence that sounds like your project.
A working admin tool for one operator, in four briefs
- 01Roles Table and the Admin Route Gate · role read per request, first admin from SQL
- 02Metrics Overview from Windowed Views · four windowed numbers, zero told apart from unknown
- 03Append-Only Event Log Viewer · filters in the URL, export re-checks the role
- 04User Management with Audited Role Changes · role changes with a reason, audited
Build order
Four steps. Gate, read surfaces, write surfaces, history.
01
Gate
Roles table · Route guard
The role read from the database on every request. The first admin from SQL, never an endpoint.
02
Read
Overview · Event log
Windowed views and an append-only log with no bypass function.
03
Write
Users · Moderation · Table editor
Every change through a function with a reason, every change an event.
04
History
Reports · Alerts · Funnel
Loops that read the events, once there are events to read.
Anatomy
What each section of an admin brief does
| Section | What it tells Lovable | What you get without it |
|---|---|---|
| Context | Who operates the tool, that the kit's tables exist, and the one rule: role read per request | A role cached in client state at sign-in |
| Data rules | A server-side role helper; no role trusted from the browser; first admin from SQL | An insert policy on roles, which is an endpoint for granting yourself admin |
| Core features | The guard before the shell, the shell before any screen | Admin content painted before the role is known |
| Screens & states | Three shells, a loading state that paints nothing, a not-authorised page that names the role needed | A member who sees the data by typing the URL |
| Safe-guards | No insert policy on roles; no CSS-only hiding; no policy weakened to render a page | The three shortcuts Lovable offers when a member's page is empty |
| Before building | Ask who the operators are and what they check each morning | A dashboard of numbers nobody decides from |
A one-sentence admin prompt gets you
- A hidden menu item instead of a gate
- A role column on a profile row the user can edit
- An editable event log
- A chart that works because SECURITY DEFINER showed everyone's rows
A brief from this page gets you
- A role read from its own table on every request
- Refusals a member can see and screenshot
- Corrections as new events, never edits
- An aggregate that counts only what the caller may see
Fixes
Where admin dashboard prompts go wrong, and the line that fixes it
Already built an admin page that only hides the menu? Paste the fix line into your existing project.
Symptom
A member types /admin and sees the data
Cause: the prompt asked to show the menu item to admins only; nothing gated the route or the query.
Fix line
Read the signed-in user's role from the user_roles table on every request through one server-side helper. Protect every /admin route and every admin query with it. Members get a not-authorised page that names the role needed. Do not rely on hiding navigation.
Symptom
A user changed their own role
Cause: the role lives on the profile row and the profile is editable.
Fix line
Move roles into their own user_roles table with no insert policy from the client. A member reads only their own row, an admin reads all. Role changes happen only through a change_role function that requires a reason, refuses the last admin and refuses self, and writes an event.
Symptom
The members' chart shows everyone's events
Cause: SECURITY DEFINER was added to the aggregate function to make the chart render.
Fix line
Remove SECURITY DEFINER from event_counts_by_day so it runs as the caller and row-level security applies. A member's chart counts only the member's rows. Then show me the function run as a member and as an admin with different totals.
Symptom
An event was edited to fix a typo
Cause: the events table has an update policy, so the log is a document.
Fix line
Remove update and delete policies from events. Corrections are new events that reference the original. The log viewer renders both and never offers an edit action.
The Complete Lovable Bundle
All 10 admin briefs in build order, plus every other prompt
Every prompt and kit, every Pro version unlocked. One payment, no subscription.
One payment. No subscription, no renewal, ever.
FAQ
Questions about Admin Dashboard prompts
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 in the SQL editor under More > Database > Manage, grant yourself admin with the commented statement, and run verify.sql as a member before pasting the gate brief. The prompt is free; 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.
Does Lovable have an admin dashboard feature?+×
Its docs describe the workspace dashboard, which is Lovable's own home screen and shows for this search by accident. For an admin area inside your app, the prompt library has a one-line entry, create an admin-only analytics area that only admins can open, and a roles entry with admin, editor and viewer. Neither says where the role is stored or read, which is what the gate brief decides.
What happens if row-level security is on but a policy is missing?+×
The query returns nothing and no error. Lovable's own admin panel guide names that as the thing to watch for, and the kit's first verification query is a member reading events and expecting their own rows, so an empty result there means a policy is missing, never that the log is empty. The briefs treat unknown and zero as different values for the same reason.
Which of these prompts have been run?+×
None of the 10 on a dashboard project yet. The rule pattern they encode was run: the SaaS foundation prompt built roles checked in the database for 10.4 credits, and the kit's schema executes with its seven verification queries passing as a member and as an admin. The scans shown above ran on that foundation project.
Can the alert and digest emails send on the free plan?+×
Not per Lovable's prompt library page: 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.
How does this differ from the backend logic prompts?+×
The backend category is the primitives: schema, access rules, functions, jobs. This category is one product built from them for the people who run an app. A founder who wants to see 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.
Do the security scans check the gate?+×
Partly. Lovable's docs say the Quick scan runs on every publish and checks database access rules, and the free Deep scan reviews application code for access control, unauthenticated endpoints and exposed personal data. What a scan cannot prove is that a member is refused at a specific URL, which is why every brief names the query to run as the wrong user.
What we have not tested yet
- All 10 briefs in this category. Their cards show a question mark until we run them.
- The kit's schema created by Lovable from the gate brief alone, against the kit's SQL, queried as a member.
- Whether Lovable offers one of the three shortcuts when a member's page renders empty.
- The 10 free fix actions in the Security view on a generated admin tool.
Next run: Roles Table and the Admin Route Gate, on the kit's schema. How we test prompts
Who wrote this
Marco Kohns wrote these briefs and the kit, and ran the foundation prompt and the scans they build on. Lovable Prompts is independent and not affiliated with Lovable.
“Try in Lovable” links are affiliate links: we may earn a commission when you create an account through them. The Pro versions and the bundle are our own paid products. Neither decides which prompt we tell you to start with.
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.
Other prompt categories
Sources
- Lovable: How to build an admin panel without code (guide, 28 March 2026)
- Lovable docs: Prompt library (admin-only area, roles and permissions)
- Lovable docs: Database access rules
- Lovable docs: Security overview
- Lovable docs: Security view
- Lovable docs: Database view and SQL editor
- Lovable docs: Credits and usage
All read on 22 Oct 2026.