A permission is a single, atomic access right — “can view products” or “can create purchase orders”. A role is a named bundle of permissions that you assign to users. Instead of granting permissions one by one to each person, you create roles that match job functions and assign those.
This means when a new person joins the team, you assign them a role and they immediately have the right access. When someone changes roles in the company, you swap their Beelocity role and their permissions update everywhere at once.
How Permissions Are Structured
Every permission follows the pattern Module > Resource > Action:
- Inventory > Product > View — can see products.
- Inventory > Product > Create — can add new products.
- Procurement > Purchase Order > Approve — can approve purchase orders.
- IAM > Role > Manage — full control over role definitions.
Actions
Actions define what the user can do with a resource:
| Action | What it grants |
|---|---|
| View | Read-only access — can see the resource but not change it |
| Create | Can create new records of this type |
| Update | Can modify existing records |
| Delete | Can deactivate or remove records |
| Approve | Can approve pending items (purchase orders, adjustments, etc.) |
| Export | Can export data to CSV or other formats |
| Manage | Full control — grants View, Create, Update, Delete and Export together |
Manage does not include Approve. Approving is a separate responsibility from editing: someone who raises and amends purchase orders is not automatically the person who signs them off. If you want a role to approve things, tick Approve explicitly.
On a role’s Permissions tab, ticking Manage ticks and closes the View, Create, Update, Delete and Export boxes for the same records, each marked Included in Manage: the role already has them. Untick Manage and they open again.
Permissions are grouped by module in the interface, so when you are setting up a role you can quickly grant all inventory permissions, all procurement permissions, or pick individual ones.
Pay has a heading of its own. The permissions to set up pay, run the month, pay it and declare it are listed under Payroll, beside Human resources, which holds the staff, their contracts, leave and hours. That is where you decide who may see salaries: a role can keep the staff without a single Payroll permission.
The public holidays are the organization’s. Their permissions are listed under Organization, beside the countries, and not under Human resources: the holidays are read by every module that counts working days, and a business that does not use Human Resources still keeps them (Public holidays). The built-in Human resources officer role still holds them.
Built-in Roles
Every new organization starts with ten system roles, ready to hand out. The owner role is given to whoever creates the organization; the other nine wait for you to assign them:
| Role | What it is for |
|---|---|
| Organization owner | Can do everything in the organization. Held by whoever created it. |
| Treasurer | Runs the treasury: confirms and cancels payments, and keeps the accounts, cheques, transfers, bank reconciliation and forecasts. |
| Cashier | Runs the till — opening, selling, refunding and closing — records payments for the treasurer to confirm, and takes cheques to the bank. |
| Sales manager | Runs sales: takes quotations, customer orders, delivery notes, invoices and credit notes through to the end, and manages clients. |
| Sales clerk | Prepares quotations, customer orders, delivery notes, invoices and credit notes. Sending and confirming them is the sales manager’s job. |
| Procurement manager | Runs purchasing: approves purchase requisitions and purchase orders, receives goods, and keeps suppliers and their catalogues. |
| Procurement clerk | Raises purchase requisitions and prepares purchase orders and goods receipts. Approving them is the procurement manager’s job. |
| Human resources officer | Keeps the staff register and runs their pay: departments, job titles, employees and their contracts, leave, and each month’s payroll, from signing to departure. Nothing outside Human Resources and Payroll. |
| Foreign trade officer | Follows the purchases from abroad: opens the import dossiers, keeps the bank domiciliation and the route, and follows each shipment to the warehouse. Reads the suppliers, orders, receipts, bank accounts and exchange rates a dossier names; changes nothing outside Foreign Trade. |
| Online store manager | Runs the online store: sets it up, chooses what it sells, and keeps the products’ photos and translated names that buyers read. Reads the products, the stock, the price lists and the organization profile; changes nothing outside the Online Store. |
Each one already carries the permissions its job needs, including the read access its screens rely on — a cashier can see the products on the till, a sales clerk the clients on a quotation — so assigning the role alone is enough to get someone working.
A built-in role speaks your language. Its name and its details are the app’s, so a French screen lists Caissier and Responsable des ventes, an Arabic one أمين الصندوق and مسؤول المبيعات, and everyone in the organization reads them in the language they chose — whatever language the organization was set up in.
A built-in role is marked System in the list. You can open it to read what it grants, change its Priority, or switch it off with Active, but you cannot rename it, rewrite its details or delete it — singly or in a selection. If your team calls a job something else, or needs a different mix of permissions, create a custom role for it.
All other roles — “Warehouse supervisor”, “Head baker”, whatever your team needs — are yours to create from Settings → Roles.
Custom Roles
On the Roles list, System = No in the filter panel is your custom roles only; the panel also takes Active and a Priority range (Working with lists).
Create custom roles to match how your organization actually works:
- Go to Settings → Roles and click New.
- Give it a name (e.g., “Warehouse Supervisor”) and optional details explaining what this role is for.
- Save. The role now has a Permissions tab beside its details.
- Open that tab and tick what the role may do. Permissions are grouped by module, so you can expand a module to see its resources and actions, tick them one by one, or use Grant all and Revoke all for the whole module at once. Each tick takes effect immediately — there is nothing further to save.
There is no limit to how many custom roles you can create.
Designing Good Roles
A few guidelines for building a role structure that scales:
- Name roles after job functions, not people — “Warehouse Supervisor” is better than “Ahmed’s Role” because it remains meaningful as people come and go.
- Start narrow, then expand — it is easier to grant additional permissions later than to realize someone had too much access. Begin with the minimum a role needs and add more if users report they cannot do something.
- Avoid one-role-per-person — if every user has their own custom role, you have effectively recreated per-user permissions and lost the benefit of roles. Aim for 5-15 roles for a mid-sized organization.
- Use descriptive names — “Quality Inspector” tells you exactly what this role is for. “Role 3” does not.
- Include the lists its pages pick from — a page’s fields pick from other kinds of record: an order names its supplier and its warehouse, an import programme’s lines their unit of measure. Give the role View on each of those too. Without it, the field reads You do not have permission to view this list and offers nothing. The built-in roles already carry them.
Assigning Roles to Members
- Go to Settings → Members.
- Find the user and click to edit their role assignments.
- Assign one or more roles.
- Optionally set valid from and valid until dates to make the assignment temporary — useful for covering someone on leave, granting elevated access for a project, or onboarding with time-limited training access.
A user can hold multiple roles at the same time. Their effective permissions are the combination of all of them.
Effective Permissions
A user’s effective permissions are the union of all their active role assignments. If Role A grants “View Products” and Role B grants “Create Products”, the user can do both.
There is no conflict resolution needed at the role level — permissions are purely additive. A role can only grant access, never deny it. If you need to restrict something that a role allows, that is where Policies come in.
Checking Effective Permissions
To understand what a specific person can do, open one of their assignments from Settings → Members and switch to the Effective Permissions tab. It answers the question directly rather than leaving you to add up their roles by hand — see Members.
Remember: Roles are just the first layer. Even if a role grants a permission, it can be further restricted by policies, row access rules, or field rules.