A field engineer arrives at a remote site, opens an assigned case, and begins reviewing the asset history. Then the connection disappears. In most systems, that is the end of the interaction. A blank screen, an error toast, and a forced restart when the signal returns. The engineer loses the context they had already loaded. They lose any note they had started typing. They lose time.
Latch handles that sequence differently. It does not guarantee that new server data will appear while the device is offline - that would be dishonest. What it guarantees is that the work the engineer already had in hand stays in hand.
Online: The Baseline State
With a live connection, the assigned case loads in full. Customer details, site address, asset information, and the case timeline are all pulled from the server. The engineer can read, add notes, and capture decisions. The mobile view is designed to keep the critical facts above the fold - no collapsing sections that hide the site location or the latest instruction.
Connection Loss: What Stays Visible
When the signal drops, the screen does not go blank. Previously opened assigned cases remain visible from a local cache. The engineer can still scroll through the case details, read the history, and check the customer information that was loaded before the interruption. The interface marks the record as offline and stale so there is no ambiguity: the engineer knows they are looking at a snapshot, not a live record.
Stale markers serve a safety function. If the case were reassigned while the engineer was offline, the cached view would still show the old assignment. The marker tells the engineer to verify before proceeding. That is not a flaw. It is the honest surface the situation requires.
Durable Drafts
Notes are the fastest casualty of a dropped connection. An engineer types a paragraph describing the site condition. The connection fails halfway through. In many field tools, the draft is gone. Latch persists text drafts through connection losses and page reloads. If the engineer closes the browser tab and reopens it, the draft is still there.
Drafts are stored locally and remain tied to the specific case. They do not conflict with server data because they are not yet submitted. The engineer can continue editing offline and submit when the connection returns.
Safe Retries and Idempotent Submissions
When the engineer taps submit after a reconnection, Latch handles the request idempotently. A repeated submission attempt - whether from a retry button or a page reload - does not create duplicate notes. The server recognises the submission as the same action and applies it once. The engineer does not have to check whether the note already landed and does not have to delete a duplicate.
The Boundary: No Fresh Data Without a Connection
This model has a deliberately hard edge. A case that was never opened while the device was online cannot appear from the cache. There is no local store that mirrors the entire assigned queue. The engineer must have loaded the record at least once before the signal dropped. That means arriving at a site without ever having opened the case leaves the engineer without a cached view. The expectation is that brief connectivity at dispatch or during travel is enough to load the day's assignments. That is a tradeoff, stated openly, because it shapes how teams should schedule the first load of the day.
Recovery: From Stale to Live
When the connection returns, the case updates automatically. The stale marker clears. Any new comments, reassignments, or status changes from the operations team load into the timeline. The draft, still present, can now be submitted. The engineer moves from a local, cached view back to the live record without restarting the session. The recovery path is the same surface the engineer was already using. No modal saying "reconnect to continue." No forced logout. The system picks up where it left off.
Continue reading: the field-service release overview, assigned-case access for field engineers, asset context for field service cases.