An offline application is a workflow decision before it is a visual feature. A person needs to understand what is saved locally, what reached the server and what still needs attention.
Define the smallest useful offline task
Choose a concrete action that should remain available: reading an assigned task or recording a local update. List the data that action needs and the situations where it must wait for the network. Avoid treating the whole product as one offline requirement.
Separate local and confirmed state
Use distinct states for a local change, a pending upload and a server-confirmed result. A saved indicator should describe what happened rather than suggesting that another person already sees the update.
Decide how conflicts are handled
Imagine that an office operator changes a task while a driver edits the same item offline. Decide which fields can be merged, which change needs review and what explanation the user receives. This is a product rule, not only a storage detail.
Make recovery a normal path
Walk through a dropped connection, an interrupted upload and an application restart. Keep the original action understandable so a retry does not make the user guess whether to repeat it. Define how duplicate submissions are recognized.
Review the whole trip
Test a complete journey from online to offline and back. Include a stale task, a local change and a server rejection. An offline interface succeeds when the user can tell what will happen next, including when a person must resolve a conflict.