Clock in app: Start Shift button gone after one tap
On release day 17 staff ended their shift by accident and could not start another. The fix reached every phone without a new app release.
If staff end a shift by mistake in your clock in app and cannot start another, the usual cause is a rule on the server that allows one start a day, combined with a screen where one button turns into another. A slip becomes a lockout. The first check is to end a test shift straight after starting it and see whether the app lets you start again.
Here is how that happened to a field sales team on release day, and how it was fixed without a new app release.
You ship a new version of the field app. By mid-morning the first complaint arrives: the Start Shift button is gone. The man who reported it had started his shift at 09:46, ended it at 10:59, and now could not start another. Until midnight, the app considered his working day over.
He had ended it himself, by accident. He was not alone. Seventeen people ended a shift before 11:47 that morning, against one and two on comparable days, and fourteen of those seventeen did it within ten minutes of starting. That is seventeen people in a field sales team at Aries Agro, a crop-nutrition manufacturer, unable to record their working day until the next morning.
What was actually going on
Two separate things combined.
The new app header used one button that changes in place: after you tap Start, the same spot on the screen becomes End. The old screen had two separate buttons, so a double tap landed on a disabled Start and did nothing. On the new header, the second tap of a double tap ended the shift.
Then a rule on the server made the accident permanent. The server rejected any second start on the same day, with the message that the day’s shift had ended. A harmless slip became a lockout.
We nearly got the size of it wrong. Partway through, one of our own queries converted the time zone twice and made shift starts look as if they had collapsed to 28 a day. The corrected figure was 541 starts before 11:45 against 609 and 640 on the two days before, which is normal. Only the early-end spike was real.
What we changed
The fix went to the server only, with no new app release, because the installed app decides what to show from the server’s answer. If the server returns the open shift, the app offers Start again. All 17 people could start again with no data repair.
While we were there we found that every part of the system that looked up today’s shift took the day’s earliest record. After a stop and restart that is a finished shift, so the code would have ended the wrong one and missed the live one. That was fixed too, along with a count of days present that had been counting shifts instead of days.
We tested start, end, start again, refused while running, end, and a third start, with real requests, on both the test and live systems.
What it did not fix
The single button still invites accidental ends. They are now recoverable, but each one still pollutes the average shift length. Separating the buttons, or ignoring a second tap that comes too quickly, waits for the next app release.
We also changed the database rule to allow at most one open shift per person per day, which is what actually stops double taps and repeated offline uploads. That change is on the test system only. The live database has 852 person-days with more than one open shift and needs tidying first, so the code was written not to depend on it.
How to check your own clock in app
- End a test shift by accident and see whether you can start another. If not, ask who can reopen it.
- After any release that changes what a button does, count early endings on release day and compare with a normal day. A spike was the whole signal here.
- Ask whether the server or the app decides if a shift is open. If the server does, many fixes can reach every phone without a release.
- Ask what happens after a mistake. A rule that says a day can only be started once is reasonable until a phone makes it easy to end one by accident.
Where this ends up
Sazinga Field treats the server as the source of truth for whether a shift is open, which is why a fix could reach every phone without anyone updating the app.