Understanding Roles
PMSuite controls what each user can see and do through Roles & Permissions — a full permission matrix that is defined per role. For every role, you set a permission level on each module, independently for each action (view, create, edit, delete). This article explains how that matrix is structured so you can read it correctly before you start changing it.
Who can use it
Roles & Permissions sits in the company Settings area, so it is managed by whoever has access to those settings. Everyone else is affected by the matrix rather than editing it.
How to Access
- Open Settings (
/account/settings). - In the settings sidebar, select Roles & Permissions (
/account/settings/role-permissions).
How the permission matrix is organised
The matrix has three dimensions. Every cell in it is the combination of one role, one module, and one action.
1. Role
Permissions are stored per role, not per individual user. Changing a permission for a role changes it for everyone who holds that role.
2. Module groups
Modules in the matrix are grouped into six areas:
- Sales
- Projects
- HR
- Finance
- Workspace
- Other
3. Actions and permission levels
For each module you set a permission level per action — view, create, edit, and delete. The available levels are:
| Level | What the role can act on |
|---|---|
| None | Nothing. The module/action is unavailable to the role. |
| Added | Only the records that the user personally added. |
| Owns | Only the records assigned to them. |
| All | Every record in the module. |
Because the level is set per action, a role can legitimately have (for example) All on view but Added on edit — able to see everything, but only change what they created themselves.
Reading a permission before you change it
When someone reports "I can't see X," check the matrix in this order:
- Identify the role the user holds.
- Find the module X belongs to (Sales, Projects, HR, Finance, Workspace, or Other).
- Check the action they are blocked on — being unable to open a record is a view problem; being unable to change one is an edit problem.
- Confirm the level.
Noneblocks entirely;AddedandOwnswill show an empty or partial list rather than an error, which is often mistaken for a bug.
Related settings that also hide things
A permission level is not the only thing that can make a module disappear:
- Module Settings turns whole modules on or off independently per user type (Admin, Employee, Client). If a module is switched off there, no permission level will bring it back for that user type. See Module Settings.
- Custom Link Settings entries appear in navigation only for the roles selected in "Can Be Viewed By."
Limitations
- Permissions are role-wide, not per user. There is no per-user override in this matrix. If one person needs a different set of rights, they need a different role — see Managing Roles.
- Changes do not apply to active sessions. A user who is already logged in may keep their old access until they sign out and back in.
- Module Settings is a separate switch. Module Settings turns modules on or off per user type (Admin, Employee, Client). If a module is switched off there for a user type, granting permission in the matrix will not make it appear — enable it in Module Settings first.
Troubleshooting
A user still can't see a module after I granted permission. Two things to check. First, confirm the change was actually saved for the right combination of role, module, and action. Second, have the user log out and log back in — permission changes don't always take effect on an already-active session.
The user can open the module but the list is empty.
The level is probably Added or Owns rather than All. They can only see records they created, or records assigned to them.
The module isn't in the sidebar at all. Check Module Settings — the module may be switched off for that user type entirely, which is independent of the permission matrix.
They can view but not edit (or vice versa). Levels are set per action. Check the specific action column, not just the module row.