Toasts

Toast serves as a feedback & confirmation mechanism after the user takes an action.

Usage

• Visual: Visible
• Voice & Tone: Informational
• Motion: Delicate
• Duration: Dismissible
• Audio: Soft (or Vibrate)

A toast appears in reaction to user action: creating, editing, deleting. For example, a user edits an opportunity via a modal and saves it. The modal closes and the toast appears at the top of the opportunity detail page.

A toast can show one of the following states:

• Error: when a user completes an action, but system-related issues prevent the action to be truly executed.
• Informational: when a user completes an action, but there are some additional info to be shown.
• Success: when a user completes/executes an action.
• Warning: when a user cannot complete an action due to external factors (e.g. permission) rather than something they can fix right away (e.g. form error).

Toasts persist at the top of the page regardless of scrolling, and they are visible until a user dismisses them or the defined duration elapses. They show 1–2 full sentences (no truncation), including an inline link (when appropriate), and an X to close. Toasts on desktop include an icon denoting the type of message, but toasts on mobile don’t include one.

The width of a toast is determined by the length of its content and its inside padding, but at minimum it should be 480 px and centered within the canvas of the page.

Toasts can appear in one of the following manners:

• Sticky: displayed until dismissed, no duration applies. This forces the user to acknowledge info without blocking other interaction on the page, e.g. 10 leads were not converted.
• Timed: displayed temporarily, until duration ends or user dismisses, whichever comes first. This shows a message that is useful but not crucial, e.g. record was saved.

Toast in Context

Dos and Don’ts

DO

• Do batch toasts of the same type to minimize the number of toasts that appear.

  

• Do stack multiple toasts if you have more than one type appearing. Show the most recent on top and the rest underneath it in chronological order.

  

Do Not

• Do not use toasts to confirm success when a create action brings the user to the newly created item. For example, creating a new record from a list view leads to the new record, so a toast is unnecessary.
• Do not show toasts after inline edit. Returning to view state is indication enough that the changes were successfully submitted—if the form didn’t save properly, it would still be open (+ error popover & message).
• Do not keep toasts after the user navigates away. A toast displays status that’s only relevant to the current page they are on; if they move to a different page, the toast message is no longer relevant.

Variants - Component

Variants - State

Variants - Screen Size

• 90% width
• No icon
• Smaller, left-aligned text
• No description text

UI Text

Basic rules around UI text in toast:

• The syntax is as follows:
  «record type»   «record name»    was/were    «past tense action»
• If the action is create a record, the newly created record should be linked. Otherwise, the affected record should be shown inside quotation marks, but not linked.
• If the action affects multiple recipients, the first one should be listed, and the rest should be shown as “X others” and linked.

Recommended Specs

Refer to this code sample for the toast markup.

The “dismissible” toast is preferred and should work for most cases. “Dismissible” means that the toast remains visible until the user dismisses it with the “×” or duration has elapsed, whichever comes first.

If the toast contains a link, the staying duration should be longer.