Team access for training records: roles, permissions and who can do what
Training admin is almost never a one-person job. The moment a second person touches the register, you need a way to hand out work without handing over everything.
The shared-login problem
Most training providers start the same way: one login, shared by whoever is on shift. It works until the day someone deletes a certificate, or a coordinator leaves and the password has to be changed for everybody, or an auditor asks who amended a record and the honest answer is "one of us".
A shared login is not a small shortcut. It removes the single thing an audit trail is for: attribution. Every entry says the same name, so the log tells you what changed but never who changed it.
Three roles that match how the work actually splits
Roles in Sentinel
- Admin — runs the account: invites people, sets permissions, manages billing and branding.
- Staff — does the day-to-day work: issues certificates, manages client companies, runs bulk uploads.
- Viewer — can look up records and companies but cannot change anything. The right role for a client-facing coordinator or an auditor you want to give read access to.
Roles set the shape; permissions handle the exceptions. Each staff or viewer account carries its own switches for viewing, adding, editing and deleting records, managing companies, running bulk uploads, and reading the audit log. A coordinator who should issue certificates but never delete one is a two-click configuration, not a policy you have to trust people to remember.
Invitations, not shared passwords
Adding someone should not mean typing a password on their behalf and sending it over WhatsApp. In Sentinel an admin enters a name, an email and a role; the person receives an emailed invitation and sets their own password. The admin never sees it, the link expires after seven days, and a pending invitation can be revoked before it is used.
This matters beyond convenience. A password an administrator chose is a password an administrator knows, and any action taken under that account is arguable. A password only its owner has ever seen makes the audit log mean something.
What the audit log then gives you
With named accounts in place, every issuance, amendment, deletion, bulk import and permission change is attributed to a person and a timestamp. When a client asks why a certificate shows a different expiry than the one they remember, the answer is a line in a log rather than a reconstruction from memory.
It also answers the question auditors actually ask, which is rarely "is this record correct?" and almost always "how do you know it has not been changed?".
Offboarding without a scramble
When someone leaves, disable their account. Their history stays intact and attributed — the record of what they did does not disappear with their access — but they can no longer sign in. No shared password to rotate, no wondering which systems they still reach.
A practical starting point
- One admin, plus a second admin so nobody is locked out when the first is on leave.
- Coordinators as staff, with delete permission switched off.
- Anyone who only needs to look things up as a viewer.
- Review the member list whenever someone joins or leaves — it takes a minute and it is the whole of your access control.
Seats and plans
Team size is part of the plan rather than an add-on you negotiate. The team screen shows seats used against seats available, and counts pending invitations against the total so an account cannot be quietly oversubscribed by sending several invitations at once.
Book a demo — see roles and permissions on your own register →