What is the difference between a user role and a permission?

A role is a named type of user, such as owner, staff or customer. Permissions are the individual things that role may view, create, change or delete. Writing the permissions in a matrix makes each role easier to verify.

Is hiding an admin link enough to protect it?

No. Someone may still type the page address directly or request another person's information. The app must enforce the rule on the page action and the stored information, then be tested with a normal account.

How many roles should my app have?

Use as few as possible. Owner, staff and customer cover many small apps; add another only when that group needs a meaningfully different set of permissions.

Authentication & Users

Add user roles and real permissions

Give owners, staff and customers different pages, actions and access, enforced on the stored information.

Time: ~45 minutes, including tests with separate accounts Difficulty: Intermediate Works with: Base44 / Lovable / v0

When to use this

When login already works but owners, staff and customers need different pages, actions and access to stored information.

Before you start

Working sign-up and login. Use the authentication prompt first if accounts do not exist yet.
A written list of the roles you actually need. Start with fewer roles and add another only when its permissions are genuinely different.
A simple permission matrix showing what each role may view, create, change and delete.
Separate safe test accounts for every role, plus one logged-out browser window.
A decision about who may assign or change roles. This should normally be limited to the owner or a narrowly trusted administrator.

The prompt

Add user roles and permissions to this existing app. Login already works. The roles are [ROLE ONE], [ROLE TWO] and [ROLE THREE]. Use these descriptions: [ROLE ONE CAN SEE AND DO], [ROLE TWO CAN SEE AND DO], and [ROLE THREE CAN SEE AND DO].

Before changing anything, show me a plain-language matrix with the roles down one side and the important pages, information and actions across the top. Mark what each role can view, create, change and delete. Include logged-out visitors. Flag any unclear or conflicting instruction instead of guessing.

After I approve the matrix, enforce it on both the screens and the stored information. Hiding a menu item is not protection. If someone types a private page address directly or changes an item number in the address, the app must still refuse access to anything outside that person's permission.

Use the safest default when a rule is missing: deny the action and show a calm message. A [CUSTOMER ROLE] may see and change only [THEIR OWN INFORMATION]. A [STAFF ROLE] may see and change [ASSIGNED OR SHARED INFORMATION]. A [OWNER ROLE] may manage [OWNER-ONLY AREAS]. Adjust these examples to match my approved matrix.

Add an owner-only user management screen where [AUTHORIZED ROLE] can view a person's current role and change it. Users must never choose a more powerful role for themselves through sign-up, profile editing or a changed page address. Keep a small history showing who changed a role, whose role changed, the old role, the new role and the time.

Do not confuse live app roles with builder access. Staff who use the finished app should not automatically gain access to the builder, project settings, private connection keys or deployment controls.

Test with one account for every role and one logged-out window. Try the normal navigation, direct page addresses, viewing another person's record, changing allowed information and attempting one forbidden action. Do not use real customer accounts or data.

Keep the existing design and make denied-access messages clear rather than frightening. Finish with the approved matrix, the test results and anything that remains broader than I requested.

Already building? Paste this into your project. Starting fresh? Open a free account with a compatible builder below.

Build it on

Start free with Base44 Read Review: Base44

Start free with Lovable Read Review: Lovable

Start free with v0 Read Review: v0 by Vercel

How we make money

What this creates

A plain-language permission matrix for every role
Protected pages and stored information based on that matrix
An owner-only screen for assigning roles
Protection against self-promotion and direct-address access
A small history of role changes
Test results from each role and a logged-out visitor

Check it worked

Paste the prompt, wait for the build to finish, then confirm these — in plain language, no technical checks needed:

Each test account sees only the pages and actions intended for its role
A customer account cannot view another customer's information
A staff account can complete its allowed work but cannot open owner-only settings
Typing a forbidden page address directly shows an access message instead of private content
A normal user cannot give themselves a more powerful role
The authorized owner can change a test role and see a readable history of that change
Signing out removes access immediately

Something missing? That's normal — ask for it in one short follow-up message rather than re-running the whole prompt.

Next steps

Add staff invitations

When role rules work and the owner needs a safe way to add team members

Add an owner-only invitation flow for [STAFF ROLE]. The owner enters [STAFF EMAIL] and chooses from [ALLOWED STAFF ROLES]. The invited person sets up their own login and receives only the selected live app role. Do not give them access to the builder or project settings.

You'll know it worked when: An invited test account joins with the chosen staff role and cannot enter owner-only areas or the builder.

Limit staff to assigned records

When staff should work only with their own clients, locations or tasks

Change [STAFF ROLE] access so each staff member can view and update only records assigned to them through [ASSIGNMENT FIELD OR RULE]. Owners may still view all records. Test with two staff accounts and confirm neither can open the other's assigned record directly.

You'll know it worked when: Each staff test account sees only its assigned work, while the owner still sees the complete list.

Audit permissions after a new feature

Whenever you add a page, data type or admin action

Update the existing permission matrix for [NEW FEATURE]. Show what logged-out visitors and every current role can view, create, change and delete. Apply the narrowest approved rules, then repeat one allowed and one forbidden test for each affected role.

You'll know it worked when: The new feature appears in the matrix and follows the same tested permission system as the rest of the app.

Watch out for

App roles and builder roles are different. Someone who manages customers inside the finished app does not automatically need permission to edit the app itself.
Hidden buttons are not access control. Test direct page addresses and another person's record; the stored information must reject the request even when the menu hides it.
Too many roles become impossible to reason about. Start with owner, staff and customer unless a fourth role has clearly different responsibilities.
Permission changes can affect real users immediately. Test with sample accounts and review the matrix before applying changes to a live app.
One broad staff role may expose more than expected. If staff should see only assigned clients or locations, state that rule explicitly and test with two staff accounts.

Platform notes

<ul><li>Base44: Base44 includes live app roles and data access rules, and it can create extra roles beyond its defaults. Builder collaborators are separate from app users, so do not make a staff user a collaborator unless they truly need to edit the app.</li><li>Lovable: Lovable can build role-based access with Lovable Cloud or connected Supabase storage. Ask for protection on the stored information, not only the visible pages, and test every role after publishing.</li><li>v0: v0 needs a connected login and data service for real permissions. It can build the screens and private checks, but the exact storage provider must enforce who can read or change each person's information.</li></ul>

Spend fewer credits

Every builder charges you for the work its AI does — so the cheapest habit is thinking before you build. These six rules cut most of the waste, whichever platform you choose.

Plan in a free chat first. Sketch the whole thing in ChatGPT, Claude or Gemini — pages, features, what each form collects, what it should look like. Thinking there is free; thinking inside a builder is billed.
Start from a written prompt, not a sentence. "Make me a website" is the most expensive sentence in AI building. A complete first prompt — like the ones on this site — saves dozens of correction rounds.
Don't be lazy with the details. Every detail you leave out comes back as a correction you pay for. Business name, colors, every page, every form field, what happens after someone submits — put it all in the first prompt.
One change per message afterwards. "Fix the header, and the form, and the colors" produces a tangle that costs more to unpick than it saved.
Stuck? Stop patching. If the same fix fails about three times, don't send a fourth correction — describe the whole section's desired end state in one fresh message instead.
Start free. Upgrade when you need more. Use the free allowance to build and explore your first version. Upgrade when you need more usage or paid features, and check any connected service costs before launch.

The prompts on this page are written to do most of this work for you — that's the point of them.

Read the full guide

Related playbooks

Related prompts

Part of these kits

Last reviewed: 2026-07-27