Help · How it works

Checking that a check-in came from the office network

LiteEntry compares the address a check-in arrives from with the one the display by that door is using — learned from the display itself, so nothing goes stale.

LiteEntry compares the network address a check-in arrives from with the address the display by that door is currently using. If they match, the phone reached us from the same network as the display; the check has the same three settings as the geofence — Off, Record and Require.

It answers “were they on the office network” without asking the phone anything about itself.

Where the office address comes from

Nobody types it in. The display asks LiteEntry for its next code once per window — every thirty seconds by default — and every one of those requests reveals the address the office is currently going out through, so the office network is learned from the display already sitting in the room.

That is what makes Require safe to use. A list of addresses typed into a settings page is correct until the day the ISP rotates it, and then it locks out a whole site at nine in the morning. A learned address changes when the office changes.

Off, Record or Require

Off — nothing is compared and nothing is collected.

Record — the comparison is made and a mismatch is noted on the check-in. Nobody is stopped.

Require — a check-in that definitely did not come from the display’s network is refused.

“Unknown” is not a mismatch

If the display has not reported in for five minutes, LiteEntry treats the network answer as unknown rather than as a failure, and unknown never refuses anybody.

This matters more than it sounds. A display that lost power or dropped off the Wi-Fi would otherwise take the whole location down with it under Require — every person at that door turned away because of a device none of them can see. The Live page tells you separately when a location’s display has gone dark, so an empty list there does not read as an empty building.

What it catches, and what it cannot

The check catches a check-in made from somewhere that is not the office network: somebody scanning a photographed code from home, or from the coffee shop next door.

It cannot tell one device on the office network from another. A phone on office Wi-Fi and a laptop on office Wi-Fi look identical to it, which is the point — it is a fact about the network, not about the phone.

Two honest cases read as a mismatch and are worth knowing before you set Require. Somebody standing inside the building on mobile data has not joined the Wi-Fi, so their check-in arrives from their carrier. And a site whose guest network goes out through a different address from the wired one will disagree with itself. Record is how you find out which of these your building does, before the setting starts refusing people.

What LiteEntry records

A mismatch is kept on the check-in itself. The day’s row in the attendance report carries a Network mismatch note, the same note travels in the CSV export, and the Review queue shows the row with the address it actually came from.

Under Require the refusal is recorded too, in the Attempts view — the one view that can show a check-in that did not happen. Marking anything reviewed records that an administrator saw it; LiteEntry does not record a judgement.

Using it with a geofence, or instead of one

The network check and the geofence answer the same question by different routes, and they fail in different places. GPS is least reliable exactly where attendance happens — indoors, on a low floor, behind concrete — and the network check does not care. A geofence, in return, works for a site whose Wi-Fi staff are not on.

Running both under Record for a fortnight costs nothing and tells you which one your building actually supports. See what each check does for all three together, or remote check-in, which skips every one of them by design.

Still stuck? Try the demo — most questions here are quicker to answer by pressing the thing than by reading about it.