Updated: December 5, 2019

Message Handling


This article describes how to display messages to the user, such as errors, warnings, success messages, confirmation, and information. You can choose from various controls to display different types of messages. All errors must be easily visible (highlighted) and clearly identifiable on the UI.

Always help the user to recognize, diagnose, and resolve the issue. Use plain language (no codes), indicate the precise problem, and suggest a constructive solution.

Interrupt the user as little as possible (only in unavoidable cases), and exploit all the technical options for giving the user guidance. Good messages are important, but a careful design that prevents a problem from occurring in the first place is even better. This can be achieved by using input types, mask input, and straightforward controls. Always start with the least complex control (for example, use select instead of value help), and use more intricate controls only if the use case really requires it. If appropriate, use placeholder texts to offer input hints (for example, to indicate the expected input format).

This UX approach makes it easier for users to fulfill their tasks and stay in their flow.

Types of Messages

The following message categories are available:

  • Error
  • Warning
  • Success
  • Information
  • Confirmation

Handling for State Messages

State messages are related to a field on the UI (such as an input field), and are displayed within the message popover (sap.m.MessagePopover).

  • The message is displayed next to input field that uses form field validation and inside the message popover.
  • If a message long text is available in the back-end system, the user can drill into the second page of the message popover.


The messages are retained until a validation is triggered (for example, when the user leaves the field), and the issue has been resolved by the system or user.

Handling for Transient Messages

Transient messages are related to an action and are displayed in the following way.


As soon as the user closes the dialog, the messages in the message box or dialog are removed from the technical message manager, and are no longer valid.

Example for state messages
Example for state messages
Example for transient messages
Example for transient messages


Form Field Validation

Error, warning, and success messages on form fields are shown directly on the form by setting the status of the field (valueState) and by providing a meaningful text to the user. For more information, see form field validation.


The following controls can be used to display inline error, warning, and success messages. The application can set a an error, warning, or success state for the control.

  • sap.m.ComboBox
  • sap.m.DatePicker
  • sap.m.DateTimeInput
  • sap.m.DateRangeSelection
  • sap.m.MultiComboBox
  • sap.m.MultiInput
  • sap.m.Input
  • sap.m.TextArea
Example of form field validation
Example of form field validation

Error Visualization

Errors should be easy to spot to save users from searching.

  • Use form field validation if the error occurs within a form.
  • If the error is related to an item in a table, use the “contains errors” feature (see the item states for responsive tables and grid tables).
  • If leaving a table empty can result in errors, use the “no data” text to indicate that entries are required.
    Example: A new purchase order can’t be created without purchase order items. If the table for purchase order items is left empty, the “no data” text might read: Create at least one purchase order item.

Message Popover

The message popover (sap.m.MessagePopover) control can communicate automatically with a message manager. With a message popover, the application can easily display multiple messages that occur after a UI interaction. For more information, see message popover.

Do not show the messaging button and message popover:

  • In the footer toolbar of a dialog
  • In a popover
  • In a partial editing area. If you offer partial editing, never show a message popover for the part of the screen being edited. The message popover always belongs to the footer toolbar for the whole page.

Instead, just highlight the fields that contain errors to make it easier for the user to understand the issue(s).

Message popover
Message popover

Message Box

The message box (sap.m.MessageBox) displays a message that interrupts the user in the course of an action. Because of its disruptive behavior, we recommend using the message box control only after careful consideration. For more information, see message box.

Message box with a helpful error message
Message box with a helpful error message

Message Toast

This is a standard message component for success messages. For more information, see message toast.

Example of a message toast
Example of a message toast

Message Strip

The message strip is used to display general information or inform about the status of an object. It can be placed within the details area of a page. For more information, see message strip.

Message strip with a warning message
Message strip with a warning message

Behavior and Interaction

Messages are intended to help the user to rectify a problem which is generally field-related. As such, it’s very important that you highlight all relevant fields to which the message relates. This section gives an overview of the changes that should appear on the UI after a validation.

If a value is incorrect:

  • Highlight the relevant field and add a useful message to the value state.
  • Display a button for the message popover on the left side of the footer toolbar.
  • If the user is still allowed to continue the action, the message no longer needs to be displayed.

Because SAP Fiori is role-based, it might be that the application cannot establish a relation to a field. This can happen with configuation issues, for example, or if data that needs to be changed in a different system. In such cases, you can still display a message box.

Navigation to the Corresponding Field on the UI

To help users resolve issues shown in the message popover, guide the user to the corresponding field on the UI. We recommend a three-tier approach:

  1. If the field causing the issue is within the user’s visible area, focus on the field.
  2. If the field causing the issue is on the same page, but outside the user’s visible area, scroll to the field and focus on it.
  3. If the field causing the issue is on a different screen or tab, navigate to the relevant tab, object, or subobject. Scroll to the field on the target page and focus on it. Also open the respective message popover for the target page. Make sure that the popover doesn’t cover the highlighted field.

If navigation to a concrete field on the UI isn’t possible, take users as close as possible to issue. If the issue is caused by a value in a table cell, for example, focus on the affected table.

Back Navigation

When navigating back from a sub-subitem, always navigate back to the subitem first – even if the user was sent directly from the main page to the subitem. This is consistent with the existing implementation for deep links.

Developer Hint
To enable users to navigate to the relevant part of the UI, apply the activeTitlePress event to the message text in the message popover (both in the overview on on the details page).
Navigation to the highlighted issue
Navigation to the highlighted issue

Data Loss

Quick Confirmation Popover

Quick Confirmation for “Cancel” Use Case

The quick confirmation popover can be used to display a confirmation message when the user selects Cancel. The quick confirmation popover is less disruptive than a dialog and the following guidelines apply:

  • It should be displayed close to the action the user has triggered (such as Cancel)
  • For all the other confirmation use cases (including Delete), please use a dialog.

“Create” Case

If the user creates an object and presses Cancel, show a quick confirmation popover with the following text:

Text: “Discard this draft?”
Button: “Discard”

“Edit” Case

If the user edits an object and presses Cancel, show a quick confirmation popover with the following text:

Text: “Discard all changes?”
Button: “Discard”

Quick confirmation popover for
Quick confirmation popover for "create" case
Quick confirmation popover for
Quick confirmation popover for "edit" case

Data Loss Message Box

Behavior for “Cancel” Use Case

If a data loss popover is not feasible, display a data loss warning in a message box.

Data loss warning in a message box
Data loss warning in a message box


Messaging Overview

  • No messages to display?
    If there are no messages to display, do not show a messaging button in the toolbar.
  • Highlight the fields
    If possible, first highlight the relevant field(s) and change its value state according to the message type, such as error, warning, or success.
  • Message popover
    In addition highlighting the fields, a button appears in the toolbar displaying an icon and the number of messages that occurred. This number matches the number of fields that have been highlighted. If multiple messages occurred, they should be displayed in the message popover, which can be triggered via a button on the left side, inside the footer toolbar.
  • Display single messages in a message box
    There may also be messages that have to interrupt the user. At present, we are only aware of technical issues such as network errors and connection issues.


Want to dive deeper? Follow the links below to find out more about related controls, the SAPUI5 implementation, and the visual design.

Elements and Controls


  • No links.