Undo and Restore
Last updated:
Practical patterns for reversible actions that build confidence instead of fear.
01 — Foundation
Undo encourages confidence
Good recovery patterns reduce fear of mistakes. Users should know what changed and whether they can reverse it.
Undo and restore systems let users recover from errors without opening a support ticket. They work when recovery is visible, time-bounded honestly, and predictable — not when actions are silently irreversible behind a cheerful toast.
02 — Undo
Visible undo actions
Recovery should be offered at the moment of change — not buried in settings.
- show undo after reversible actions — delete row, archive, dismiss
- state how long undo remains — “Undo (30 seconds)” or “Restore from archive”
- prefer undo over confirmation fatigue for low-risk reversible edits
- in-context message with undo button — not a corner toast unless unavoidable; see Toast Notifications
<p role="status">
Invoice archived.
<button type="button">Undo</button>
</p>03 — Restore
Restore and soft delete
Longer recovery windows need a clear place to find restored items.
- trash, archive, or version history with plain labels
- explain what restore will do — “Restore invoice #1042 to active list”
- do not claim undo when the server already purged data
04 — Avoid
What to avoid
Misleading confirmations punish users twice.
- silent irreversible actions after a generic “Success” toast
- hidden recovery — users should not need insider knowledge
- confusing restore states — “Undo delete” vs “Restore version” need different copy
05 — Review
Before you approve
A short checklist for undo and restore in code review.
- users know what changed and whether recovery exists
- undo is visible, keyboard accessible, and honest about timing
- irreversible actions use Destructive Actions — not fake undo