Conflict state vs Sync state vs Draft state vs Error state

Choose conflict state when the system has at least two competing valid versions of the same object, field, file, record, paragraph, or branch and cannot safely pick a winner without user or policy resolution.

Conflict state live example Sync state live example Draft state live example Error state live example

Decision dimensions

Dimension	Conflict state	Sync state	Draft state	Error state
UI or UX	UI + UX - Competing-version resolution state	UI + UX - Local-and-remote reconciliation status	UI + UX - Unpublished object version lifecycle	UI + UX - Recoverable failure surface
UI guidance	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.	Show sync state close to the object or queue it describes, using labels such as Local saved, Queued, Syncing, Synced, Partially synced, Failed, Paused, and Conflict needs review.	Label the current version explicitly as Draft, Unpublished changes, Published, Active, Locked, or Unavailable, and place that label near the object title, list row, editor header, and publish actions.	Render a persistent error region near the affected content with a specific failure heading, plain-language cause, preserved context, and recovery actions.
UX guidance	Use conflict state when multiple valid changes overlap and the system needs a human, rule, or review workflow to decide what survives without losing work silently.	Use sync state to keep users confident while local changes, remote copies, attachments, messages, or records reconcile across devices, services, or background workers.	Use draft state when users need to pause work on an object, return later, and decide whether to publish, activate, discard, or keep editing an unpublished version.	Help users recover when expected loading, saving, validation, sync, permission, or computation fails without losing their work.
Good UI	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 field report queue shows 5 local changes: notes synced, two photos uploading, meter reading queued, signature failed with Retry, and supervisor comment needs review.	A knowledge article header says Draft saved today, shows the currently published title, and offers Resume draft, Compare with published, Discard draft, and Publish.	Reports could not load appears in the report section with the saved filter, Retry, Use cached data, and Contact support actions.
Bad UI	A save banner says Something went wrong and only offers Retry after another user changed the same field.	A single green Saved badge appears while several attachments are still queued.	An editor opens directly into draft text but the header only says Saved, so users cannot tell whether viewers see the changes.	Tiny transient toast for a blocking failure.
Good UX	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 reconnects after editing offline and sees the queue move from local saved to syncing, then to one failed photo with retry while the accepted notes remain synced.	A user opens a published article that has an unpublished version, chooses Resume draft, reviews a change summary, publishes, and sees the page become visible to viewers.	User input and filter context are preserved after failure, and retry returns to recovered content or a clear still-failed state.
Bad UX	The app silently keeps the newest server value and deletes the user's local note.	The offline banner disappears after reconnect, but hidden queued changes keep failing in the background.	A user closes an editor after seeing Saved, later discovers the page was never published, and cannot find the draft in the content list.	Clearing work after save failure.
Best fit	Concurrent users, devices, branches, or background jobs changed the same object or location.	Local changes, files, messages, uploads, or records need to reconcile with a remote service or another device.	Users create or edit objects that should not become visible, active, submitted, or externally effective until a later action.	A system or task failure blocks expected content or action.
Avoid when	Only one operation failed and there is no competing valid version.	The product has no local copy or queued work and a simple loading, success, or error state is enough.	The change is a small one-field edit that should be saved or canceled immediately.	Nothing exists yet and the state is expected.
Required state	No conflict state after automatic safe merge.	Local saved state for data persisted on the device but not yet sent.	Published or active state with no draft.	Normal expected state before failure.
Accessibility burden	Use headings and text labels to name each side of the conflict; do not rely only on red/green diff colors.	Use visible text and accessible names for statuses; do not rely on spinning arrows, checkmarks, color, or icon overlays alone.	Expose Draft, Published, Unpublished changes, Locked, and Unavailable as text in the page title area and list rows, not only by color or icon.	Use appropriate alert or status semantics for newly appearing critical errors.
Common misuse	Treating a conflict as a simple retryable save error.	Calling local persistence Synced before remote acceptance.	Using Saved to mean both saved draft and published content.	Using a transient toast for critical errors.

Conflict state

UI or UX: UI + UX - Competing-version resolution state
UI guidance: 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.
UX guidance: Use conflict state when multiple valid changes overlap and the system needs a human, rule, or review workflow to decide what survives without losing work silently.
Good UI: 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.
Bad UI: A save banner says Something went wrong and only offers Retry after another user changed the same field.
Good UX: 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.
Bad UX: The app silently keeps the newest server value and deletes the user's local note.
Best fit: Concurrent users, devices, branches, or background jobs changed the same object or location.
Avoid when: Only one operation failed and there is no competing valid version.
Required state: No conflict state after automatic safe merge.
Accessibility burden: Use headings and text labels to name each side of the conflict; do not rely only on red/green diff colors.
Common misuse: Treating a conflict as a simple retryable save error.

Sync state

UI or UX: UI + UX - Local-and-remote reconciliation status
UI guidance: Show sync state close to the object or queue it describes, using labels such as Local saved, Queued, Syncing, Synced, Partially synced, Failed, Paused, and Conflict needs review.
UX guidance: Use sync state to keep users confident while local changes, remote copies, attachments, messages, or records reconcile across devices, services, or background workers.
Good UI: A field report queue shows 5 local changes: notes synced, two photos uploading, meter reading queued, signature failed with Retry, and supervisor comment needs review.
Bad UI: A single green Saved badge appears while several attachments are still queued.
Good UX: A user reconnects after editing offline and sees the queue move from local saved to syncing, then to one failed photo with retry while the accepted notes remain synced.
Bad UX: The offline banner disappears after reconnect, but hidden queued changes keep failing in the background.
Best fit: Local changes, files, messages, uploads, or records need to reconcile with a remote service or another device.
Avoid when: The product has no local copy or queued work and a simple loading, success, or error state is enough.
Required state: Local saved state for data persisted on the device but not yet sent.
Accessibility burden: Use visible text and accessible names for statuses; do not rely on spinning arrows, checkmarks, color, or icon overlays alone.
Common misuse: Calling local persistence Synced before remote acceptance.

Draft state

UI or UX: UI + UX - Unpublished object version lifecycle
UI guidance: Label the current version explicitly as Draft, Unpublished changes, Published, Active, Locked, or Unavailable, and place that label near the object title, list row, editor header, and publish actions.
UX guidance: Use draft state when users need to pause work on an object, return later, and decide whether to publish, activate, discard, or keep editing an unpublished version.
Good UI: A knowledge article header says Draft saved today, shows the currently published title, and offers Resume draft, Compare with published, Discard draft, and Publish.
Bad UI: An editor opens directly into draft text but the header only says Saved, so users cannot tell whether viewers see the changes.
Good UX: A user opens a published article that has an unpublished version, chooses Resume draft, reviews a change summary, publishes, and sees the page become visible to viewers.
Bad UX: A user closes an editor after seeing Saved, later discovers the page was never published, and cannot find the draft in the content list.
Best fit: Users create or edit objects that should not become visible, active, submitted, or externally effective until a later action.
Avoid when: The change is a small one-field edit that should be saved or canceled immediately.
Required state: Published or active state with no draft.
Accessibility burden: Expose Draft, Published, Unpublished changes, Locked, and Unavailable as text in the page title area and list rows, not only by color or icon.
Common misuse: Using Saved to mean both saved draft and published content.

Error state

UI or UX: UI + UX - Recoverable failure surface
UI guidance: Render a persistent error region near the affected content with a specific failure heading, plain-language cause, preserved context, and recovery actions.
UX guidance: Help users recover when expected loading, saving, validation, sync, permission, or computation fails without losing their work.
Good UI: Reports could not load appears in the report section with the saved filter, Retry, Use cached data, and Contact support actions.
Bad UI: Tiny transient toast for a blocking failure.
Good UX: User input and filter context are preserved after failure, and retry returns to recovered content or a clear still-failed state.
Bad UX: Clearing work after save failure.
Best fit: A system or task failure blocks expected content or action.
Avoid when: Nothing exists yet and the state is expected.
Required state: Normal expected state before failure.
Accessibility burden: Use appropriate alert or status semantics for newly appearing critical errors.
Common misuse: Using a transient toast for critical errors.

Decision rules

Choose conflict state when the system has at least two competing valid versions of the same object, field, file, record, paragraph, or branch and cannot safely pick a winner without user or policy resolution.
Choose sync state when local and remote copies are reconciling, queued, uploading, accepted, paused, failed, or ready for review, but the interface does not yet need to compare overlapping edits.
Choose draft state when the main issue is an unpublished or inactive version lifecycle, such as resume, discard, compare, publish, or active-version visibility.
Choose error state when one operation failed and there is no alternative valid version to compare, merge, preserve, or choose from.
A conflict-state UI must identify the owning object, the competing parties or sources, timestamps or versions, the exact overlapping fields, and what each resolution action will keep or discard.
Do not hide conflict resolution inside a toast, one-word warning, or generic retry; users need durable access to both versions and a clear resolution path.
Use side-by-side, inline diff, tracked-change, row-level, or guided conflict-review views according to the data type and risk.
For destructive or irreversible resolution, require explicit confirmation after showing which local, remote, or collaborator changes will be removed.

Inspect live examples

Conflict state Sync state Draft state Error state

Failure modes

A sync queue says Review needed but opens no comparison of local and server values.
A document editor overwrites another person's paragraph without naming the newer version or offering continue-editing, overwrite, or cancel choices.
A file sync app creates a conflict copy but hides it from the affected folder and owner.
A merge tool offers Use ours and Use theirs without showing which side is the target branch or source branch.
A record form shows a generic save error after another user changed the same field, so the user retries and loses context.
A draft publish flow merges conflicting active and draft values without showing a change summary.