Toast-only success for completed transaction

Problem Context

• The user has completed or appears to have completed an application, booking, order, payment, account change, survey response, publication, approval, or service request.
• The transaction may need a reference number, receipt, submitted detail summary, next-step timing, tracking, contact, cancellation, amend, save, print, email, or support path.
• The implementation uses a toast, snackbar, flash, or temporary notification as the only completion proof or redirects users to a dashboard without durable confirmation.
• Users may look away, use assistive technology, close the page, refresh, return from browser history, contact support, or need proof later.

Selection Rules

• Flag this anti-pattern when a committed or high-consequence transaction is confirmed only by a disappearing toast.
• Replace it with confirmation page when the transaction or service journey has ended.
• Replace it with success confirmation when the user stays in the same task but still needs durable object-specific proof.
• Allow toast notification only when success is low consequence, self-evident, and proof is not needed after the toast disappears.
• Show a transaction name, submitted object, reference or timestamp when useful, and what happens next.
• Keep save, print, email receipt, copy reference, track, amend, cancel, contact, or support actions available when they support the completed transaction.
• Do not show success before the authoritative commit, server acceptance, payment authorization, booking creation, or submission record exists.
• Use pending, offline mobile retry, sync state, progress, or error state when the transaction is queued, unaccepted, failed, denied, or still processing.
• Preserve a safe return route for bookmark, refresh, Back, duplicate submit, expired session, and history return scenarios.
• During generated UI review, flag handlers whose final step is only toast.success(...) or equivalent after clearing transaction state.

Required States

• Pre-submit state with the transaction and affected object visible.
• Committed confirmation state with durable proof after authoritative success.
• Receipt/reference state with copy, save, print, email, or tracking where useful.
• What-happens-next state with timing, owner, and user responsibility.
• Supplemental toast state that is not the only proof.
• Toast expired state where the durable confirmation still remains.
• Dashboard or return state that preserves transaction proof or a tracking route.
• Duplicate-submit protection state after commit.
• Failure, pending, queued, denied, or processing state that does not render as success.
• Start another transaction state that does not erase the completed receipt.

Interaction Contract

• The completed transaction remains provable after the toast expires.
• The user can identify what completed, when, and what reference or receipt proves it.
• Any transient toast points to or duplicates a durable confirmation surface rather than replacing it.
• The transaction context is not cleared until proof and next steps are rendered or safely reachable.
• Copy, save, print, email, tracking, contact, amend, cancel, and start-again actions preserve the completed transaction's identity.
• The UI prevents duplicate submit, refresh resubmit, or Back resubmit after commit.
• If the authoritative success event is not available, the UI stays pending, queued, retrying, or failed instead of showing completed success.

Implementation Checklist

• Identify which actions are completed transactions rather than disposable status events.
• Define the authoritative commit event, reference, receipt, timestamp, object identity, submitted summary, and next-step content before rendering success.
• Choose confirmation page for journey endpoints and success confirmation for in-context proof.
• Use toast only as secondary notification and provide a route to the persistent confirmation.
• Keep proof visible through toast expiry, refresh, Back, bookmarked return, dashboard redirect, and session recovery where permitted.
• Remove or guard duplicate submit controls after commit and ensure refresh cannot replay the transaction.
• Write success copy with the transaction name and proof, not vague Done or Success.
• Test with screen reader timing, keyboard navigation, slow readers, mobile viewport, support-reference copying, print/save behavior, and interrupted attention.

Common Generated-UI Mistakes

• Redirecting to a dashboard and showing a five-second Application submitted toast with no receipt page.
• Using a generic Done toast for payment, booking, order, application, and profile-change outcomes.
• Clearing the form immediately after submit without rendering a durable success state.
• Showing a toast before the server commit finishes.
• Putting the reference number only inside the toast.
• Hiding next steps, timing, or support path behind notification history.
• Letting users refresh or tap Submit again because no persistent completed state exists.
• Treating a queued offline or pending async action as completed transaction success.

Critique Questions

• If the toast disappears, can users still prove the transaction completed?
• What reference, receipt, timestamp, or submitted details might users need later?
• Does the UI explain what happens next and when?
• What authoritative event proves the transaction completed before success is shown?
• What happens on refresh, Back, duplicate submit, bookmark return, or expired session?
• Should this be a confirmation page, in-context success confirmation, or only a disposable toast?