TL;DR
Geofenced clock-in is one of the most oversold features in field service software. The honest version is smaller than the pitch and more useful than it sounds: read the position at the instant the button is pressed, send it with the entry, let the server compare it with the job's address, and store the evidence next to the conclusion. Here is each piece, including the two places where the right answer is to record nothing.
The thing that cannot be built
A web app installed to the home screen on iOS does not get position in the background. There is no background geolocation for web apps on that platform. This is not a gap in one product; it is the platform, and it applies to every web app equally.
So: the app does not clock people in automatically when they arrive. It cannot. Anybody selling you that in a web app is selling you something that will not work, or selling you a native app with a battery cost they have not mentioned, or selling you a device in the vehicle, which is a different product with a different price and a different conversation with your staff.
We would rather say that out loud than have you find it in week three.
What is possible, precisely
When the worker taps clock in, the app asks the phone for a single reading. High accuracy requested, no cached position accepted, eight seconds to answer.
Then a belt-and-braces detail worth knowing about, because it is the kind of thing that decides whether the button works on a Tuesday morning: some Android builds never call either callback when location services are off. Not an error, not a success — nothing. So there is a second timeout half a second past the first, and the clock starts regardless.
Which is the design principle underneath all of this: position never holds work hostage.
A denied permission, a phone indoors, a dead GPS chip, a worker who declines the prompt — none of these is a reason to stop somebody starting their day. Every failure resolves to no reading, the clock runs anyway, and the entry is recorded as having no position rather than as having a false one.
Accuracy is rounded up, never down
The phone reports a radius it believes the reading is good to. That number is rounded up before it is sent.
Claiming a reading is better than the phone says it is would put somebody outside a fence they were standing inside. A metre of false precision here costs an argument with an employee, and the employee is right.
The server decides, not the phone
The reading travels with the entry. The comparison happens on the server, against the service address on the work order — which carries coordinates and a fence radius between 10 and 5000 metres, both set on the address in the panel.
The distance is an equirectangular approximation rather than a great-circle calculation. Over a fence of tens of metres the difference is far below GPS accuracy, and this runs on every clock-in.
The reported accuracy is allowed to count in the worker's favour: a phone that says "within 30 metres", standing 40 metres out, is probably there. The fence is widened by the accuracy the phone itself declared, not narrowed by it.
Doing this on the server rather than in the app is not about trust in the worker. It is that the phone does not know the customer's fence radius, the fence can be edited afterwards, and a verdict computed on a device is a verdict that cannot be reproduced later.
Null is not false
This is the most important line in the whole feature, and it is one word.
When there is no reading, or the job has no service address, or the address has no coordinates or no radius, the verdict is stored as unknown. Not as outside.
"No position" and "probably somewhere else" are not the same sentence. Storing the second when you only know the first puts an accusation on a row on the strength of a field the office never filled in — and that row will be read months later by somebody who was not there, in a conversation about somebody's pay.
The distinction has a practical consequence you should plan for: until you have put coordinates and a radius on your recurring addresses, every clock-in records an unknown verdict. That is correct behaviour and it is also a to-do list.
Evidence beside the conclusion
What is stored per entry: the coordinates the phone gave, the accuracy it declared, whether the reading came from GPS or was a manual entry, and separately the geofence verdict.
The raw reading is stored beside the verdict rather than instead of it, because a dispute months later needs the evidence and not our conclusion about it. If the fence radius was wrong, or the address was geocoded to the wrong side of a courtyard, the coordinates are still there and the question can be reopened. A stored boolean with nothing behind it cannot be argued with, which sounds like a feature and is the opposite.
The same principle runs through the timesheet: an entry typed in from the office is recorded as typed in, not silently dressed up as a clock-in.
Two things to say to your staff before you turn it on
This is a workplace surveillance question and treating it as a purely technical one is how it goes wrong.
What is read, and when. One reading, at the instant of the tap, twice a day. Not continuously, not while driving, not while the app is closed — the platform does not even allow the last one. There is no live map of where the vans are, because there is no continuous position to draw one from.
What it is for. The verdict answers one question — was the clock-in at the job — and it exists because the alternative is a customer's word against a crew's. A recorded position is as often the thing that proves somebody was there as the thing that proves they were not.
Say both before the first shift, not after the first question.
Where it sits in the tiers
Position on time entries is part of the middle and top tiers, not the entry tier. The entry tier has scheduling, work orders, time reporting, the field app and the invoice basis; clock-in position and standing agreements start at the middle one.
Setting it up so the verdicts mean something
Four steps, and the first one is most of the work.
Put coordinates on the addresses you visit more than once. A customer address holds a street, a postcode, a city, coordinates, a fence radius and access notes; the access notes are shown only to the office and to the worker booked on the job. In the panel the coordinates can be fetched from the street address via OpenStreetMap, which saves typing them and is worth a glance afterwards, because a lookup can land on the wrong side of a courtyard. Without the coordinates there is no fence and every clock-in there records an unknown verdict, correctly and uselessly.
Choose a radius wider than you think. The minimum the system accepts is 10 metres and the maximum is 5000. Ten is almost never right. A phone indoors in a stairwell, or in a yard between two buildings, reports a position tens of metres out with an accuracy to match. A radius of 100 to 200 metres for an ordinary address catches the case you care about — a clock-in from home, or from the previous customer — without generating a stream of false verdicts on people who are standing in the right place.
Attach the clock-in to the job. The fence belongs to the work order's service address. A clock-in with no job attached has no address to compare against and therefore no verdict, however good the reading was.
Read the unknowns as a to-do list, not as a suspicion. For the first weeks most of them will mean "this address has no coordinates yet". That is a data-entry backlog, and treating it as anything else is how you lose the crew's goodwill in the first month.
The summary, in one paragraph
Position at the tap, sent with the entry, judged by the server against an address you maintain, stored with its evidence, and never allowed to stop somebody working. No background tracking, no automatic arrival, no live vehicle map. It covers most of the value of the thing that is usually sold, and it is a thing that actually exists.