Resolve Conflicting Offline Edits Before a Mobile App Reconnects

An offline mobile form can save correctly on a phone and still overwrite someone else's work when it reconnects. Imagine a field employee editing a service note while an office colleague changes the same request. Both changes are legitimate. The product needs a rule for combining them, rejecting one, or asking someone to decide.

Agree on those rules before accepting an offline feature. A useful review produces a short conflict policy and a repeatable two-device test, with visible outcomes for the employee and the office.

Start with one record and its competing changes

Choose a real workflow, then use invented records in a test environment. For a hypothetical service request, list the fields a mobile worker can edit: inspection notes, photographs, arrival time, customer contact information, and completion status. Identify which fields the office can also change.

Write down the last version each device received. This creates a shared starting point for the test. Android's offline-first guidance explains that local writes can conflict with network data and that resolution often needs version information. The exact policy remains a product decision.

Do not treat the entire request as one indivisible value unless the business intends that behavior. Updating a note should not automatically replace an unrelated office assignment.

Choose a rule for each kind of information

• Append-only observations: consider keeping separate notes with their authors and record references rather than replacing a shared paragraph.
• Editable details: if two people change the same phone number, preserve both proposals and route the disagreement to an authorized reviewer.
• Controlled statuses: define valid transitions. An old offline “in progress” edit should not silently reopen a cancelled request.
• Attachments: distinguish a saved description from a successfully uploaded file. Show pending or failed uploads separately.

A simple preference field might tolerate a last-write rule. A completion approval might require a stronger check. Ask what losing a valid earlier value would mean before selecting the easiest technical option. Record who resolves conflicts and what happens while that person is unavailable.

Make the unresolved state understandable

Separate “saved on this device,” “waiting to synchronize,” “accepted by the server,” and “needs review.” A generic green check can cause an employee to believe the office already has information that exists only locally.

For the disputed phone number, a useful message could explain: “The contact changed while you were offline. Your proposed number is saved for review.” Offer a clear next action without exposing another customer's data. Do not make the user repeatedly press Save to discover whether the change exists.

Decide whether the worker can continue with other tasks. A disagreement about a note does not necessarily justify blocking every request, but a disputed authorization may require stopping the affected action.

Run the reconnection rehearsal

1. Create one synthetic request and open the same initial version on two devices.
2. Disconnect the field device. Change a note and the contact number locally.
3. On the connected device, change that contact number and cancel the request.
4. Reconnect the field device and observe the record, pending changes, and messages on both devices.
5. Interrupt synchronization, reopen the app, and reconnect again. Check that the pending edit remains identifiable and accepted notes do not multiply.
6. Resolve the contact conflict using the authorized role, then refresh both views.

Also test a device whose clock is incorrect and a user whose access was removed while offline. The expected response should come from the agreed policy, not from whichever update happens to arrive last. Test permission checks at synchronization time as well as when the form first opens.

Accept the workflow with evidence

Keep a test record with the starting versions, changes made, expected outcome, observed outcome, app build, and tester. Confirm that the cancellation remains effective, the note survives according to policy, the rejected proposal can be reviewed, and both screens converge after resolution.

Ask an operations colleague to explain each visible state without help from the developer. If they cannot tell whether a change reached the office, the interface still needs work. These checks describe a hypothetical acceptance exercise, not results from a Dynelink client.

Contact Dynelink to turn an offline mobile workflow into explicit conflict rules, user messages, and acceptance cases before the next release.