Field notes › Compliance
Verifying worker certificates: pending, verified, expired
Every worker certificate in your records is in one of three states, whether your system names them or not. It is pending, meaning you have a document but no one has confirmed it. It is verified, meaning someone checked it and stands behind it. Or it is expired. Most compliance messes trace back to firms only tracking one state, a certificate either exists or it does not, and treating existence as proof.
Pending: a document is not evidence yet
A worker sends through a photo of their forklift licence. What do you actually have? A photo. Until someone looks at it properly, you do not know whether it is current, whether the class matches the work, whether the name matches the worker, or whether the image is even readable. Filing that photo and marking the worker compliant is where the trouble starts, because the record now looks identical to one that was properly checked.
The pending state exists to keep those two things distinguishable. An uploaded certificate should sit visibly unverified until a person has reviewed it, and a pending certificate should count as absent for rostering purposes. Harsh, but correct. You would not send a worker to site on the strength of a document nobody has opened.
Verified: someone put their name on it
Verification is a human act, not a filing act. It means a specific person opened the document and confirmed the basics: right person, right qualification, right class, legible, and an expiry date captured into the system rather than left inside the image. Where a licence can be checked against the issuer's records, that check is worth doing for anything high-stakes, and your state regulator can tell you what checking options exist for the licences they issue.
Recording who verified each certificate and when matters more than it seems. When a client auditor asks how you know a licence was sighted, a named person and a timestamp is an answer. A folder of images is a shrug. This is exactly the kind of thing an audit trail is for.
Expired: the state that arrives on its own
Pending and verified change when people act. Expired arrives by itself, on a date that was known months in advance, which makes it the most preventable problem in compliance and still the most common. A verified certificate is not verified forever. The moment its expiry date passes, it proves nothing, and a system that keeps showing it as a green tick is lying to you.
Handling expiry well means two things. The system must know every expiry date, which is why capturing the date is part of verification. And the system must act on approaching dates early enough for the worker to do something about it. Renewals take time to book, especially for workers who are on site more weeks than they are home.
What the workflow looks like when it works
Put together, the workflow is short and repeatable. In Mustr it runs like this:
- The worker uploads their certificate through the worker portal, from any phone, no app to install.
- It lands as pending, clearly separated from verified records.
- An administrator reviews it, and it becomes verified with its expiry date recorded.
- As expiry approaches, the certificate surfaces up to 60 days ahead, with one-click reminder emails to the worker, who uploads the renewal the same way.
The roster enforces the whole thing. Every booking is checked server-side against the worker's competencies before it is made, and a missing, unverified or expired certificate blocks the booking outright rather than raising a warning someone can click past. The three states stop being labels in a spreadsheet and become rules the roster actually obeys.
None of this is complicated. It is just relentless, which is exactly why it should not depend on a person remembering. If your certificate records cannot currently tell pending from verified, book a demo and see it on your own roster.