Batch or immediate save
Choose one mental model and make it visible. Do not mix silent automatic saves with an unexplained Save button.
Edit & save
Make drafts visible, save changes together, and preserve work after a failure.
Update a work queue without losing the draft.
Use when people edit several records or board cards before committing a batch, such as a service queue, project plan or review checklist.
- 01Make the draft visible.
- 02Save once and show progress.
- 03Confirm success or preserve the draft.
Design beyond the happy path.
Select a state to see what the interface should communicate. These are illustrative snapshots; try the live component below.
EXAMPLE WORKSPACEDraft
Project work
2 unsaved changes
- Prepare handover
- In progress · edited
- Review checklist
- Ready · edited
DESIGN INTENT
Draft
Show that edits are local. Keep the save action near the work and explain what will be included.
Try the working example ↓EXAMPLE WORKSPACESaving
Saving changes…
Waiting for the application to confirm
- Prepare handover
- Pending
- Review checklist
- Pending
DESIGN INTENT
Saving
Prevent overlapping requests. Keep the draft visible while waiting; a request starting does not mean it succeeded.
Try the working example ↓EXAMPLE WORKSPACESaved
Changes saved
The application accepted both updates.
- Prepare handover
- In progress
- Review checklist
- Ready
DESIGN INTENT
Saved
Use the server response as the saved state. Announce completion without moving focus away from the task.
Try the working example ↓EXAMPLE WORKSPACESave failed
Couldn’t save the changes
Your 2 edits are still available.
- Prepare handover
- Draft retained
- Review checklist
- Needs a valid owner
DESIGN INTENT
Save failed
Preserve the draft and show a useful reason. Mark record-level errors so the person can correct the affected item.
Try the working example ↓WORKING EXAMPLE
Component reference →Edit & save
Edit a card, move it to a different column, then save the changes. Try the rejection option and confirm that the pending edits remain available. Demo changes are not stored permanently.
Make the important choices explicit.
Conflicts
If another person changed the same record, explain the conflict and offer a recovery path. Do not silently overwrite.
Leaving with a draft
Keep the draft where practical, or warn before discarding unsaved work.
Keep the behavior. Bring your data.
The examples demonstrate interaction using sample data. Your application owns the real records, permissions and persistence.
- 01Draft state
- Keep edited values separate from the last confirmed values.
- 02Save acknowledgement
- Match the acknowledgement to the pending request; use the component’s documented save lifecycle.
- 03Validation
- Validate and authorize on the server, then return record-specific errors.
BUILD THIS PATTERN WITH
All patterns →