Custom Permissions
Roles decide who a user is; custom permissions decide what that role can actually do and see. In PMSuite, permissions are configured on the role, not on individual people — you edit a role's permission matrix, and every user assigned to that role inherits the result.
What makes PMSuite's matrix different from a simple on/off checklist is that each permission is a level, not a switch. Instead of only choosing whether a role can view tasks, you choose which tasks it can view: none, only the ones it added, only the ones it owns, or all of them.
Who can use it
Company Admin. Permission configuration lives in the company settings area and is not available to employee or client roles.
How to Access
Sidebar → Settings → Roles & Permissions (/account/settings/role-permissions).
Open the role you want to configure to load its permission matrix.
Understanding the permission matrix
The matrix is organised by module group:
- Sales
- Projects
- HR
- Finance
- Workspace
- Other
Within each group, every module exposes four actions you can control independently:
| Action | What it governs |
|---|---|
| View | Seeing records in that module |
| Create | Adding new records |
| Edit | Changing existing records |
| Delete | Removing records |
The four permission levels
For each module + action pair you pick one of four levels. This is the core concept of the whole feature.
None
The role cannot perform that action at all. Setting View to None is how you effectively hide a module from a role.
Added
The action applies only to records that user personally added. A user with Added edit rights on Leads can edit the leads they created, and nobody else's.
Owns
The action applies only to records assigned to that user. Useful for "you can work on your own caseload, not the whole company's" setups — for example a team member editing only the tasks assigned to them.
All
The action applies to every record in that module, company-wide. Reserve this for genuinely company-wide roles.
Because levels are set per action, you can mix them freely. A common shape is View: All combined with Edit: Owns — the role can see the full picture but can only change its own work.
Configuring permissions
- Go to Settings → Roles & Permissions (
/account/settings/role-permissions). - Open the role you want to change.
- Find the module group (Sales, Projects, HR, Finance, Workspace, Other) and then the module inside it.
- For each of View, Create, Edit and Delete, choose the level: None, Added, Owns or All.
- Save the role.
- Ask affected users to log out and log back in (see below).
The log-out / log-in rule
This is the single most important operational detail on this page.
Permission changes are not always picked up by a session that is already active. A user who was logged in while you edited the role may keep seeing the old access — or keep missing the new access — until their session is refreshed.
So after any permission change, tell the affected users to log out and log back in. If you are troubleshooting a "they still can't see it" report, do this before assuming the setting itself is wrong.
Limitations and workarounds
Permissions are role-level, not per-user. There is no per-person override; two people on the same role always have identical permissions. Workaround: create an additional role with the exact matrix you need and assign that individual to it. See Managing Roles.
Levels are record-scope, not field-scope. Added / Owns / All filter which records an action reaches. They do not hide individual fields inside a record the user can already view.
Active sessions can lag behind. Covered above — a saved change may not reach a logged-in user until they re-authenticate.
Hiding a module from a whole user type is a different setting. If you want a module gone for all clients or all employees regardless of role, that belongs in Module Settings, which toggles modules per user type (Admin, Employee, Client).
Troubleshooting
"An employee can't see a module I gave them access to." Work through it in this order: (1) confirm the change was saved against the right role, and the right module + action combination — it is easy to set create when the user needs view; (2) confirm the user is actually assigned to that role; (3) have them log out and log back in. For any "can't see X" report of any kind, Roles & Permissions is the first place to look.
"They can see the module but the list looks empty." That is usually a level mismatch rather than a missing permission. View: Added shows only what they created, and View: Owns only what is assigned to them — if neither applies to them yet, the list is legitimately empty. Raise the level to All if they need company-wide visibility.
"They can open a record but can't change it." View and Edit are separate actions with separate levels. Check the Edit level for that specific module.
"A user can create records but then can't find them." Check that View is not set to None or to a level that excludes what they just made.