Roles and permissions mean every staff member has their own account linked to a role (cashier, branch manager, accountant), and the role defines what they can see and change. The golden rule is least privilege: the minimum access that lets them do the job. Add branch-level scope, a second approval for sensitive actions such as large refunds, and a log of who did what and when, and enforce all of it on the server, not just by hiding buttons.
- how to add user roles and permissions to my app
- role based access control for small business app
- staff permissions in admin dashboard
- restrict employees to their own branch data
- difference between role and permission
What are roles and permissions, and why do you need them?
Roles and permissions give each staff member in your app access to exactly what their job needs. Instead of one shared 'admin' login, each person gets their own account, linked to a role such as 'cashier', 'branch manager' or 'accountant', and the role decides what they see and change. Technically this is called role-based access control (RBAC).
Why should a small business care? Three practical reasons: mistakes (a new hire deleting a product by accident), trust (not everyone should see profits and payroll) and accountability (when an order is cancelled or a price changes, you know who did it). With a shared login, none of those questions has an answer.
Give each person the key to their room, not the key to the whole building.
Permissions are the heart of any admin dashboard and any internal tool used by more than one person.
Four concepts: user, role, permission, scope
| Concept | Meaning | Example |
|---|---|---|
| User | One person with their own account | Sara, phone 05xxxxxxxx |
| Role | A named set of permissions | Branch manager |
| Permission | A specific action on a type of data | View orders, edit prices, issue refunds |
| Scope | Which data the permission applies to | Only the Olaya branch, or only customers assigned to her |
The common mix-up is thinking only in roles and forgetting scope. A 'branch manager' at the Olaya branch should not see Jeddah's orders or edit its staff schedule. Same role, different scope for each person.
Ready role sets by type of business
Do not invent roles from scratch. Here is a starting point for three common Gulf businesses; adjust it to your team:
Restaurant or café with several branches
- Owner: all branches, all reports, prices and menu.
- Branch manager: their branch's orders and staff schedule, mark items sold out, refunds up to a limit.
- Cashier: create orders and take payment in their branch, no cancellation after payment.
- Kitchen: the orders screen and the 'ready' status only.
Clinic
- Reception: appointments and contact details, without medical notes.
- Doctor: their own appointments, patients and notes.
- Accountant: invoices and payments, without medical details.
Online store
- Store manager: products, offers and orders.
- Customer service: orders, notes and refund requests, without prices.
- Warehouse: picking orders and stock, without payment data.
- External marketer: create coupons and read campaign reports only.
Sensitive actions: approvals and the audit log
Some actions are too risky for one person to do unchecked. Give them a second approval:
| Action | Requested by | Approved by | Why |
|---|---|---|---|
| Refund above a set limit | Customer service | Store manager or owner | Prevents mistakes and financial abuse |
| Product price change | Store manager | Owner for big discounts | Protects margin and catches extra-zero typos |
| Export all customer data | Any role | Owner | Data leaks are the biggest risk |
| Delete a customer account | Customer service | Manager | Usually irreversible |
| Add a staff member as manager | Manager | Owner | Prevents privilege escalation |
Then the audit log: every price change, cancellation, refund and role change is recorded with the staff member's name, the time and the before and after values. Nobody edits the log, not even the owner, who can only read it. On Fanann Enterprise plans, audit logs and approval flows are part of the package.
Staff sign-in and the account lifecycle
Permissions start with authentication: who is this person, really? For small teams, sign-in with a phone number and a one-time code is practical and enough, as in adding phone-number OTP login. For companies that already use Microsoft or Google accounts for staff, single sign-on (SSO) is better, because disabling someone's company account disables them in your app automatically.
- 1Invite
A manager invites the employee by phone number and picks their role and scope (branch). No passwords sent over WhatsApp.
- 2First sign-in
The employee signs in with a one-time code and sees only what their role allows.
- 3Role change
On promotion or transfer, change the role or scope, and the change is logged.
- 4Temporary access
Covering for a colleague on leave? Grant extra access with an automatic expiry date.
- 5Leaving
Disable the account the same day and end open sessions. Do not delete it, so its history stays in the log.
Where permissions are enforced: the mistake many make
- Hiding the 'delete' button from cashiers in the interface
- Removing the reports page from the menu
- Checking the role only in the mobile app
- A direct page link that works for any signed-in user
- The server rejects the delete request if the role lacks permission
- The reports API refuses unauthorized users
- Every request is checked on the server, whatever its source
- The database returns only the allowed branch's data
Hiding a button improves the experience, but it is not security. Anyone who knows how to send a request directly to the server can bypass it. Make sure permissions are enforced in the backend and the database. It is one of the key items in the security checklist for AI-built apps.
Test with a simple matrix
Before launch, sign in as each role and try: can a cashier open the reports link directly? Can the Olaya branch manager see Jeddah's orders? Can customer service export the customer list? Any unexpected 'yes' is a hole.
Build your role system in Fanann
Fanann builds roles and permissions as part of your app: you describe roles, scopes and approvals in plain language, and the agent builds staff management screens, enforces permissions on the server and database, adds the audit log and tests every page.
Add a role and permission system to my restaurant app with 3 branches (Olaya, Narjis, Jeddah). Roles: owner (all branches, all permissions), branch manager (own branch's orders and staff only, mark items sold out, refunds up to SAR 200), cashier (create orders and take payment in own branch, no cancellation after payment), kitchen (orders screen and 'ready' status only), accountant (payments and invoices for all branches with Excel export, no full customer profiles). Refunds over SAR 200, price changes and customer exports need owner approval. Staff sign in with phone number and a one-time code; managers invite staff and choose role and branch. Support temporary access with an expiry date. Disabling an account ends all sessions. Keep a read-only audit log of every price change, cancellation, refund and role change. Enforce all permissions on the server and database, then test with an account for each role and give me a report of what each role can and cannot do.
Try it in FanannNext step: write your team's names in one column and, next to each, what they do every day. The roles will emerge on their own. For attendance and leave, read build an employee attendance and leave app.
Key takeaways
- One account per person and one role per account; shared logins destroy accountability.
- Start with least privilege and widen when needed, never the other way round.
- Roles define what someone can do; scope defines which data: their branch, or only their customers.
- Sensitive actions need a second approval and an audit log nobody can edit.
- Permissions are enforced on the server; a hidden button alone is not protection.
Frequently asked questions
How do I add user roles and permissions to my app?
Can I restrict each employee to their own branch's data?
What is the difference between a role and a permission?
What should I do when an employee leaves?
Is hiding buttons enough to protect permissions?
Ask your AI assistant about this
Copy this prompt into the AI assistant you use, then add the details of your own case.
I am reading this guide: “Roles and permissions: give every staff member the right access in your app” https://fanann.com/en/blog/roles-permissions-staff-app/ My question: how to add user roles and permissions to my app Use that page as a source and explain the answer step by step for my situation, tell me what to check before I start, and cite the page link.