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 look up the permission a particular action needs, see Which Permission Do I Need?. To configure roles, 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.
CertHub checks the two against each other when a workflow starts: if a reviewer you name does not hold Approve through any of their roles, starting the workflow is refused and the reviewers concerned are named, rather than the process stalling later at a step nobody can complete. If you see that message, either assign those users a role that grants Approve or route the step to someone else.
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. These guards look at the Can manage roles setting, not at the role's name, so they still apply if you rename Admin:
- 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. The attempt is refused with "Cannot remove the last Admin. At least one Admin per organization is required."
It also makes sure every user keeps at least one role, so nobody ends up as a member who can do nothing:
- A role that is still assigned to users cannot be deleted. Remove the users from the role first.
- A user's last remaining role cannot be removed — neither from the user, nor by taking the user off the role. Assign them another role first.
Besides the predefined roles, every organization contains one reserved system role, InternalAutomation, which CertHub uses for its own automation. It cannot be modified or deleted, is reserved for CertHub, and should not be assigned to people — see the Role Reference.
Existing and new organizations
New organizations 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 that existed before role permissions were introduced have all six permissions on every role, so that no existing workflow stopped working when permissions arrived.
If your organization predates role permissions, every role can do everything, and permissions are not yet acting as a control. Review your roles and narrow each one to what its function actually requires — either edit them yourself in Settings → Roles, or ask CertHub support to apply the default matrix from the Role Reference for you. Applying the default matrix can remove permissions your users currently rely on, so check it against how your teams work first.
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.