Designing workflows for unreliable connections
Offline is not one state. A workflow can start with a connection, lose it during transfer, return with partial data and still need to finish cleanly.
I developed this review from the content-import work on Kolibri, where educators may be sharing slow connections and every failed transfer costs time and bandwidth. It also applies to field operations, uploads, sync, onboarding and long multi-step forms.
Review the interruption end to end
A connection-loss message is only one moment in the failure. The design quality is determined earlier, when the product decides what to load, what to persist and where a durable checkpoint exists. It is determined again later, when the user returns and the product decides what can resume.
| Workflow moment | Failure question | Design response |
|---|---|---|
| Before starting | Does the user know the size, duration, permissions and connection dependency? | Expose the cost of the action before commitment, including file size or expected data use where relevant. |
| Selection and setup | Will choices survive if the connection disappears before processing begins? | Persist selections locally or server-side before the first network-heavy action. |
| Transfer or processing | Is progress tied to real work or only to elapsed time? | Show completed items, remaining items and the current operation rather than an indefinite spinner. |
| Connection lost | What completed, what paused and what is still safe? | State exactly what was saved. Do not make the user guess whether leaving the page destroys progress. |
| Return and resume | Where is the last durable checkpoint? | Resume from the checkpoint instead of restarting the visible flow from the beginning. |
| Partial success | Can the user distinguish completed, pending and failed items? | Keep successful work, isolate the failed subset and allow targeted recovery. |
| Conflict or duplicate | What happens when the same item exists locally and remotely? | Define a reconciliation rule and show the user when a choice is genuinely required. |
| Final verification | Did the workflow produce a usable result, or did the request merely finish? | Verify the actual outcome: content is available, the record synced or the file can be opened. |
Place durable checkpoints deliberately
A checkpoint is the last state the product can trust after an interruption. It may sit after a saved selection, an uploaded chunk, a completed item or a server acknowledgement. If the team cannot name it, the user will eventually repeat work or create duplicates.
- Name every step that depends on the network.
- Mark the last durable checkpoint before and after each network-bound step.
- Define what survives a browser close, app restart, device restart and expired session.
- Store enough context to resume without asking the user to reconstruct the task.
- Keep the checkpoint model visible to support and operations.
Make partial success a first-class state
Large imports, uploads and sync jobs rarely fail as one indivisible action. A workflow that treats six completed items and one failed item as total failure wastes bandwidth and breaks confidence.
- Preserve every completed item.
- Show the failed subset and the reason at the right level of detail.
- Let the user retry only the incomplete work.
- Prevent the retry from creating duplicates of completed work.
- Keep a result summary the user can return to later.
Use the worksheet
The worksheet turns a workflow into a list of network dependencies, checkpoints, persisted data, user-facing states, resume actions and conflict rules. Review it before high-fidelity design so recovery is part of the flow rather than a late error-state exercise.
A strong interrupted workflow tells the user what survived, what remains and how to continue without paying twice in time or data.