Use restore from trash when deleted objects remain recoverable in a durable deleted-items location after the immediate action window has passed.
Use restore from trash when deleted objects remain recoverable in a durable deleted-items location after the immediate action window has passed.
Practice the judgment: Imagine this situation: The interface promises recovery after retention has expired or after an administrator purge. 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 | Restore from trash | Undo | Destructive action confirmation | Draft state |
|---|---|---|---|---|
| UI or UX | UI + UX - Durable deleted-object recovery | UX - Post-action recovery behavior | UI + UX - Final destructive commit review | UI + UX - Unpublished object version lifecycle |
| UI guidance | Show deleted objects in a dedicated trash, recycle bin, deleted-files, or recoverable-items surface with object name, type, original location, deletion date, deleted-by actor, and remaining recovery window. | Show a named recovery affordance after the completed action, such as Undo delete for a specific task, near the result or in a consistent status region. | Render a destructive confirmation after the user invokes a destructive command, with a title and final action button that repeat the destructive verb and target, such as Delete workspace or Cancel subscription. | 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 restore from trash when users may discover a mistaken deletion after leaving the original workflow and need a durable way to recover the object. | Let users move quickly through frequent reversible actions, then recover from mistakes after seeing the result. | Make the safe path explicit and easy, keep the destructive action unavailable until required review is satisfied, and report whether the object was kept, blocked, or permanently committed. | 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 Deleted files table lists Quarterly budget.xlsx with original folder Finance/Q2, deleted yesterday by Maya, 29 days left, and a Restore to Finance/Q2 action. | Deleting Quarterly report removes it from the list and shows a recovery panel saying Quarterly report deleted with an Undo task button. | Delete Payments project? lists 4 dashboards, 12 saved views, 3 webhooks, and 8 shared links, offers Keep project, and labels the danger action Delete Payments project. | 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 | Restore succeeds but the item is invisible because the original parent is gone or access changed. | Undo action disappears before users can activate it. | A soft archive action opens the same severe deletion confirmation used for permanent account closure. | A draft label is missing from the editor, so users publish or discard the wrong version. |
| Good UX | A user opens Trash, filters to spreadsheets deleted this week, previews the original folder, restores one file, and gets a link to the restored location. | Undo restores the deleted task to the list and reports Quarterly report restored. | A user opens Delete workspace, reviews the object count and webhooks, cancels, and returns to the same workspace with nothing changed. | 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 expects a file to remain recoverable, but the product hid the retention deadline and the file was purged. | The UI promises undo for a side effect that has already notified external recipients. | A user confirms deletion because OK looks like the primary next step, then discovers shared links and child reports were lost. | A user discards a shared draft and unknowingly removes another editor's unpublished changes. |
| Best fit | Deleted objects remain recoverable after the user leaves the original workflow. | The action is common and mistakes are likely. | A user has initiated a destructive command that can permanently remove, revoke, reset, deactivate, or cancel something valuable. | Users need to pause and resume unfinished work across sessions, devices, or routes. |
| Avoid when | Deletion is permanent, regulated, externally effective, or security-sensitive and should be prevented before commit. | Recovery would restore only part of the user's lost work. | The action is a routine reversible archive, hide, dismiss, move, reorder, or trash move. | The change is a small one-field edit that should be saved or canceled immediately. |
| Required state | Normal active-object state before deletion. | Normal state before the user action. | Review state that names the destructive verb, target object, and affected scope. | Published or active state with an available draft. |
| Accessibility burden | Expose deleted item name, type, original location, retention deadline, and restore availability as text in each row. | Make the undo control keyboard reachable and programmatically identifiable. | Use alertdialog semantics or platform equivalent when the destructive decision requires an immediate response. | Use headings and status regions so screen reader users know whether they are editing a draft or viewing the active version. |
| Common misuse | Treating trash as a substitute for confirmation when deletion is severe or externally visible. | Restoring only part of the prior state while implying full recovery. | Labelling the destructive commit OK, Yes, Continue, or Confirm. | Using Saved to mean both saved draft and published content. |