The Attempts That Never Became a Record
A refused clock-in is not nothing happening. It is a row, carrying where the phone thought it was, how sure it was, how far that put the employee from their nearest site, and which of eight refusals applied — and one particular combination of those fields is the first thing HR is shown.
Most attendance systems record the hours people worked. This one also records the moments somebody stood at a door and was told no.
Every clock-in and clock-out attempt writes a row before it returns an answer. Not the successful ones — all of them. A row is written when the employee has not enrolled a device, when the location reading is too vague to use, when they are two hundred metres from the nearest depot, and when everything worked. The row carries the evidence the decision was made on, not a summary of it.
What is on the row
- Who and which event — the employee, and whether they were clocking in or out.
- Where the device said it was — latitude and longitude as submitted.
- How sure the device was — the accuracy the phone reported, in metres.
- How far that put them — the computed distance to the site involved, worked out on the server.
- Which site, where one was resolved.
- Whether a valid site code was scanned, independently of whether the location check passed.
- Which enrolled credential signed the attempt, where the device check got that far.
- The verdict and, when refused, the reason — the same sentence the employee was shown.
The reason is the message, not a code
The stored failure reason is the text the employee read on their phone — "You are 214m from Mombasa Depot (your nearest assigned site)", "GPS signal too weak (±180m)", "register a device from your attendance portal first". Reviewing a refusal a week later means reading exactly what the person in front of the door was told, which removes an entire category of argument about what happened.
Eight ways to be refused
The refusals happen in a fixed order, and knowing the order tells you what a given failure rules out. Anything after the third refusal means the device check passed, so the person and the phone are established; the disagreement is about place.
| # | Refusal | What it tells you |
|---|---|---|
| 1 | Verification not enabled for this employee | They have never enrolled a device, or HR switched them off. An onboarding matter, not an attendance one. |
| 2 | No device response supplied | The attempt reached the server without an assertion — an unenrolled browser, or a request built by hand. |
| 3 | The device response did not verify | A signature that did not check out. Rare, and worth looking at when it repeats for one employee. |
| 4 | No coordinates supplied | The employee is assigned to sites and location was refused or unavailable on the device. |
| 5 | Location accuracy worse than 100m | A weak fix. Usually indoors. The most common refusal in practice, and the least interesting. |
| 6 | Out of range, but a valid site code was scanned | The one that needs a person. Presence proved by the code, contradicted by the phone. |
| 7 | Out of range, no valid code | They are where the phone says they are, and it is not at work. |
| 8 | Site requires a code and none was valid | In range, at a site that asks for a code, without one. Usually a scan that failed rather than an absent employee. |
Refusal six is the only one where the system is telling you it might be wrong.
Why the review screen opens on refusal six
The verification log is read-only and gated by the permission to view attendance. It offers three filters — everything, every failure, and the ones that need review — and it opens on the last of those, with counts for all three shown beside it.
The needs-review filter is a single condition: the attempt failed, and the site code it carried was valid. That combination is the system saying two of its own inputs disagree. The employee scanned a code that only exists at the door of a site they are assigned to, and the phone in their hand reported a position outside that site's radius. One of those is wrong, and the code is the harder one to fake from a distance.
The clock-in was still blocked, because location is a mandatory factor and the system does not resolve its own contradictions in the employee's favour. What it does instead is put the case in front of somebody, with both readings attached, so a correction can be filed and approved by a person who can weigh them.
From a refused attempt to a paid hour
The route back is a regularisation: the employee states the date, the times and the reason; somebody with authority approves or declines it with a comment; and an approval writes the requested values into the attendance record. Nothing about that is automatic, and there is a daily reminder chasing approvals that have been sitting.
Read together, the refusal log and the correction queue are two halves of one control. The log says an hour was claimed and refused, with the evidence. The correction says a named person decided to record it anyway, with a reason. Neither on its own would survive a question about a disputed shift; together they answer it completely.
What AWRA OpsHub does today
- A row written for every clock-in and clock-out attempt, on every one of the nine exit paths, before the answer is returned to the employee.
- The evidence stored rather than summarised — submitted coordinates, reported accuracy, server-computed distance, resolved site, whether a valid site code was present, and which enrolled credential signed.
- The refusal reason stored as the sentence the employee was actually shown, so a review reads what they read.
- A read-only review panel gated by the permission to view attendance, with counts for all attempts, all failures, and the ones needing review.
- A needs-review filter set as the default view, isolating failed attempts that carried a valid site code — the case where the system is reporting a contradiction in its own inputs.
- A correction path where the employee states the times and a named approver decides, with the decision, the decider and a comment recorded, and an approval writing the values into the attendance record.
- A daily reminder chasing corrections that are waiting on a decision.
- Tenant recorded explicitly on every row, including from the public portal where nobody is signed in, so an attempt made without a login still belongs to the right organisation.
More we can add to your workspace
- A regularisation raised straight from a reviewed attempt, pre-filled with the date, the event and the evidence, so the review and the correction are one action rather than two screens.
- A pattern alert across attempts — the same employee refused at the same site every Monday, or a site whose refusals all cite weak accuracy — surfaced without anybody reading the list.
- A per-employee view of their own refused attempts, so somebody can see why their morning failed without asking HR.
- A stated retention period for verification attempts, with the location data ageing out on a schedule an organisation sets.
- An export of the attempt log for a date range, for the occasions when a dispute leaves the building.
- A summary of refusals by reason on the attendance dashboard, turning eight refusal types into a distribution somebody can act on.
Where we point you to a specialist
- We will not let the system resolve a contradiction between a scanned code and a location reading on its own. When two factors disagree, a person decides, and the decision is recorded with their name on it. Automating that would remove the only judgement in the process at the exact moment judgement is what is needed.
- These rows carry where an employee was and how sure their phone was about it. What you may record about staff locations, how long you may keep it and who may read it are questions for your advisers under the employment and data protection law that applies to you. We will hold what you are entitled to hold.
- We will keep the review panel read-only. Editing an attempt would destroy the one property that makes it worth having, which is that it says what happened rather than what somebody later decided should have happened.
Raising a correction directly from a reviewed attempt is the smallest useful piece here, and it removes the retyping that currently sits between noticing a problem and fixing it.
From a list of attempts to a signal
The evidence is already captured on every attempt. What turns it into an operational tool is aggregation and a shorter path from noticing to acting.
One-click correction
A regularisation raised from the attempt being reviewed, carrying the date, the event and the evidence with it.
Refusals by reason
Eight refusal types as a distribution over a date range, per site and per employee, so the cause is visible without reading rows.
A retention policy for attempts
A window you set, after which the location detail on old attempts ages out on a schedule rather than by memory.
We publish scope, not dates.
Scope attendance reviewOur take
Logging failures is unusual and it is the right call, because a control that only records its successes cannot be evaluated. The refusal log is what makes it possible to answer the two questions that actually matter about an attendance system: is it stopping the right things, and is it stopping the wrong ones. Opening the review panel on the contradiction case rather than on the full failure list is the second good decision here — most refusals are a weak signal indoors and need nobody, while the handful where a valid site code disagrees with a location reading need a person that day. What is missing is not evidence. It is the short path from seeing one of those and fixing it, which today is two screens and some retyping.
Five questions to ask about refused clock-ins
Are failed attempts recorded at all?
A good answer sounds like
Yes, with evidence.
What ours actually is
Yes — a row on every attempt, successful or not, carrying the coordinates, accuracy, distance, site, code status, credential and reason.
Can I see why a specific person could not clock in?
A good answer sounds like
The message they saw.
What ours actually is
The stored reason is the sentence the employee was shown, word for word.
What is reviewed first?
A good answer sounds like
The ambiguous cases, not all of them.
What ours actually is
Failed attempts that carried a valid site code, as the default filter, with counts for the other two views beside it.
Can the log be edited?
A good answer sounds like
No.
What ours actually is
No. The panel is read-only. Corrections happen on the attendance record through an approved regularisation, which is its own trail.
Who can see it?
A good answer sounds like
A named permission.
What ours actually is
The permission to view attendance, the same one that governs the attendance records themselves.
Read a week of refusals before changing anything
Almost every proposal to loosen an attendance policy is answered by a week of the refusal log — usually one site with a radius set too tight, or a group who never enrolled. It is the cheapest diagnostic in the module.
Talk through attendance reviewFrequently asked questions
Does a refused attempt create an attendance record?
No. It creates a verification row and nothing else — the attendance record is only written once the check passes. That separation is deliberate: the attendance register holds hours that were accepted, and the verification log holds every claim that was made about them, including the ones that were turned down.
What is the "needs review" filter actually selecting?
Attempts that failed while carrying a valid code for one of the employee's assigned sites. That combination means the code says they were at the door and the phone says they were not, and only a person can decide which to believe. It is the default view because it is the only refusal type that reliably needs somebody that day.
Can HR clock somebody in after reviewing a refusal?
Not directly from the log, which is read-only. The route is a regularisation — the employee requests the times, an approver decides with a comment, and approval writes the values into the attendance record. Raising that request straight from the attempt being reviewed is the one piece of work this article names as missing.
How long are these rows kept?
There is no stated retention window for them today, so they accumulate. Given that each row carries a location reading, an organisation with a data retention policy should treat that as a question to settle rather than a detail — a retention window for attempts is on the list above and is a configuration change rather than a redesign.
Do attempts from the public portal get recorded the same way?
Yes, identically. The public portal is used by staff who have no user account, so there is no signed-in session to take the organisation from — the row records it explicitly instead. That is the reason an attempt made by somebody with no login still lands in the right workspace's log.
Is there a report of refusals by reason?
Not yet — the panel is a list with three filters and counts rather than a distribution. Turning eight refusal types into a chart by site and by week is a reporting change on data that is already fully captured, and it is the fastest way to find the one site or the one cohort generating most of the noise.
