Reliable mobile work depends on what happens to a record when connectivity disappears and returns. An offline-capable application needs the right information on the device, a visible queue for changes, a documented conflict policy and a way to verify the final server record. Test those behaviors before using the workflow in a place with intermittent service.
Define what must work offline
List the tasks workers need to complete: opening assigned jobs, reading instructions, editing fields, taking photographs and collecting a signature may each have different support. Specify which records, related tables and attachments must download before departure. Include login lifetime, available storage and approved local-data protection in the application owner's review.
Microsoft's Power Apps offline-status documentation distinguishes network connection, synchronization in progress, pending uploads and errors. It also requires the initial offline download to complete before relying on the downloaded data. That product-specific example shows why the application's own status is more informative than the phone's Wi-Fi indicator.
Make record states visible
Use the application's actual labels, with a short explanation for workers. The following vocabulary is a planning model, not a claim that every product implements these exact states.
On a narrow screen, scroll the table sideways. Keyboard: focus the table and use the arrow keys.
| Planning state | What it establishes | Next verification |
|---|---|---|
| Saved locally | The device retained the edit in the application | Confirm it remains after the app's supported close/reopen test |
| Queued | A local change is waiting for transfer | Check queue status and connectivity requirements |
| Sending | A transfer is underway | Wait for a documented result or error |
| Confirmed on server | The receiving system shows the intended record | Check critical fields and attachment completeness |
| Conflict or error | Some part of the update needs attention | Follow the app's resolution procedure and preserve evidence |
A server confirmation should identify the relevant record or transaction. A disappearing spinner gives less assurance when the workflow has several stages, such as sending a form and then uploading its images.
Agree on conflict behavior
A dispatcher and a field worker may edit the same job while the worker is offline. Define who owns each field and how the product resolves competing edits. Determine whether conflicts apply to an entire record or individual fields, and how rejected changes become visible.
Dynamics 365 Field Service documents offline synchronization and conflict handling for its mobile application. Its behavior depends on configuration. Read the documentation for your own product and deployment, then reproduce a harmless competing-edit scenario. A general “last change wins” explanation is insufficient unless the administrator can identify which timestamp, change and record scope the system actually uses.
Run a realistic acceptance test
Use the offline sync acceptance worksheet in an approved test environment with fictional records. Begin online, complete the required download and verify the assigned sample job and its instructions are present. Disconnect the test device from networking, perform the supported edits and add a sample attachment.
Reopen the application using its supported workflow and check that local work remains. Restore connectivity and observe queue progress. From a separate authorized server view, confirm the record's fields and attachment count. Repeat with an interrupted upload, an expired sign-in if the test environment supports it, and a competing edit from a second test user. Record recovery steps and who resolves each failure.
A fictional field-service test might use job DEMO-104: change its status once and attach two sample photographs. Success means the server contains one intended job update and both photographs, with the documented final field values. The test also checks that retrying after an interruption does not create a second job or lose one attachment. This is a test requirement, not a guarantee of any application.
Recover without losing pending work
When a worker sees an error, first capture the record identifier, time, application version, queue state and visible message. Use the supported retry or conflict process. Check the server before manually recreating a record whose transfer outcome is uncertain.
Do not clear application storage, uninstall the app or reset the device while unsynchronized work may remain. Those actions require the application's documented recovery process and an administrator's assessment of local data. A connection repair and a record repair are different operations; restoring internet access should be followed by verification of the pending work.
Give workers a clear completion rule
Define when a job is considered finished: local save, supervisor review and server confirmation may serve different business purposes. Provide an escalation route for records that remain pending at shift end, including a way to report the issue without copying sensitive content into personal messaging.
Keep the test results with the app's offline profile and configuration version. Repeat the relevant cases when downloaded scope, conflict rules, authentication or attachment handling changes. Pair the workflow with a device-security lifecycle so local work remains protected while it waits to synchronize.