Field notes › Compliance
Compliance blocking vs flagging: why a warning is not a control
Flagging means the system shows a warning and lets the booking go ahead if someone clicks through. Blocking means the booking is refused until the problem is fixed. The difference only shows up under pressure, which is exactly when warnings get dismissed, so a rule you need to hold every time has to be a block at the moment of booking.
Why a warning gets clicked past at 6am
Think about when compliance warnings actually appear. Rarely during a calm afternoon of forward planning. They turn up when someone has called in sick, the bus leaves in an hour and the rosterer is trying to get a replacement to site before the client rings. The replacement is available, knows the site, and the screen says there is a problem with their working at heights ticket. There is a button that says continue.
Most people press it. They are not being careless. The warning asks a tired person to weigh a vague risk against a certain, immediate problem, and the client waiting on the phone feels far more real than a ticket issue that might be a data entry mistake. If the last few warnings turned out to be nothing, the habit is already built. Every warning that proves to be noise makes the next one easier to ignore, and after a few months, continue is muscle memory.
A warning also tells you less than it seems to afterwards. It records that someone saw a problem and went ahead anyway. That helps work out who made the call. It does nothing to keep the worker off site.
What a hard block at booking stops
A block has to live in the right place to mean anything. A pop-up with no OK button is still a check in the browser, and a check in the browser can be missed by a stale tab or two people editing the roster at once. The check needs to run on the server at the moment the worker is assigned, so every route into the roster passes through it.
In Mustr that check runs on the server every time a worker is assigned, and it cannot be clicked past. It asks four questions. Does the worker hold the competencies required for this client, role and shift, current and verified? Is their site induction current? Are they already booked somewhere else? Have they marked themselves unavailable? If any answer is wrong, the booking does not happen, and the reason is shown so the rosterer knows what to fix or who to try next.
The requirements matter as much as the check. A block is only as good as the list it checks against, so set requirements where they genuinely differ, per client site and per role, and on an individual shift when one job needs something extra. A generic list applied everywhere either stops people who are fine or lets through people who are not.
What a block does not do is renew anything. It stops the bad booking. It cannot chase the ticket, and it cannot tell you that a site needs a requirement nobody added.
Handling a genuine exception without switching the check off
The usual objection is that sometimes the office knows the worker is fine. They renewed last week, the card is in their wallet, and the system has not caught up. That happens, and it is a stronger argument for a block than against one, because it tells you the problem is the record.
Fix the record, not the rule. If the worker has photographed the new ticket and uploaded it from their phone, it sits as pending on the office's "to approve" list. Someone checks it against the card, marks it verified, and the booking goes through on the next try. That is a few minutes of work, and it fixes every future booking for that worker, not just this one.
If the record is right and the ticket really has lapsed, there is no exception. There is a worker who cannot go to that site today, and the job becomes finding someone who can. A crew panel showing each person's verified competencies and the dates they are free makes that quicker than arguing with the software.
Watch for the workarounds that quietly switch the check off: removing a requirement from the site to get one person through, or marking an upload as verified without looking at it. Both leave the roster looking compliant when it is not, which is worse than a warning, because nobody can see it. Decide who in the office is allowed to verify tickets, and treat each verification as a decision someone puts their name to.
What an auditor or host client asks afterwards
After an incident, or during a client's contractor audit, the questions are predictable. Was this worker's ticket current on the day they were on site? Who verified it, and when? Could your system have rostered someone without it? What changed on this person's record, and who changed it?
A flagging system can answer the first two and struggles with the third, because the honest answer is yes, followed by a log of warnings someone dismissed. A blocking system answers no and can show why. With an audit trail of who changed what and when, and every certificate held as verified, pending or expired, you can walk a host client through the record behind a single shift without pulling spreadsheets together the night before. The note on proving compliance to a client covers putting that pack together.
Keeping blocks rare
A block that fires every day means the chasing is starting too late. Expiring certificates should be visible well before they bite. Mustr shows them on the dashboard up to 60 days out with one-click reminder emails, and admins choose how many days before expiry the chasing starts. When renewals are handled weeks ahead, the block at booking goes back to being a backstop.
When you look at rostering software, ask to see the moment of failure. Have the vendor book a worker with a missing ticket, live, and watch whether the system refuses or asks you to confirm.
Questions people ask
What is the difference between blocking and flagging in compliance software?
Flagging shows a warning and lets the user continue with the booking. Blocking refuses the booking until the underlying problem is fixed, such as an expired ticket or an induction that is out of date. A block that runs on the server applies to every route into the roster, not only the screen in front of the rosterer.
Should a compliance block ever be overridden?
If the record is wrong, fix the record instead of overriding the check, for example by verifying a ticket the worker has already uploaded. If the record is right, the worker should not be on that shift and the job is finding someone who can go. Overrides that are allowed under time pressure tend to become routine.
What happens when a worker has renewed but the office has not checked the ticket yet?
Until someone verifies the upload it stays pending, and a check that requires current, verified competencies will not accept it. The fix is to work through the list of uploads waiting for approval promptly, especially before a busy rostering day. Once the ticket is verified, the booking can go through.
Do hard blocks slow rostering down?
They slow down the bookings that should not happen, which are the ones worth slowing. When the reason is shown and the crew view makes it clear who is qualified and free, finding a replacement is quick. Chasing renewals weeks ahead keeps blocks uncommon.
To see what happens when a booking fails a check, try Mustr with sample data and attempt to book the wrong worker yourself.