Permissions Overview
CertHub controls what each user may do through roles. A role carries a set of permissions, users are assigned one or more roles, and the permissions of all of a user's roles are combined to decide what that user can do.
This page explains the model. To configure it, see Managing Roles and Permissions. For the full list of predefined roles and their permissions, see the Role Reference.
The six permissions
Every role carries the same six permissions. In the interface these appear under Access Modules when you edit a role:
| Permission | Label in the interface | What it allows |
|---|---|---|
| Read | Read | View an object |
| Edit | Edit/Update | Change an existing object |
| Download | Download | Export or download an object |
| Approve | Approve | Approve an object, and release or publish it |
| Create | Create new | Create a new object |
| Delete | Delete | Delete an object |
Each permission is an independent switch. They are not levels or tiers, so combinations that might look unusual are entirely valid and are sometimes exactly what a quality management system needs. A role can, for example, hold Approve without holding Edit — which describes a reviewer who signs off on content but never authors it.
How a user's permissions are calculated
A user's effective permissions are the union of the permissions of every role they hold. If a user holds two roles and either one of them grants Approve, the user can approve.
Two consequences are worth internalising:
- Roles only ever add. There is no way to write a role that removes a permission another role has granted. To reduce what a user can do, remove a role from that user rather than trying to counteract it with another role.
- Permissions are granted to roles, never to individual users. You cannot give one person an extra permission directly. If someone needs a combination no existing role provides, create a role for it and assign it to them.
Users with no role
A user who holds no roles at all is denied everything, including read access. They will see the message "No access assigned. Contact your administrator".
This is deliberate: access is granted explicitly, never assumed. When you create a new user, assigning at least one role is a required step, not an optional one — see Application Settings & User Management.
Permissions apply organization-wide
A permission a role holds applies to every object of every type, across every module of CertHub. A role with Edit can edit any object anywhere in the application — not a particular product, document, or QM list.
There is currently no way to restrict a role to one specific product, document, or list, and no way to grant a permission for one object type but not another. If you need one group of users to work on a subset of your data and not the rest, the permission system cannot express that today.
Roles do two different jobs
The same roles appear in two places in CertHub, and it is worth keeping the two apart:
- Permissions — what a user is allowed to do, as described on this page.
- Approval routing — which people an approval workflow sends its steps to. An approval step can be addressed to a role, and everyone holding that role receives the task.
These are independent. Addressing an approval step to a role does not grant that role the Approve permission, and granting Approve does not place anyone into an approval workflow. A user who receives an approval task but whose roles do not grant Approve will not be able to complete it, so when you build an approval workflow, check that the roles you route steps to actually hold Approve.
Role administration
Creating roles, changing their permissions, and assigning users are themselves restricted, by a separate setting shown as the Can manage roles badge on a role.
This setting is deliberately not one of the six permissions and cannot be granted or removed through the interface or the API. It is fixed when your organization is set up, where it is held by Admin. This prevents two failure modes: nobody can grant themselves role administration, and — because creating a role named "Admin" confers nothing — nobody can gain it by naming a role suggestively.
CertHub also prevents your organization from locking itself out of role administration:
- The last remaining role that can manage roles cannot be deleted.
- The last user holding such a role cannot have it removed, and cannot be deleted.
Existing and new organizations
How your roles were initially set up depends on when your organization was created.
Organizations created on or after 17 August 2026 start with the predefined roles and the permissions listed in the Role Reference. These are ready to use as they are, and can be adapted at any time.
Organizations created before 17 August 2026 had all six permissions granted to every role, to make the transition to the permission system straightforward: no existing workflow stopped working the day permissions arrived.
If your organization predates 17 August 2026, every role can currently do everything. Your roles are therefore more permissive than the descriptions in the Role Reference suggest, and permissions are not yet acting as a control.
Open Settings → Roles and narrow each role to what its function actually requires — either against the Role Reference or against your own intended matrix. Until you do, assume any user can perform any action.
Auditing
Every role records who created it and who last changed it, with timestamps, shown at the top of the role's detail view. Role and permission changes are therefore traceable for audit purposes alongside the rest of your approval and versioning records.