What is role-based permissions?

Role-based access control (RBAC) is the system that determines who can see and do what in your app. Rather than giving every user identical access, you define roles — Admin, Manager, Staff, Client, Read-only — and assign permissions to each role. Users inherit the permissions of their assigned role.

Without this, everyone who logs in sees everything. With it, a staff member can create jobs but not view financial reports; a client can see their own data but not another client's; an admin can configure the whole system.

It sounds straightforward, but getting permissions right — especially as your app grows — is one of the areas where shortcuts cause the most pain later.

When does your app need it?

• Your app has both internal users (staff, managers) and external users (customers, clients, partners)
• Some users should see certain data but not be able to edit it
• Actions like approving, deleting, or exporting data should be restricted
• Different customers should only see their own data — not each other's
• You have a hierarchy (e.g. manager approves before staff member can proceed)
• You're building a multi-tenant platform where each organisation manages its own users

How much does it cost?

Adding role-based permissions typically adds 5–11 hours of development — roughly $1,000–$2,000 AUD.

Simple role structures (2–3 roles, straightforward rules) sit at the lower end. Complex permission systems — with custom roles, fine-grained resource-level permissions, and audit logging of who accessed what — push toward the top.

Cost increases when:

• Permissions need to be configurable by the customer (not just by you the developer)
• Resources have ownership logic ("this user can only edit their own records")
• You need an admin UI to manage roles and assignments
• Permissions apply at field level, not just screen level

How it's typically built

Role-based permissions are typically implemented as a combination of database-level user attributes (each user has a role field) and middleware checks in your API and UI. When a user requests a resource or action, the system checks their role against a permissions matrix before proceeding.

For simpler apps, a flat role list works fine. For complex multi-tenant systems (where customers manage their own users), a policy-based system like CASL (JavaScript) or a dedicated service like Permit.io may be used to manage permissions declaratively.

The frontend reflects permissions by showing or hiding elements, but the real enforcement always happens server-side — hiding a button isn't security.

Questions to ask your developer

• Where does permission checking happen? The answer should be: "on the server, for every request." Frontend-only permission hiding is not secure.
• Can permissions be changed without a code deploy? If you need to add a new role or adjust what a role can do, ideally that's a configuration change, not a code change.
• How are permissions logged? For compliance or audit requirements, you may need a record of who accessed or changed what — and when.
• How do permissions work for data that belongs to one user but is visible to another? (e.g. a manager reviewing a staff member's work orders) This "ownership" logic is often where complexity lives.
• What happens when a user is mid-session and their role changes? Their access should update immediately, not at next login.

---

See also: Multi-tenant / organisations · Audit trail · App cost calculator