A fixed border booth usually sits on a dependable wired network. A roaming officer at a port, on a train or at a temporary crossing does not. Yet the expectation is the same: check the document, verify the traveller, consult the relevant systems and record a decision — consistently, and with a complete audit trail.
Designing for that reality starts with an uncomfortable question: what should the workflow do when the network is gone?
Decide what must work offline — and what must not
Not every step can or should run without a connection. Reading a document’s machine-readable zone and chip, capturing a facial image and running local quality checks can all happen on the device. Queries against live watchlists and national registries generally cannot, and pretending otherwise creates risk.
We start every mobile workflow with an explicit capability matrix: for each step, is it fully available offline, available with reduced assurance, or unavailable? That matrix becomes a design artefact the authority signs off — not an implementation detail discovered in the field.
Make reduced assurance visible
When a check could not be completed, the officer has to know immediately and unambiguously. The interface should distinguish between a verified result, a result pending synchronisation and a check that was not performed. Colour alone is not enough: wording, iconography and the decision options available should all change.
Synchronise like it matters
When connectivity returns, queued transactions are sent to the backend. This is where many systems quietly lose data. The patterns we rely on are well established:
- Every transaction carries a unique, client-generated identifier, so retries are idempotent and never create duplicates.
- Queued records are encrypted at rest on the device and removed only after the server confirms receipt.
- Deferred checks are re-run server-side, and any new result is routed for follow-up rather than silently attached to a closed record.
- Device and server timestamps are both kept, so clock drift is recorded rather than trusted blindly.
Treat the device as part of the system
A handheld that holds traveller data offline is inside the security boundary. Device management, strong local authentication, remote wipe and minimal retention are not optional extras; they belong in the architecture from the first workshop.
Offline capability is not a feature you add at the end. It shapes the data model, the interface, the integration contracts and the operating procedures.
Treating it as a first-class design concern is what allows a mobile checkpoint to be as dependable as a fixed one.