Roles, permissions and per-user module restriction
How Winlium decides who sees a module and who may do what: licence, company module switch, per-user restriction and role permissions, plus standard roles, seats and how to build a custom role.
In one minute
Winlium checks four things before a user can use a module: your licence, your company's module switch, the user's own module restriction, and the permissions in the user's roles. Roles are bundles of permissions. A user can hold several roles.
Why Winlium has it
Staff should see only the work they do. Each layer is held by a different person: Winlium's licence by us, the module switch by your company administrator, the restriction and roles by whoever manages users.
How it works in Winlium
The four layers
| Layer | Set in | Effect when it says no | Message |
|---|---|---|---|
| 1. Licence | Your Winlium licence | Nobody in your deployment can use the module. | The 'expense' module is not enabled on your current license. |
| 2. Company switch | Modules | Hidden and blocked for everyone in the company. | The Expense module is not enabled for your company. |
| 3. User restriction | Module Access on the user | Hidden and blocked for that user, whatever their role. A red Restricted badge shows. | You don't have access to the Expense module. Contact your administrator. |
| 4. Role permission | Roles | The module is hidden until the user holds at least one permission for it. Single actions fail with a permission message. | You don't have permission to do this. Missing permission: '…'. Ask an administrator to grant it to your role under Admin → Roles, then try again. |
SUPER_ADMIN skips layers 2, 3 and 4. The company owner cannot be restricted. Home and My Approvals are always available. Layers 2 to 4 also hide the module from the menu.
How a permission is written
A permission has three parts: module:resource:action, for example expense:expenses:create. The first part is the module key (Purchase is procurement, Point of Sales is pos, Reports is reporting).
| Action | Plain meaning |
|---|---|
| read | Open and list records. |
| create | Add a record, and run actions sent as a "do this" request: submit, post, process, disburse. |
| update | Edit a record, and a few actions sent as an edit. |
| delete | Remove a record. |
Winlium builds the action from how the screen talks to the server, so there is no separate "post" or "approve" word in most cases. Read the exact string on Permissions (a read-only list with search). A few special permissions use words such as manage or override.
Approving a task from My Approvals needs no module permission. Some modules also have their own approve action, which is checked like any other.
Standard roles
Winlium ships 13 standard roles, shared by all companies. Every one also holds two read-only basics: company settings and a single requisition. "Holds" below is computed from the live role list.
| Role | What it covers | Holds permissions in |
|---|---|---|
| Accountant | Day-to-day accounting: invoices, payments, receipts, supplier bills and returns, journals, cash book, budgets, bank reconciliation. | accounting, admin, reporting, requisition, transaction |
| Finance Admin | The rules postings follow: chart of accounts, account and transaction types, taxes, financial years, currencies, accounting and consolidation settings. | accounting, admin, requisition |
| Purchase Manager | All of Purchase, plus supplier bills and returns, and viewing items and stock. | procurement, accounting, admin, inventory, requisition, transaction |
| Sales Manager | All of Sales, plus viewing items, stock, customers and invoices. | sales, accounting, admin, inventory, requisition, transaction |
| Inventory Manager | All of Inventory, stock requests, inventory settings. | inventory, admin, procurement, requisition, transaction |
| CRM Manager | All of CRM, plus viewing customers and prospects. | crm, accounting, admin, requisition, sales |
| Project Manager | All of Projects, plus viewing items, stock and cost centers. | project, accounting, admin, inventory, reporting, requisition, transaction |
| HR Manager | The HRMS settings page only. No HRMS records. | admin, requisition |
| POS Manager | All of Point of Sales and its settings, plus viewing items and stock. | pos, admin, inventory, reporting, requisition, transaction |
| POS Cashier | Tills and orders only. | pos, admin, requisition |
| Company Admin | Users, role assignment, org unit grants, company settings, module switches. Can read roles but not change them. No business modules. | auth, admin, requisition |
| Reporting Analyst | Read-only on reports and transactions. | reporting, transaction, admin, requisition |
| Owner | Everything except Maintenance, Survey and a few Authentication items. Can create and edit company roles. | all other modules |
Three special roles are not in that list. SUPER_ADMIN is Winlium staff: every permission, no limits. TENANT_ADMIN passes permission checks inside its own tenant. MEMBER holds nothing: a user with only this role sees the Home page with "Welcome — your account is being set up".
Custom roles, Restore defaults and overrides
Standard roles are platform-wide, so only SUPER_ADMIN can edit them or use Restore defaults (a company administrator gets "Only SUPER_ADMIN can edit platform-wide roles"). Use Duplicate role to copy one into your company, then edit the copy. A copy is not kept in step with the original. A custom role cannot be deleted while anyone holds it.
The Permissions tab on a user can add or remove single permissions for that user in that company. Only Owner and SUPER_ADMIN hold this. Groups only gather users. They carry no permissions.
Seats
A seat is one user with an active company membership whose status is Active or Invited. SUPER_ADMIN is not counted. The limit covers all companies in your deployment. A pending invite reserves a seat. At the limit, Winlium refuses to create, invite or reactivate a user: "All N user seats are in use. Deactivate a user or request more seats before adding another." Deactivate frees the seat and keeps history.
Delete is stricter. You cannot delete yourself, the SUPER_ADMIN user or a user from another company. A user who has signed in cannot be deleted: "This user has signed in, so their history is linked to them. Deactivate them instead — it frees the seat and keeps the records." You cannot change your own roles or module access.
Example
Example only. Amaka is a site engineer at a Lagos construction firm. She must submit expense claims.
- Only Owner holds Expense permissions today, so the administrator cannot give her a standard role. The administrator builds a custom role (steps below).
- Tick the permissions the claim screens need:
expense:expenses:create,expense:expenses:update,expense:expenses:read,expense:expenses-submit:create,expense:expenses-my-expenses:read,expense:policies-my-policy:read,expense:categories:readandadmin:expense-settings-me:read. - The New Expense form also loads lists from other modules: currencies, branches, departments, cost centers, taxes. Without read permission for them those lists come up empty. Add what your claims need.
- Check Modules has Expense on and Amaka's Module Access does not show Restricted for Expense.
Create a role and give it to a user
Open Roles
Go to Roles and select the new-record button at the top. The page is Create Role.Choose the scope
Leave Current Company selected. Platform-wide is for SUPER_ADMIN only.Name it
Type a Role Name.Pick permissions
Tick a module header for everything in it, or expand it and tick single items. Use Search permissions... to find one.Save
Select Save. The message is "Role created successfully".Assign it
Open User Management, open the user, select Add role in the Roles section, choose the role, then select Save.
| Field | Type | Required | Details |
|---|---|---|---|
| Role Name | Text | Yes | Error if empty: "Role name is required". Error if the name exists in the same scope: "Role "X" already exists in this scope". |
| Current Company | Choice card | Yes | The role is visible only to the active company. Error if no company is chosen: "Select a company in the top-right dropdown before creating a company-scoped role." Default: Selected |
| Platform-wide | Choice card | No | SUPER_ADMIN only. Fixed once the role is saved. |
| Permissions | Tick list by module | No | A role with none grants nothing. |
To restrict a user from a module, open the user, go to the Defaults tab, find Module Access, switch the module off and select Save module access. Only modules enabled for the company are listed.
| Field | Type | Required | Details |
|---|---|---|---|
| Module Access | One switch per module | No | Off means restricted. Locked messages: "You cannot change your own module access." and "The company owner and platform/tenant administrators cannot be restricted." If every switch is off: "Every module is restricted — this user will only see Home and My Approvals." Default: On (allowed) |
Screenshot pending
Create Role page with the Scope cards, Role Name field and the module permission picker
- 1Scope
- 2Role Name
- 3Permissions picker
Reading the "who can do what" tables
Other module guides build their role tables from the live permission list. A tick means a standard role holds that permission by default. Your company may have changed a role, so check Roles for the real position.
Where it applies
- Every module. Row-level limits by branch or warehouse are separate: see Org unit access scoping.
- Approvals: Working with approvals and Workflows and approvals.
- Moving between companies: Choose a company.
- Expense setup and claims: Expense.
Common mistakes
- Switching a module on in Modules and expecting staff to see it. They also need a role permission.
- Editing a standard role as a company administrator. Duplicate it instead.
- Deleting a user to free a seat. Deactivate instead.
- Forgetting that a pending invite uses a seat.
- Giving MEMBER to someone and expecting access. It is a waiting state.
- Restricting a user from Administration and then wondering why Expense Settings or the New Expense form fails: those screens belong to Administration.