Permissions in Cargolake are built from two layers. Understanding them makes the difference between "the button is missing" and "I know why the button is missing".
1. Abilities
An ability is a single permission, written as an action on a subject:
readonInvoice·createonShipment·approve-style actions likesubmitonPayment Request
Subjects are the things the system manages — there are around eighty of them, from Lead and Quotation through Bank Statement Line and Posting Rule. Actions are mostly the familiar four:
| Action | Meaning |
|---|---|
read | See it in lists and open it |
create | Make a new one |
update | Change an existing one |
delete | Remove it |
manage | All of the above, including actions added in future |
Some subjects add verbs of their own, because the operation is not plain CRUD — convert on a lead, split and merge on shipments, transit on a transition, execute on a workflow, rollback on a journal, revoke and assign on roles, generate document, calculate, publish, process, restore.
A handful of subjects are deliberately narrow. Own User and read-own cover the things everyone may do to their own record — reading their profile, changing their own password — without granting access to anyone else's.
Abilities themselves are fixed by the system. You cannot invent a new one; you choose from the list.
2. Roles
A role is a named bundle of abilities — Quotation User, CRM User, FCL Admin. Users are given roles, not individual abilities.
When you build a role you see abilities grouped by subject, one card per subject. Ticking the box on the card header grants manage on that subject; ticking individual actions grants just those. The distinction matters:
- manage is open-ended. If a new action is added to that subject later, holders of
manageget it automatically. - A list of specific actions is closed. New actions are not granted until you edit the role.
For a genuinely restricted role — an outside bookkeeper, a temporary contractor — list the actions explicitly rather than granting manage.
A user can hold several roles. Permissions add up; there is no "deny" that overrides a grant. If someone can do something you did not expect, look for a second role.
Roles also carry a level, where lower numbers mean more senior. It is enforced: nobody can assign or revoke a role more senior than their own, so permissions cannot be escalated sideways by someone who happens to be able to manage roles.
Some of the roles in your company arrive ready-made, set up when it was created. Those are maintained centrally and cannot be edited here — build your own alongside them if they do not fit. See Building roles.
What this means in practice
A menu entry is missing. You lack the ability behind it. The sidebar hides what you cannot reach rather than showing you a locked door.
A change to your roles has not taken effect. Your permission list is cached in the browser at sign-in. Sign out and back in.
A page loads but an action fails. Permission is checked twice: once to decide what to show you, and again on the server when you act. The second check is the real one. A stale cached list can show you a button that the server then refuses — again, sign in afresh.
Nobody can grant what they do not have. Assigning roles is itself an ability (assign and revoke on Role). Administrators can only hand out permissions their own role permits them to manage.
Last updated 9 September 2026