Conflict resolution is the guided decision workflow after a conflict is detected. Conflict state signals and preserves competing versions, review before submit checks the user's own answers before final commit, and autosave recovery preserves work after failed or uncertain saving.
Conflict resolution is the guided decision workflow after a conflict is detected. Conflict state signals and preserves competing versions, review before submit checks the user's own answers before final commit, and autosave recovery preserves work after failed or uncertain saving.
Practice the judgment: Imagine this situation: A review page asks users to check answers but hides that another source changed the same field. Write the person's goal, choose one of these patterns, and show the state that helps the person continue. Use the decision rules and source trail below to explain your choice.
Review the underlying principle →| Dimension | Conflict resolution | Conflict state | Review before submit | Autosave recovery |
|---|---|---|---|---|
| UI or UX | UI + UX - Guided workflow for reviewing and committing conflict decisions | UI + UX - Competing-version resolution state | UI + UX - Final editable answer summary before committing a transaction | UI + UX - Recovery surface for failed or uncertain background saves |
| UI guidance | Show a durable resolution workspace that lists every unresolved conflict, exposes the current conflict, names each version source, and separates choose-local, choose-remote, merge, save-copy, skip, and commit actions. | Show both competing versions near the affected object, field, paragraph, file, row, or branch with source labels such as Your edit, Server version, Mina's edit, Target branch, and Current published value. | Render a single review page immediately before commit with a clear title, grouped answer sections, readable key/value rows, per-answer or per-section Change actions, skipped optional answers when meaningful, and a primary button whose label names the committed action. | Keep the user's latest local value visible or copyable until recovery succeeds, and distinguish Retry save, Keep local copy, Restore last saved, Compare versions, Download copy, and Continue after recovery. |
| UX guidance | Use conflict resolution after conflict detection when users must make one or more explicit decisions before a record, document, branch, import, or synced object can continue. | Preserve each version, explain why automatic merge was unsafe, guide users through the smallest conflicting unit, and make the post-resolution result reviewable before committing. | Use review before submit to give users one final chance to verify and correct captured answers before a transaction is sent, paid, published, applied, or otherwise committed. | Use autosave recovery when users need to preserve effort after background saving fails, stalls, conflicts, expires, or only stores a local copy. |
| Good UI | A field report resolver shows 2 of 3 conflicts remaining, displays Your offline value and Mina's server value for the current field, offers Keep local, Keep server, Merge both, Save copy, and shows a reviewed result before Commit resolutions. | A field report says Conflict on supervisor comment, shows Your offline edit from 11:06 beside Server edit by Mina at 11:07, and offers Keep mine, Keep server, and Merge comment. | A claim review page has Applicant, Contact details, Evidence, and Declaration sections; each row shows the captured answer and a Change link with hidden context such as Change email address. | A claim form says Household income answer failed to autosave at 10:42, keeps the typed answer visible, and offers Retry save, Copy answer, Restore last saved, and Continue after saved. |
| Bad UI | A resolver lets users click Commit while some conflicts are still unresolved and hides which side will be lost. | A save banner says Something went wrong and only offers Retry after another user changed the same field. | Change links lack context, so assistive technology users hear a list of identical Change links. | The app clears the field after a failed autosave and offers only Reload page. |
| Good UX | A user resolves the supervisor comment by merging both versions, keeps the server contact number, saves the local safety note as a copy, reviews the final report, then commits with an audit summary. | A user tries to sync an offline field report, reviews only the two changed fields, merges one comment, keeps the server contact number, and commits a resolved version. | A user changes their phone number from review, lands on the phone page with the old value pre-filled, saves, and returns directly to review with other answers preserved. | A user loses network while writing a long answer, sees it is saved on this device only, reconnects, retries the same value, and continues after the timestamp updates. |
| Bad UX | The system silently resolves all conflicts by newest timestamp and only shows a success toast. | The app silently keeps the newest server value and deletes the user's local note. | A user selects Change address, edits one field, then has to repeat every later page before finding the review page again. | A stale saved timestamp hides that the latest answer failed after the timestamp. |
| Best fit | A conflict has been detected and a user must choose, merge, save-copy, skip, or commit a result. | Concurrent users, devices, branches, or background jobs changed the same object or location. | A user has provided multiple answers and should verify them before a consequential submit action. | Autosave failed, stalled, expired, or became uncertain while users still have meaningful local work. |
| Avoid when | The interface only needs to signal that a conflict exists and route users elsewhere. | The user is managing an unpublished draft lifecycle rather than resolving competing edits. | The task is a single low-risk field with clear inline validation and an obvious submit action. | The work is a durable draft object with list-level resume, publish, and discard lifecycle. |
| Required state | Conflict list state with unresolved count and current conflict position. | Conflict detected state naming affected object and source versions. | Initial review state with grouped captured answers, relevant sections, and explicit submit action. | Clean saved state with current server timestamp. |
| Accessibility burden | Place resolution controls after the compared values they affect and label them with the source they keep or discard. | Associate each conflict message with the affected field, row, line, paragraph, or file. | Use headings that make the review task explicit, such as Check your answers before sending your application. | Place recovery controls in reading order near the affected field, section, or submit action. |
| Common misuse | Marking conflicts resolved before the user reviews the surviving value. | Treating a conflict as a simple retryable save error. | Labelling the final commit button Continue. | Leaving a green Saved label visible after a failed or stale autosave. |