Distinguish local from confirmed state
A device-saved action is not necessarily accepted by the main system. Show pending, accepted and needs-review states. Give outgoing operations stable identifiers so retries do not create duplicate requests. Do not present payments or stock as confirmed when the device only holds a stale local copy.
Choose conflict rules early
Two employees may edit one record while one is offline. Last-write-wins is unsuitable for some data. Important fields may need version checks, field-level merging or an operator decision. Specify how deletion and cancellation behave before synchronisation.
Test interrupted connectivity
Close the app between saving and sending, change users, expire sessions and repeat deliveries. Protect sensitive local records using platform capabilities and agreed sign-out deletion rules. Provide a visible pending-action list and a way to resolve errors. Operators need diagnostic traces without personal-data leakage.
Checklist
- Distinguish pending and confirmed states.
- Make retries safe.
- Agree conflict rules by field type.
- Preserve the queue across app closure.
Project questions
Can every action work offline?
Not necessarily. Current stock, payment confirmation and some permission checks require a server. Restrict these actions or label them as provisional.