Managing Roles and Permissions

This page walks through the administrative tasks: creating roles, setting their permissions, and assigning users. For the concepts behind these screens, read the Permissions Overview first. To decide which boxes to tick, look the action up in Which Permission Do I Need?.

Administrators only

Every task on this page requires a role that can manage roles — normally Admin. If you do not hold one, the Add a Role and delete buttons are disabled, with a tooltip explaining that only admins can create or delete roles.

The right to manage roles comes from the Can manage roles flag, which the predefined Admin role holds. It is shown as a chip in the role's detail dialog. It is not one of the six permissions and cannot be granted to, or removed from, any role through CertHub.

Opening the roles list

Go to Settings → Roles. The Roles List shows every role in your organization with its description and the users assigned to it. You can search by name, and sort the list by the date each role was last updated.

If you can manage roles, each row has a pencil icon that opens the role for editing. If you cannot, the pencil is hidden; click the role's name instead to open it in a read-only View Role dialog.

Figure 1: The Roles List, showing the roles defined in your organization

Your organization starts with a set of predefined roles covering common medical device quality management functions. These are listed in the Role Reference. You can rename them, edit their permissions, and assign users to them — they are ordinary roles, not fixed presets.

The exception is a protected role: one that has Can manage roles, is a system role, or is named Admin. Its permissions are locked, and hovering over them shows "This role's permissions are protected and cannot be changed." This stops anyone from removing the permissions of the role that administers all the others.

One role, InternalAutomation, is a system role: it belongs to CertHub's own internal automation, and its user appears in member lists as CertHub Support. Its detail dialog shows a System role badge. It cannot be modified or deleted — saving changes to it is refused with "This role cannot be modified". It is reserved for CertHub and should not be assigned to people. Otherwise you can ignore it.

Creating a role

1. Click Add a Role in the top-right corner of the Roles List.

2. Under Role Data, enter a Role Name and a Role Description.

   Write the description as if for an auditor: state the function the role represents and why it holds the permissions it does. The description is shown in the Roles List and is the only in-product explanation your colleagues will see.

3. Under User Assignment, select the users who should hold this role in the Assigned Users field. You can leave this empty and assign users later.

4. Under Access Modules, tick the permissions the role should grant.

   A new role grants only Read until you tick more

   Read starts ticked on every new role, and its checkbox is locked. The other five permissions — Edit/Update, Download, Approve, Create new and Delete — start switched off. A role saved without ticking anything more lets its users view content but not change, create, approve, download or delete anything. This is intentional — permissions are opted into deliberately — so decide each of the five before you save.

5. Click Add new.

Figure 2: Creating a role — the six permissions appear under Access Modules

Changing a role's permissions

1. In the Roles List, click the pencil icon on the role.
2. Adjust the checkboxes under Access Modules. Read cannot be changed here, and a protected role's permissions cannot be changed at all.
3. Click Save.

Changes take effect for every user holding the role. There is a short delay — normally well under a minute — before the change is enforced across all of CertHub, so a user who is mid-session may briefly still be able to do what you have just revoked.

Revoking permissions affects users immediately

Removing a permission takes it away from everyone holding the role, with no warning to them. Before narrowing a widely-held role, check the This Role is used by panel in the role's detail view to see who is affected.

When you edit a role, the detail view also shows who created it and who last changed it, with timestamps.

Assigning users to roles

You can work from either direction:

• From the role — edit the role and add or remove users in the Assigned Users field. Use this when onboarding several people into the same function.
• From the user — open Settings → Users and change the roles on that user. Use this when one person's responsibilities change. See Application Settings & User Management.

A user can hold several roles, and their permissions are the union of all of them. Assign a second role to add permissions; remove a role to take permissions away.

In the Assigned Users field, a user for whom this is their only role is locked and cannot be removed. Give them another role first.

The last user who can manage roles cannot lose that ability: removing them from their Admin role is refused with "Cannot remove the last Admin. At least one Admin per organization is required." Make someone else an Admin first.

Figure 3: Assigning users to a role

Deleting a role

A role can only be deleted once nobody holds it.

1. Open the role and check the This Role is used by panel.
2. Move any remaining users to another role — from the role's Assigned Users field, or from Settings → Users.
3. Select the role using the checkbox in the Roles List.
4. Click the delete action and confirm.

While a role still has users, its checkbox in the Roles List is disabled, with the tooltip "This role is assigned to N user(s) and cannot be deleted. Remove the users from the role first." (N is the number of users). This is deliberate: deleting a role in use would strip it from its holders as a side effect, and a user whose only role that was would silently lose all access, including read. Moving them off first makes that a decision you take rather than a consequence you discover.

Two further deletions are refused outright:

• The last role that can manage roles, so your organization cannot lose the ability to administer its own permissions.
• Roles marked System role, which belong to CertHub's internal automation.

Deletion is irreversible

Deleting a role permanently removes it and its associated data. Recreating a role with the same name does not restore its previous assignments.

For the same reason, a user's last role cannot be taken away — from either the role screen or the user screen. Give them a different role first, or delete the user.

Designing your role set

A few practices that keep a permission model auditable:

Model functions, not people. A role should describe a job — Risk Manager, SME for Production — so that it stays correct when staff change. Roles named after individuals have to be rewritten every time somebody moves.

Separate authoring from approval. Giving one role both Edit/Update and Approve lets the same person write and sign off their own work. Where your quality management system requires review by a second person, use separate roles and rely on approval workflows to enforce the sequence.

Grant Delete sparingly. Most quality management functions never need to delete anything; superseding a document through versioning is the auditable equivalent and preserves history.

Treat Download as a distinct decision. Download controls export of content out of CertHub. Where the content is confidential, decide it on its own merits rather than granting it alongside Read by habit.

Prefer combining roles over creating variants. Because permissions accumulate, a user who needs the permissions of two functions can simply hold both roles. Creating a merged role duplicates a matrix you then have to maintain in two places.

Checking your own permissions

CertHub greys out actions you cannot perform, so the interface reflects your permissions as you navigate. If a button is unexpectedly unavailable — its tooltip reads "You don't have permission to perform this action" — or a page shows "No access allowed" with "Your role does not have read access to this area, so its content cannot be displayed…", the cause is almost always one of:

• You hold no roles. Ask an administrator to assign one.
• None of your roles grants that permission. Permissions come from roles only, so the fix is a role change, not an exception for your account.
• The permission was recently changed. Reload the page to pick up the current state.

To find out which permission a blocked action needs, look it up in Which Permission Do I Need?.

Administrators can confirm what a user actually holds by opening that user in Settings → Users and checking the roles listed against the Role Reference.