Access in Limnn is layered so you can be broad where it helps and precise where it matters. Four controls work together: system roles, custom roles, team scoping and field-level security. Every module uses the same permission engine, so a rule you set once applies in the UI, Reports, exports, APIs and what Cortex may read.
System roles
- super_admin - full control of the workspace including roles, billing and security. The workspace owner starts here.
- admin - administers modules, users and settings but is bound by the Super Admin role's protections.
- manager - inherits visibility over the teams they manage (the manager hierarchy) in addition to their own records.
- user - the default for anyone invited without another role; sees their own and shared records.
Permission strings
Capabilities are granted as MODULE:ACTION pairs. Roles hold a set of grants, and code paths call a can() check against them. Examples:
SALES:VIEW
SALES:EDIT
SALES:DELETE
SUPPORT:VIEW
REPORTS:VIEW
SETTINGS:MANAGEBuilding a custom role
- 1Open /settings/roles and choose New role.
- 2Name the role for the job (for example Support Lead) rather than the person.
- 3Tick the module and action grants the role needs; start from view-only and add edit rights as required.
- 4Save, then assign it to users from /settings/users. Users may hold a system role plus custom roles; grants combine additively.
Teams and scope
Teams at /settings/teams define who sees whose records. A rep sees their own and shared records, a manager sees the teams they manage, and admins see the workspace. Scope is applied server-side before data is returned.
Field-level security
Field-level access hides or locks individual fields (salary, margin, national ID) even on records a person may open. Configure it at /settings/field-access; see the Field-level access control article for depth.