A customer rings, support cannot see their account, so it becomes an engineering ticket that takes two days. Here is the model behind the tool that ends that, the prompts to build it, and what it takes to run it.
Your private status link is on its way to your inbox.
An internal admin dashboard lets support look a customer up and fix their problem without asking engineering. It is four parts: search that matches how an enquiry actually arrives, a record view that assembles everything about that customer in one place, a set of named actions they can take, and a log of every action taken. The one design decision that matters is the third: give operators a finite list of named actions rather than the ability to edit any field. A named action can be previewed, limited, logged and usually undone. An arbitrary edit is none of those, and it is how production data gets quietly corrupted.
Support console
Pro, annual
Plan
288 of 300
Seats in use
41 days
To renewal
2
Open tickets
Halden Foods
Customer since March 2024 · account manager R. Iyer
What has happened to this account
You run support, operations or the engineering team fielding their requests. What you want is for routine account questions to stop becoming engineering tickets, without handing anyone a database client.
What an agent does while a customer is still on the phone.
An email address, an order number, a partial company name, a ticket reference. Support almost never has the customer id, so search has to match the way an enquiry actually arrives.
Plan, billing status, recent orders, recent activity, open tickets and any flags, assembled from wherever those things live. No second tab, no second login.
The history sits on the record, not in a separate report. Most confusing account states are explained by something a colleague did last week.
Send a sign-in link, extend a trial, apply a credit, resend a receipt, merge duplicates. Each one has preconditions, a role, and a preview of what will change.
Actor, timestamp, reason, and a before and after. Refusals are logged too, and those are frequently the more interesting entries.
Higher role, full preview of every affected record, a typed confirmation. Safe on one record says nothing about safe on four thousand.
Four parts, and the third is the one that decides whether this is a support tool or a way to corrupt production data by accident.
Finding a record the way an enquiry arrives: an email address, an account name, an order or invoice number, a partial phone number, a support ticket reference.
Everything about one customer or account on one page, assembled from whichever systems hold it, so an operator does not need four tabs and three logins.
A finite list of named operations with clear preconditions: reset a password, extend a trial, resend a receipt, cancel an order, merge duplicates. Not arbitrary field editing.
Every action with the actor, the timestamp, the reason, and a before-and-after snapshot. Both a control and the fastest way to explain a strange account state later.
These prompts start from a Helix project, which is what handles sign-in, credentials and hosting. Start with Helix
Paste these into Claude Code, Codex or Cursor in order. Each one leaves you with something that runs, so you can stop after any step.
Search the way support actually looks things up.
In this Helix project, build me an internal admin dashboard for our support
team.
Start with search. One box that matches on the identifiers an enquiry
actually arrives with: email address, account name, customer id, order or
invoice number, phone number, support ticket reference. Partial matches on
names and emails, exact on identifiers.
Show enough in the results to tell two candidates apart: name, email,
status, created date, plan. Support very often has two and needs to pick.
Then a record page that assembles everything about one customer in one
place: profile, plan and billing status, recent orders or transactions,
recent activity, open tickets, and any flags.
Pull each section from its own module, and render a section that fails to
load as unavailable with a retry rather than failing the whole page. One
slow system should not make the dashboard useless, and a partial outage is
exactly when support needs it most. Show the last refresh time per
section.
I sign in through Helix, so do not build a login page. Read the signed-in
user from the runtime. And do not put any key or connection string in the
code: if this needs to reach another system, tell me and I will create the
connection in my workspace.Worth knowing. Degrading section by section is what makes an admin tool usable on a bad day, which is the only kind of day it gets used hard.
The decision that keeps this from becoming a liability.
Now the important part. Define every operation as a named action rather than
exposing raw field editing.
For each one specify: a name, what it does, the preconditions, the role
required, whether a reason is mandatory, and whether it is reversible.
Start with these and let me add more in a config file: send a sign-in link
or reset a password, extend a trial by a set number of days, apply a
credit or refund up to a role-dependent limit, resend a receipt or
notification, cancel or reschedule an order, merge duplicate records,
suspend or reinstate an account, add an internal note.
Rules for all of them. Show a preview of what will change before it
happens. Require a typed confirmation for anything destructive or
irreversible. Enforce the role server side, not just by hiding a button.
And refuse cleanly rather than partially applying when a precondition
fails.
Do not build a generic field editor. If an agent needs to change something
not on this list, that should become a new named action.Worth knowing. A named action can be reviewed, rate limited, logged meaningfully and usually reversed. An arbitrary edit is how production data gets quietly corrupted.
On the record, not buried in a separate report.
Add an append-only audit log: actor, action, target record, timestamp,
reason, parameters, a before and after snapshot, and the outcome. Never
edited, never deleted.
Log every action including failed attempts and refusals. A blocked attempt
is frequently the more interesting entry.
If the data warrants it, log views of sensitive records too, as a separate
lower-volume entry type.
Make the audit searchable by actor, action, target and date range, and put
it on the record page itself so an agent can see what was already done to
this account before acting. Most confusing account states turn out to be
something a colleague did last week.
Then report actions per operator per week, the most used actions, and
refusals by reason. A frequently refused action is usually a precondition
that does not match reality.Roles, limits, and a separate path for bulk.
Put roles in a config file, each listing the actions it may perform and any
limits such as a maximum refund. Enforce server side.
Include a read-only role. It will cover most requests for access, because
most people asking for an admin dashboard only need to look something up,
and giving them a role that cannot change anything removes most of the
risk of saying yes.
Rate limit each action per operator, so a mistake or a compromised account
cannot touch a thousand records before anyone notices.
Give bulk actions their own path: a higher role, the full list of affected
records shown first, a typed confirmation, and one audit entry per record
rather than one for the batch.
If I ask for a view-as feature, make it strictly read-only, time limited,
loudly indicated in the interface throughout, and audited on entry and
exit.
And add a test mode against sample data so new agents can learn the tool
without touching a real account.The step that turns a working prototype into something with your data in it.
Now connect it to the systems we actually run, so it works on real data
rather than the rows you seeded.
Anything in angle brackets is a placeholder. Swap it for whatever we use
instead, and have the app name the connection it wants rather than assume
a vendor, so changing my mind later is a config change and not a rewrite.
<your product database>. Read the customer record and perform the named
actions. Scope this to the actions you defined, not to everything.
<Stripe>. Read plan and payment status, and apply the credits and refunds
your roles allow.
<Zendesk>. Show open tickets on the record, so support is not holding two
tabs.
<Okta>. Authenticate the operator and read their group, so every action in
the audit log has a verified name and a role behind it.
<Salesforce>. Show the account and its owner, so an agent knows who to
hand a commercial question to.
<Snowflake>. Read usage history for the account, which the production
database should not be queried for.
<Slack>. Post high-privilege actions to a channel security can watch, in
addition to the audit log.
<Gmail>. Resend receipts and notifications, which is a large share of what
support is asked for.
Only write where I have said to write. Everything else is read only.
Do not write a key, a token or a connection string anywhere in the code,
and do not ask me to paste one. Tell me which connections you need and I
will create each as an authentication in my Helix workspace. Reference
them by alias.Worth knowing. Every name in angle brackets is a placeholder for whatever you run. Helix holds the credential as a workspace authentication, so the app references an alias and never the secret itself.
The last step of every build: a URL, and the right people on it.
Deploy my app.Worth knowing. Your assistant runs helix deploy underneath and the app comes back as a URL. This tool acts on production customer data, so set Access Control before sharing and scope operators to the actions their role warrants.
This is the app with the widest reach in the library, and every connection is a decision about blast radius.
Your product database
Read the customer record and perform the named actions. Scope this to the actions you defined, not to everything.
Stripe
Read plan and payment status, and apply the credits and refunds your roles allow.
Zendesk
Show open tickets on the record, so support is not holding two tabs.
Okta
Authenticate the operator and read their group, so every action in the audit log has a verified name and a role behind it.
Salesforce
Show the account and its owner, so an agent knows who to hand a commercial question to.
Snowflake
Read usage history for the account, which the production database should not be queried for.
Slack
Post high-privilege actions to a channel security can watch, in addition to the audit log.
Gmail
Resend receipts and notifications, which is a large share of what support is asked for.
Each line says whether the app reads, writes or both. Anything not described as writing should be read only.
Named systems are the ones most teams actually run, not a list of the only ones that work. Swap in whatever you use.
Each connection is an authentication in your Helix workspace, referenced by alias. The app names the connection it wants and never holds the credential, so nothing here ends up in your code and any of it can be rotated or revoked without a redeploy.
The build gets you a working dashboard. It reads and writes production data on behalf of staff, which makes how it is run the more important half.
AI Deployment
One command takes the app from your assistant to a live address, so the people who need it get a link rather than instructions for running it locally.
App Security
This tool acts on production customer data. SSO means every action is attributable to a verified person, and access is scoped so operators hold only the actions their role warrants.
App Security
Reading and writing across production systems needs real credentials. Granting them to the app rather than embedding them means they can be rotated or revoked without a redeploy, and the app's reach is something you can see.
App Registry
Every app carries a named owner and an entry IT can see, so the tool does not become nobody's problem when the person who built it changes role.
Cost Management
Per-app spend visibility, with budgets and caps, so an internal tool cannot quietly become a line item nobody can explain.
A tool that lets support and operations staff find a customer record, see everything about it in one place, and perform a defined set of actions against it, with every action logged. It exists so routine account questions stop becoming engineering tickets.
No. Define named actions with preconditions, role requirements and reasons instead. A named action can be reviewed, logged, rate limited and often reversed. An arbitrary field edit is how production data gets corrupted in ways nobody can trace.
The actor, the action, the target, the timestamp, the reason, and a before-and-after snapshot, appended and never edited. Log refused and failed attempts too, since those are frequently the more interesting entries.
On a separate path with a higher role, a full preview of affected records, a typed confirmation, and one audit entry per record rather than one for the batch. An action being safe on a single record says nothing about it applied to four thousand.
Yes, and it will cover most requests for access. Many people asking for an admin dashboard only need to look something up, and giving them a role that cannot change anything removes most of the risk of granting it.
Yes. The prompts here are written for Claude Code, Codex or Cursor and stage the build. The judgement calls are which actions to define and which roles may perform them, and those are operational decisions rather than technical ones.
Customer Success
Let customers see their own account, users, usage and documents, with the multi-tenant boundary and the organisation model built in from the first commit. Prompts to build it, and what it takes to run it.
IT and Operations
Request access against a defined catalogue, route it to the system owner, grant it with an expiry, and produce the evidence an access review needs. Prompts to build it, and what it takes to run it.
Last reviewed September 2026.
Helix is the governed runtime for AI-built apps. Deploy what you build, put SSO in front of it, connect it to your systems with managed credentials, and give it a named owner.
Your private status link is on its way to your inbox.