Roles & Permissions (RBAC)

How access is decided

Two independent tests must both pass before someone can do something:

1. Does their role carry the permission? Roles are assigned per business unit, so the same person can be a manager in one outlet and a cashier in another.
2. Is the module enabled on that business unit? A kitchen permission is meaningless in a unit with no kitchen. See Business Units.

Permission shape

Permissions read as area : action — for example inventory:count, kitchen:read, daily_reconciliation:create, document:create. The area names the part of the system; the action names what you may do in it. Reading, creating and approving are usually separate actions, which is what lets you give someone visibility without giving them authority.

Common Tasks

How to Create a Custom Role (new role, add role, custom permissions)

Create a role when none of the system roles matches how a job actually works in your business.

Required permission: Organization administrator or owner

1. Go to Settings → Roles in the left sidebar
2. Click Create New Role
3. Enter the role name and a description of who it is for
4. Select the permissions the role should carry
5. Click Create Role

Result: The role is available when assigning people to a business unit.

Note: Start from the least access that lets the job be done and add to it. It is far easier to grant a missing permission when someone asks than to discover months later that everyone could void transactions.

How to Change What a Role Can Do (edit role, change permissions, grant permission)

Adjust an existing custom role's permissions.

Required permission: Organization administrator or owner

1. Go to Settings → Roles
2. Open the role to see Role Details
3. Add or remove permissions
4. Click Save Changes

Result: Everyone holding that role gains or loses the access immediately.

Note: System roles cannot be edited — you will see System roles cannot be modified. To vary one, create a custom role instead.

How to Give Someone Access to a Business Unit (add staff, assign role, invite user, give access)

People are given a role per business unit, so access follows where they actually work.

Required permission: Organization administrator or owner

1. Go to Settings → Team in the left sidebar
2. Invite the person, or open an existing team member
3. Assign them a role for each business unit they work in
4. Save

Result: They can sign in to both the main system and the staff app, seeing only the units they were given and only what their role in each allows.

Note: Someone working across two outlets needs a role in each. Access in one unit grants nothing in another.

How to Work Out Why Someone Cannot See a Screen (missing menu item, cannot access page, permission denied)

Check the two tests in order — most reports of missing access are the second one.

1. Confirm which business unit they are signed into
2. Check that unit has the relevant module enabled at Settings → Business Units
3. Check their role for that unit at Settings → Team
4. Open the role at Settings → Roles and confirm it carries the permission

Result: You find whether it is the role or the business unit configuration, and can fix the right one.

Note: If it works for them in one outlet but not another, it is the business unit's modules, not the role.

How to Delete a Role (remove role, delete custom role)

Remove a custom role that is no longer used.

Required permission: Organization administrator or owner

1. Reassign anyone currently holding the role to a different one
2. Go to Settings → Roles and open the role
3. Click Delete Role and confirm

Result: The role is removed and can no longer be assigned.

Note: Move people off the role first. Deleting a role that people still hold leaves them without the access they need to work.

Designing roles that hold up

• Separate doing from approving. The person who counts stock should not be the person who approves the variance; the person who captures an invoice should not be the person who posts it. Qvian splits these actions so you can enforce that.
• Grant read before write. Most people need to see far more than they need to change.
• Match roles to jobs, not to people. A role called “Head Chef” survives the head chef leaving; one called “Ahmed’s access” does not.
• Review after someone changes job. Permissions accumulate — people are promoted and keep their old access alongside the new.