User Levels
A User Level is a named permission set tied to a single system module. Each user level grants a specific group of permissions within one module (for example "HR Manager" within HR, or "System Administrator" within Settings). User levels are the building blocks that roles are assembled from.
Right-click a row to open it, edit it, or delete it.
New to how departments, user levels, roles, the Reports To line and employee records fit together? Start with the tutorial Understand Users, Roles and Employees.
Overview
Instead of assigning individual permissions to every role, you create reusable user levels β each one is a curated bundle of permissions for one module. A role then combines one or more user levels to define what a user can do across the system.
Each user level has:
- A Label (the name you give it)
- A System Module it applies to
- An optional Description
- A set of Permissions chosen from that module's navigation structure
Finding This Page
Go to Settings β Users & Access β User Levels.
Visibility is permission-based: you only see a user level if you personally hold at least one of the permissions it grants. A user level you hold none of is hidden from this list entirely β as if it didn't exist. Where a user level IS visible, the Permissions count and its permission tree show only the permissions you personally hold, not the level's full bundle β so two administrators can see a different count for the exact same user level.
Page Layout
The User Levels page shows a table of all existing user levels you can see, with:
| Column | Description |
|---|---|
| Label | The name of the user level |
| System Module | The module the level applies to (shown with its icon) |
| Permissions | The number of permissions granted, narrowed to the permissions you personally hold (e.g. "8 permissions") |
You can search the list by Label and filter it by System Module. Click any row to open that user level's detail page.
At the top right of the page, an AI Assistant button (robot icon) opens a chat sidebar that can list, create, update, and delete user levels for you conversationally. See AI Assistant.
The other button shown at the top right of the page depends on the current state:
- When no user levels exist yet β a Seed Default Data button appears.
- When user levels exist β an Actions dropdown appears with Add User Level and Clear All options.
Common Tasks
Creating a User Level
- From the User Levels page, open the Actions dropdown and choose Add User Level (or use the Add User Level button).
- Under Basic Information, fill in:
- Label (required) β a descriptive name, e.g. "HR Manager" or "Team Lead".
- System Module (required) β select which module this level applies to. Changing the module clears any permissions you had selected.
- Description (optional) β explain this user level's purpose and responsibilities.
- Under Permissions, select the permissions to grant. The available permissions come from the navigation structure of the system module you chose. You must select at least one permission.
- Click Add User Level to save. You are taken to the new user level's detail page.
π Note: Label, System Module, and at least one permission are all required. The form will not submit until they are filled in.
Viewing a User Level
- Click any row in the User Levels table.
- The detail page shows the Basic Information (Label, System Module, Description) and the Assigned Permissions, organized by the module's navigation structure β limited to the permissions you personally hold.
Editing a User Level
- Open a user level's detail page.
- Click Edit. Editing is available even when the level grants permissions beyond your own β you don't need the whole bundle to edit it.
- Update the Label, System Module, Description, or selected permissions.
- Click Save Changes. Any permission the level already granted that you don't personally hold is left untouched β you can only add or remove permissions you yourself have.
Deleting a User Level
Delete only appears on a user level's detail page if you hold every permission it grants. If you hold only some of its permissions, Delete is hidden β deleting would destroy permissions you can't even see, so you'll need an administrator with the full bundle to remove it.
- Open a user level's detail page.
- Click Delete.
- Confirm in the dialog by clicking Delete.
β οΈ Warning: Users assigned to this level will lose the permissions it granted. This action cannot be undone.
Seeding Default User Levels
Newly created workspaces start with the full set of default user levels already in place, so most companies never need this step. If the page is empty (for example after Clear All), you can recreate the full set of predefined levels in one step.
- Click Seed Default Data.
- Review the confirmation dialog. It creates predefined user levels covering all system modules, including:
- HR: HR Administrator, Manager, Viewer, Timekeepers, Payroll Manager, Leave Approver
- Settings: System Administrator, Manager, Viewer
- Project: Administrator, Manager, Member, Viewer
- Treasury, Asset: Administrator, Manager, Viewer
- Orders: Orders Admin, Orders Staff, Orders Viewer
- Calendar, Leads, School, Governance: Admin, Manager, User levels
- Click Create Defaults. All the predefined user levels are created with appropriate permissions.
This is a non-destructive action β it only adds default levels your company is missing and never changes existing ones.
Orders Access Levels
Orders has its own section in the permission tree when you create or edit a user level (system module Orders). It holds three permissions:
- Work on orders β start orders, work their steps and fill in their documents. Under it are three actions: Advance a step, Cancel an order and Cancel / mark lost (any workflow).
- Orders β view only β see orders, their documents, the Orders reports and Open POs; every change is refused.
- Order settings β change the outcome reasons and the Lost needs approval default.
Three standard levels come with every company, and nobody is assigned to them until you do it:
| User level | Permissions |
|---|---|
| Orders Admin | Work on orders, Advance a step, Cancel an order, Cancel / mark lost, Order settings. Described as "Everything on orders, including cancel, mark lost and Order settings". |
| Orders Staff | Work on orders and Advance a step ("Start orders, work their steps and their documents"). |
| Orders Viewer | Orders β view only ("See orders, their documents and reports β change nothing"). |
Plain Assets access no longer opens orders for changes. Levels that reached Orders only through Assets access (including your own custom levels) were given Orders β view only, so nobody lost sight of orders. To let such a role work on orders, add Orders Staff or Orders Admin to it. The standard Asset Administrator and Asset Manager levels keep working on orders; the Asset Viewer level is view-only.
How each screen behaves for a view-only user is described in Order Fulfillment β Who Can See and Change Orders.
Clearing All User Levels
β οΈ This is a destructive, high-impact action protected by a one-time password (OTP).
- Open the Actions dropdown and choose Clear All.
- The dialog warns that this will permanently delete:
- All user levels for this company
- Related role-to-user-level assignments
- Orphaned roles (roles left with no remaining user levels)
- User accounts linked to those orphaned roles
- Request the OTP, enter the code you receive, and confirm with Clear All.
π Your own account and role are always preserved. This action cannot be undone.
Permissions Added for Payroll and HR Features
Newer payroll and HR screens have their own permissions in the permission tree, so you can give people exactly the access they need. Each screen has an access permission (to open it) and separate action permissions, which appear as checkboxes under it. Existing user levels do not gain them automatically unless you tick them.
| Screen | Action permissions (as labelled) | What they control |
|---|---|---|
| Payroll β Disbursements | Create/Edit Runs, Approve, Release, Export Files | Off-payroll disbursement runs. Approve and Release are separate permissions so one person need not do both. |
| Payroll β Payroll Journal | Setup & Edit Journals, Download Journal | Setting up and downloading the payroll journal. |
| Payroll β Debit Notes | Setup & Generate Notes, Download Notes | Inter-company recharge debit notes. |
| Payroll β Separation Pay | Confirm Clearance | Marking a leaver as cleared, which unlocks final-pay release. Kept separate from Update. |
| Bank Accounts (Employee Records) | View Full Account Numbers, Add/Edit/End Accounts, Import, Export | Without View Full Account Numbers, bank numbers show only the last 4 digits everywhere, including search, exports and profile change requests. |
| Manpower β Employee Records | View Compensation | Who sees pay on the employee record: monthly rate, contract history amounts, allowances, deductions, previous-employer income, salary certificate and the pay columns of the list and export. Without it the same fields, sections and columns still appear, but every amount is masked (β± β’β’β’β’β’β’), and a user can still manage every non-pay field. Existing levels with Employee Records access received it automatically, so remove it where pay must stay private. See Who Can See Pay. |
| Employee dispatch records | Add / Import Dispatches, Edit / End Dispatches | Recording when an employee is dispatched. |
| Filing β Schedule Swap | Approve/Reject | Filing and approving schedule swaps. |
| Manpower β Announcements | Create, Update, Delete | Posting, editing and deleting company announcements from the HR dashboard. Reading and acknowledging announcements stays open to everyone. The default HR Administrator level carries these on newly set-up companies; for existing levels, tick them yourself. See HR Dashboard. |
Tighter Access on Existing HR Features
- Exporting the employee list from Employee Records needs the HRIS Update permission.
- Employee photos and media need HRIS access.
- Adding, editing, or ending an employee contract needs HRIS Update; viewing contracts needs HRIS access.
- The regularization due list is limited to branches the viewer can reach, and the pending regularization rates are visible only with HRIS Update.
- Issuing a salary certificate for another employee needs the Payroll Center Submit or Export permission. Employees can always get their own, if your company allows it.
Cancel / Edit Invoices Permission
Changing an invoice is controlled separately from viewing it. In the permission tree, under Treasury β Collection by Invoice, the Cancel / Edit Invoices checkbox lets a user edit an invoice, change its status, cancel it (which reverses its journal entry) and delete a draft. Opening invoices and creating them do not need it; recording collections has its own permission (below).
- Users without it still see the Edit, Change Status and Delete buttons on an invoice, but greyed out with the reason on hover.
- The default Treasury Administrator and Treasury Manager levels include it; Treasury Viewer does not.
- User levels that already had any Receivables access were given the permission automatically, so nobody who worked with invoices lost the ability. Levels created from now on need it ticked.
Record / Void Collections Permission
Recording a collection (payment) on an invoice puts money into a fund account and posts the journal entry; voiding one reverses both. Under Treasury β Collection by Invoice, the Record / Void Collections checkbox allows it.
- Users without it don't see Record Collection on an invoice, and the receipts list shows no Void action.
- The default Treasury Administrator and Treasury Manager levels include it; Treasury Viewer does not.
- User levels that already had any Receivables access were given the permission automatically, so nobody who recorded collections lost the ability. Levels created from now on need it ticked.
- The Collection step of an order workflow doesn't need it β the workflow step's own permissions apply.
Fund Accounts and Purchase Order Payments
Moving money is controlled separately from viewing it:
- Treasury β Fund Account β Record, Transfer & Manage allows a manual add or subtract, a transfer between fund accounts, a bank-statement import, and creating, editing or deleting a fund account. Without it the fund-account pages are read-only.
- Recording a payment on a purchase order β directly, or by settling a bank-statement line to it β needs the purchase order's Update permission (the same one that opens the payment page). A bank-statement import that settles a line to an invoice or a purchase order needs that second permission on top of Record, Transfer & Manage: Record / Void Collections for an invoice, the purchase order's Update for a PO.
- The default Treasury Administrator and Treasury Manager levels include them; Treasury Viewer does not.
- Levels that already had Treasury write permissions (create, update, approve, releaseβ¦) were given these automatically; read-only Treasury levels were not β they keep seeing fund accounts and purchase orders but can't move money. Levels created from now on need them ticked.
How User Levels Fit With Roles
User levels are not assigned directly to users. Instead:
- You build user levels β each a permission bundle for one module.
- You assign one or more user levels to a Role.
- You assign the Role to users.
This lets you reuse the same permission sets across many roles instead of re-selecting permissions each time.
Related Pages
- Roles β combine user levels into assignable roles
- Users β assign roles to users
- AI Assistant β manage user levels by chatting instead of using the forms
π‘ Note: Each user level applies to exactly one system module. To grant a user permissions across several modules, assign their role multiple user levels (one per module).
How It Connects
Each user level targets one system module, and the sidebar entries and actions of that module are shown or hidden according to the permissions the user holds. Build the levels first, then group them into roles.