Cancel and Save


Cancel and save are ubiquitous across our applications. These two actions give users peace of mind and a sense of control, knowing that either they can back out of changes they have made or the reverse, save all of the changes they have made.

Usage/Best practices#

Cancel and save actions should be hidden by default at the page-level and revealed upon interaction with components on the page (with the exception of card or modals that have primary and secondary button actions built in).


As a neutral action, the cancel button should always be the secondary button, located to the left of a primary action.

Cancel in page headers#

  • Will revert the user to their previously un-edited state (clears all work).
    • Always use the confirmation modal to prevent accidental loss of work or if the impact of cancel cannot be undone or will require a lot of time and effort to recreate, such as multiple deletions or removals.

Cancel in modals#

  • Returns user to the parent page.


Save should always be the primary button, located to the right of secondary buttons.

Save in page headers#

  • Saves changes made anywhere on the page including paginated tables and tabbed sections.
  • See Actionable Words for label handling.
  • Always use success messages to provide quick notification that save completed successfully.

Save in modals#

  • If save occurs immediately - use "save".
  • If save is deferred - use "done".

Implicit save#

In some cases, values may be saved implicitly without requiring an action from the user to take effect.

Save in tables#

  • Save should occur upon completion of updating the value.

    • In cases where the input is a single interaction, such as a switch or checkbox, save occurs on mouse up or key up.
    • In cases where the input is a text input or something that requires more than a single interaction/keystroke, save occurs upon clicking off of the input, or by pressing Enter or Return.
  • When the input is updated, the value should update without requiring a page reload.

  • When saving an a inline edit:

    • Display a message summarizing the change.
    • Do not reorder the table. Leave all rows in place until the user initiates a re-sort.

Labels when confirming a "cancel action"#

Labels should not compete as this can be confusing to the user. Eg. Cancel and Cancel update. If all other options don't fit, use Do not cancel and Cancel update. Always try to avoid using "cancel" within both actions.

DoDo not
Primary: Cancel update, Secondary: Do not cancelPrimary: Cancel update, Secondary: Cancel
Last updated on by Diana Thomson