The week
“We don't track location” usually means the app doesn't send it.
Which is a promise made by the part of the system a customer cannot inspect, on behalf of a part they cannot audit, and it survives exactly as long as the next release.
The version that holds is the one where the server refuses the data.
Two settings, not one
Proof of presence and a coordinate are different decisions.
Whether a rep checks in at all, and whether a location is taken when they do, are configured separately. So a workspace can require a check-in — a timestamp, a deliberate act, a record that somebody was there — while capturing no coordinate whatsoever.
Both default to the conservative end, so a workspace that never opens the settings captures nothing.
And when location is off, the coordinates are discarded after the request is read. It is not a flag the app is trusted to honour: a modified client, a replayed request or a bug in a future release cannot cause one to be stored.
- Off—Nothing captured. The default.
- Optional or requiredOffA timestamp and a deliberate act. No coordinate, ever — the server discards it.
- Optional or requiredOptionalA coordinate when the browser offers one, and a visible note when it did not.
- RequiredRequiredA check-in without a coordinate is refused.
- The rep is told the mode before they tap —
Printed on the check-in bar in plain type, along with whether their browser will ask for a location.
- A manual check-in is visibly manual —
The badge says so, rather than looking identical to one taken from satellite — so nobody is silently credited with a precision they did not provide.
- Check-out is always optional —
Even where check-in is required. And it refuses without a check-in first, rather than recording a departure from somewhere nobody arrived.
- Precision is deliberately capped —
Stored at a resolution that identifies a building, not a desk.
- Nothing is captured between the two taps —
There are exactly two moments in this module where a coordinate can be written. Nothing samples, polls, or runs in the background.
Where a coordinate can go
One place, through a link, on a map that is not a surveillance tool.
Opening one specific visit — which writes an audit row the rep can see — and clicking through to an open mapping service, hardcoded with the reason written into the link itself.
It cannot reach anywhere else. There is no mapping library in the product, so there is no canvas to draw a pin on. There is no distance calculation anywhere in the backend, so there is no geofence and no was-he-really-there check to build a dashboard from. And the reporting engine deliberately excludes the coordinates while exposing eight other things about a visit — so they cannot be grouped, charted, exported or emailed on a schedule.
›So we cannot verify attendance?
Correct, and you should plan for that. The location is taken from the device and trusted. There is no accuracy threshold and no spoofing detection. What you get is a deliberate act with a timestamp, not proof.
›Is there a geofence, or an on-site radius?
No geofence. There is a radius setting in the preferences and it is worth being straight about: nothing currently computes with it. Treat it as absent.
›Do photos carry location?
A photo taken on a phone can carry its own embedded location, and the product keeps a file exactly as it was given — it does not strip or rewrite image data. That is deliberate, for the integrity of the evidence, and it does mean a photo can carry more than the visit record does.
›Can we require a check-in but not a location?
Yes. That is the configuration the two separate settings exist for, and it is the one most teams should use.