Choose inline message when the same warning belongs to a visible row, field group, card, table section, or panel and users need to keep seeing it beside that object.
Choose inline message when the same warning belongs to a visible row, field group, card, table section, or panel and users need to keep seeing it beside that object.
Practice the judgment: Imagine this situation: A session-expiration warning appears as a toast and disappears before the user can save work. 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 | Alert | Inline message | Toast notification | Confirmation dialog |
|---|---|---|---|---|
| UI or UX | UI + UX - Urgent current-task status message | UI + UX - Contextual in-flow feedback | UI + UX - Transient non-modal status message | UI + UX - Consequential alert decision |
| UI guidance | Render an alert as a visible message in the current task area with a clear severity cue, short title, consequence-focused body, and one direct action or safe dismissal when appropriate. | Render the message inside the same row, card, panel, form section, or task region that it describes, with a clear tone, concise title, body text, and at most one local action or detail disclosure. | Render toast notifications in a consistent non-modal region with short status text, clear severity, an optional close control, and at most one concise action. | Render an alert-style modal decision with a specific title, consequence description, safe cancellation, and a destructive action label that names the object or scope. |
| UX guidance | Use alerts when the user must notice a time-sensitive condition that affects their current task, such as session expiry, lost connection, unsaved work risk, failed submission, or a security-sensitive hold. | Use inline messages when users need contextual feedback while continuing nearby work, such as a row-level warning, section-level success, local policy note, or task-specific next step. | Escalate to inline, section, dialog, notification center, undo, or error-state treatment when the message requires repair, proof, long reading time, several actions, or reliable recovery. | Help the person reach a clear task outcome. |
| Good UI | A session alert appears above the active editor, says the session expires in 2 minutes, and offers Save draft while keeping the editor usable. | An invoice row shows Missing billing contact directly beneath the affected customer with Add contact as the only action. | Export started appears in the top notification region with a timestamp, close control, and View jobs action that remains available in activity history. | Delete Research archive? explains that 14 notes and shared links will be permanently removed, offers Keep archive, and labels the danger action Delete archive. |
| Bad UI | Users miss an urgent condition because the message auto-expires or appears far from the affected task. | A section message contains a full support workflow, several links, and unrelated settings controls. | Five unrelated toasts pile up over the Save and Continue controls. | The red destructive action is enabled immediately and sits where users expect the routine primary button. |
| Good UX | When the connection returns, the alert downgrades to a success status and then can be dismissed safely. | A successful send message remains beside the invoice long enough to copy the generated reference. | A completed archive action shows a short toast and a specific Undo action because the prior state can be restored. | Cancel, Escape, and Keep archive leave the archive unchanged and return focus to Delete archive. |
| Bad UX | The only warning that unsaved work will be lost disappears after five seconds. | The message disappears like a toast even though users still need the invoice reference. | Every autosave tick triggers a toast, training users to ignore real status changes. | Every archive, filter, and dismiss action opens the same confirmation until users click through automatically. |
| Best fit | A current task has a time-sensitive warning, error, or important status change. | A visible object or section has local status, warning, success, or next-step information. | Use for short non-blocking confirmation after explicit actions such as save, copy, send, archive, invite, or queue export. | The action is destructive, irreversible, costly, security-sensitive, privacy-affecting, or externally visible. |
| Avoid when | The message belongs beside one object, row, field, or local section. | The message is a one-field validation correction. | The message is the only recovery path for a blocking or high-consequence failure. | The action is routine and easily reversible. |
| Required state | Advisory or success state that uses calmer status semantics rather than assertive alert semantics. | Informational inline message attached to the relevant object or section. | Stacked state with newest and older messages ordered predictably and capped. | Pre-action state with an explicit consequential trigger. |
| Accessibility burden | Use role alert for urgent dynamic text and avoid putting interactive controls inside the role-alert node itself. | Keep the message in the reading order near the context it describes. | Keep close and action controls keyboard reachable, clearly named, and stable while focused. | Use alertdialog semantics or platform equivalent when the decision is urgent and requires a response. |
| Common misuse | Using a disappearing toast for warnings users must act on before continuing. | Using an inline message for a single field error that should be connected to that input. | Using a toast as the only feedback for payment, save, permission, upload, or security failures. | Asking users to confirm every routine action until they stop reading. |