Next step · What to do next

Give staff the right access (roles and permissions)

What you may see

Different staff should see and do different things

Why this step

Least access means a mistake or a stolen password hurts less; roles must be enforced on the server and in database rules, not only by hiding buttons.

Before you start

List your staff types and what each must be able to see and do.

The prompt for this step

What you type here never leaves your browser. The search runs on this page, and nothing is sent to a server or to an AI.

Any error or warning you see now

What you have now (tool, framework, where it is hosted)

Kept only in this browser, on this device. Keys and passwords are removed before anything is saved.

Prompt language

You are a senior engineer and careful product advisor who builds small business websites and apps, and explains every step to people who are not developers. I am not a developer, so explain every step in plain words and tell me exactly which button, menu or command you mean. If you are not sure about something, say so; do not guess.

WHAT I WANT NEXT
Give staff the right access (roles and permissions)

ANY ERROR OR WARNING I SEE NOW (write "none" if there is none)
[paste the exact error here]

WHAT I HAVE NOW (the tool I used, the framework, where it is hosted)
[write in a few words what you did before it happened]

WHY THIS STEP
Least access means a mistake or a stolen password hurts less; roles must be enforced on the server and in database rules, not only by hiding buttons.

DO THESE STEPS, IN THIS ORDER
1. Define a small set of roles (for example owner, manager, staff, viewer) as a table of permissions per screen and action; wait for my approval.
2. Store roles in the database; check them on the server for every page, route and action; match them with row level security; give only the owner the power to change roles.
3. Log role changes and sensitive actions (refunds, exports, deletes) with who and when.
4. Test every role against every action, expecting refusals where needed.
Stop and tell me if what you see does not match a step. Do not skip ahead.

CHECK THAT IT WORKED
- Each role can do exactly what the table says, and refusals are logged.
Tell me exactly what I should see on the screen when it works.

DO NOT CHANGE
- Do not create a role that can do everything except the owner.
- Anything I did not ask about: the design, the text, other pages, other settings or the data.
- Do not delete files, data or branches, do not reset or force-push, and do not rewrite history, unless you first show me exactly what would be lost and I say yes.
- Do not paste, print or ask me to paste a password or secret key into this chat. If one is needed, tell me which settings page of the right service to store it in.

WHEN YOU FINISH
Explain in simple words what you changed (file by file or setting by setting), why you changed it, and how I can undo it.

Paste it into Claude, ChatGPT, Gemini or Cursor, then follow what it says.

After you tried it, did it work?

Steps

Define a small set of roles (for example owner, manager, staff, viewer) as a table of permissions per screen and action; wait for my approval.
Store roles in the database; check them on the server for every page, route and action; match them with row level security; give only the owner the power to change roles.
Log role changes and sensitive actions (refunds, exports, deletes) with who and when.
Test every role against every action, expecting refusals where needed.

Do not do this

Do not share one login among staff.
Do not create a role that can do everything except the owner.

Try another entry