Managing Roles

Purpose: Roles & Permissions is where you control what each type of user can see and do in PMSuite. Every role has a full permission matrix covering the Sales, Projects, HR, Finance, Workspace, and Other module groups, and every module in that matrix can be tuned independently for the view, create, edit, and delete actions. Managing roles means keeping that matrix accurate and making sure each user is on the role that matches their job.

Who can use it: Administrators. Roles & Permissions sits in the organization settings area, so access follows the same permission model it configures.

How to Access

Navigation: Sidebar → Settings → Roles & Permissions

Direct URL: /account/settings/role-permissions

The Settings hub itself is at /account/settings, which opens on Company Settings; pick Roles & Permissions from the settings sidebar to get to the permission matrix.

How the Permission Matrix Works

Each role has its own matrix. The matrix is organised into six module groups:

Within each group, you set a permission level per module and per action.

Permission Levels

PMSuite uses four permission levels rather than simple on/off switches. Each one narrows which records the action applies to:

These levels are set independently for view, create, edit, and delete. That means a role can, for example, view All records in a module while only being able to edit the ones it Owns.

For a fuller walkthrough of the levels with examples, see Permission Scopes. For guidance on tuning individual toggles, see Custom Permissions.

Editing a Role's Permissions

1. Go to Settings → Roles & Permissions (/account/settings/role-permissions).
2. Select the role you want to change.
3. Work through the module groups and set the permission level for each action you want to adjust.
4. Save the role.

Changes apply to every user currently on that role, not just one person. Before you change a role, be clear about who is on it.

Permission changes don't always take effect on a session that is already active. After saving, have affected users log out and log back in — see Troubleshooting below.

Assigning a Role to a User

Roles are assigned per user on the employee record, not from the Roles & Permissions page. The employee list shows a User Role column alongside Employee ID, Name, Designation, Email, Reporting To, and Status, so you can see at a glance who is on which role.

• When adding someone: set the role as part of the Add Employee flow, or when the invited user is set up through the Invite Employee email flow. See Adding Employees and Inviting Employees.
• For an existing user: open their employee record and change the User Role there. See Employee Profile.
• For clients: client access is controlled on the client record itself (including the Login Allowed toggle), not from the employee list. See Clients.

Roles and Other Settings

A few settings elsewhere in PMSuite reference roles directly, so keep them in mind when you restructure:

• Module Settings toggles each module per user type — Admin, Employee, Client — independently of the permission matrix. A module hidden there stays hidden regardless of role permissions. See Module Settings.
• Custom Link Settings adds navigation links with a "Can Be Viewed By" role selector; the link only appears for the selected role(s). See Custom Links.
• Time Log Settings sends the Daily Timelog Report to a selected role. See Time Log Settings.
• Performance goals (Individual, Department, Company) each have separate View and Manage permission controls. See Performance Settings.
• Dashboards — the Advanced Dashboard is permission-gated, while the Private Dashboard shows only the logged-in user's own data. See Advanced Dashboard.

Limitations and Workarounds

• Roles are assigned one user at a time. There is no bulk role-change action in the roles UI. Workaround: plan the change first, then work down the employee list and update each User Role in turn.
• Two separate gates control module visibility. Permission matrix and Module Settings both have to allow a module. Workaround: when a module is missing for a user, check both before assuming the role is wrong.
• Permission levels are record-scoped, not field-scoped. You control which records a role touches, not which fields within a record. Workaround: where a module is too sensitive to open partially, set it to None and route requests through a role that has access.
• Admins cannot remove their own administrative access. PMSuite blocks a change that would lock the acting admin out of Roles & Permissions. Workaround: if you intend to demote an admin account, do it from a second admin account.

Troubleshooting

A user says they still can't see a module after you granted permission. Check two things, in this order:

1. Confirm the change was actually saved for the right combination of role, module, and action. It is easy to set the level on a neighbouring row.
2. Have the user log out and log back in. Permission changes don't always take effect on a session that was already active.

This is the first check for any "can't see X" report — verify Roles & Permissions before investigating anything else.

A user can see records but can't edit them. View and edit are separate actions with separate levels. A role set to view All but edit Owns behaves exactly this way. Adjust the edit level for that module.

A user sees fewer records than expected. The permission level is probably Added or Owns rather than All. Those levels filter by who added or was assigned the record, so the list looks empty or short even though the module is open.

A view-only role appears able to change things. Confirm the edit and delete levels are set to None for the modules in question — view level alone does not restrict them.

Related Articles

• Understanding Roles
• Custom Permissions
• Permission Scopes
• Module Settings
• Security Settings
• Adding Employees
• Employee Profile
• Sidebar Navigation