Destructive action confirmation

Problem Context

• The user has already selected a destructive command such as Delete, Remove, Cancel, Deactivate, Reset, Revoke, or Permanently erase.
• The action can cause permanent data loss, account loss, subscription cancellation, permission removal, key reset, webhook deletion, public-link breakage, or irreversible external effects.
• The product can enumerate the affected object, child objects, relationships, integrations, billing effects, or recovery limits before committing.
• The team must distinguish permanent destruction from reversible archive, trash, dismiss, hide, or undoable cleanup.

Selection Rules

• Choose destructive action confirmation when a destructive command needs a final commit review before permanent or externally visible loss.
• Use the destructive verb and target in the title and final button; avoid OK, Yes, Continue, Proceed, and Confirm for the final destructive action.
• List the affected scope in concrete terms: object name, count, child records, members, shared links, integrations, billing, audit, or external systems.
• Keep the safe path first or easiest to reach when cancellation leaves everything unchanged.
• Disable the destructive action until required acknowledgement, dependency resolution, or scope review is complete.
• Use ordinary confirmation dialog for high-consequence decisions that are not mainly destructive.
• Use undo or restore when deletion is actually a reversible trash move and the prior state can be restored faithfully.
• Use warning text before the destructive command when the user only needs consequence copy before starting the delete flow.
• Escalate to typed confirmation for severe broad-scope deletion, workspace or account closure, production data deletion, or security-critical reset.

Required States

• Idle state where the destructive command is visible but not committed.
• Review state that names the destructive verb, target object, and affected scope.
• Dependency-blocked state where deletion cannot continue until related jobs, locks, billing, or permissions are resolved.
• Acknowledgement-required state for permanent loss or external effects.
• Safe cancellation state that keeps the object unchanged and returns focus to the destructive trigger or object row.
• Committing state after deliberate confirmation with disabled duplicate submissions.
• Committed outcome state that reports what was permanently removed and where focus or navigation goes next.
• Alternative recovery state where undo, trash restore, archive, or warning text is the more appropriate pattern.

Interaction Contract

• The confirmation appears only after a user-initiated destructive command.
• The title, body, and final button all refer to the same target and destructive action.
• The confirmation inventory is specific enough for users to decide whether to cancel.
• The safe path closes the confirmation without changing the target object.
• Escape cancels only when the destructive action has not started and cancellation is safe.
• The destructive button cannot be activated until required acknowledgement or dependency checks pass.
• Committing disables duplicate activation and shows a clear in-progress state.
• After cancel, block, or completion, focus returns to the trigger, the preserved object, or a clear post-deletion status.

Implementation Checklist

• Identify the destructive verb, target object, owner, and exact irreversible boundary before designing the confirmation.
• Inventory child records, relationships, shared links, integrations, billing effects, audit retention, external notifications, and recovery windows.
• Write the title as a destructive question or statement using the target name.
• Write the final action label as the destructive verb plus object type or object name.
• Write the safe action as the preserved outcome, such as Keep project, Keep subscription, or Do not delete.
• Block commit when dependencies make deletion invalid or when required acknowledgement is incomplete.
• Prevent duplicate destructive submissions while the deletion request is committing.
• Record cancellation, blocked, and committed outcomes in a status region or audit trail where appropriate.
• Review whether undo, restore-from-trash, warning text, or command placement would protect users with less interruption.

Common Generated-UI Mistakes

• Using a vague Are you sure prompt that does not name the object, count, or consequence.
• Labelling the destructive commit OK, Yes, Continue, or Confirm.
• Making the destructive action the default Enter target before the user reviews the loss.
• Using the same severe confirmation for reversible archive, hide, dismiss, and move-to-trash actions.
• Omitting child objects, shared links, subscriptions, automations, webhooks, or permissions from the loss inventory.
• Offering undo after an irreversible deletion has already crossed the system boundary.
• Showing the confirmation after the destructive action has already started.

Critique Questions

• What exactly will be gone, revoked, cancelled, reset, or deactivated after commit?
• Can the product list enough affected scope to change the user's decision?
• Is this permanent destruction, a reversible trash move, or a routine archive action?
• Does the final button say the destructive verb and target?
• Is the safe action phrased as the preserved outcome?
• What blocks deletion, and how does the confirmation show that block?
• What state receives focus after cancel, block, and commit?