When connectivity disappears, what work is the user still authorized to complete?
REFERENCE PROCESS / CONCEPTUAL
01 / ENGINEERING NOTE
Begin with the unit of work
A field technician may need to open an assignment, record observations, capture photographs, and finish a local draft. Those are different promises from submitting a legally binding approval. The offline boundary should list safe local actions separately from transitions requiring fresh server authority.
Model the exact transaction, not whether an HTML page can load offline.
02 / ENGINEERING NOTE
Separate local durability and shared truth
Local persistence protects work against a network outage; synchronization makes the work visible to other actors. Each operation needs a stable identifier, local state, a durable queue and a visible pending/confirmed/rejected status. A network retry must not silently duplicate a consequential action.
Treat an offline completion indicator as local completion unless confirmation is actually received.
03 / ENGINEERING NOTE
Conflict handling is domain logic
A last-write-wins timestamp is convenient but can destroy evidence. Independent field entries may merge safely; conflicting approval decisions often cannot. Define versions, authority and human resolution paths by record type before choosing a synchronization library.
Practice concurrent edits and role revocation in testing.
04 / ENGINEERING NOTE
Design rejection and repair
A queued action may fail because policy changed, a referenced record was removed, or authorization expired. Recovery must preserve the original evidence, explain what failed, and offer a reversible repair where possible. Operators need a way to reconcile without bypassing controls.
The recovery screen is part of the product contract.
These notes describe design reasoning, not a product certification or client deployment.
← Back to all insights