Something went wrong. The user needs to know. Do you block the screen with a modal dialog, or flash a small toast at the bottom and let them keep working? SAPUI5 gives you both — MessageBox and MessageToast — and mixing them up is one of those small UX sins that makes an app feel unpolished.
Here's how to choose, with code for the patterns you'll actually use.
The fundamental difference
MessageBox is modal and blocking. It darkens the screen, demands attention, and waits for the user to click something before they can continue. It's a conversation: the app asks, the user answers.
MessageToast is non-modal and transient. A small strip slides up from the bottom, shows a message for a few seconds, then disappears on its own. The user never has to dismiss it and never stops working. It's an announcement, not a conversation.
Ask yourself: does the user need to decide something, or just know something? Decision → MessageBox. Awareness → MessageToast.
MessageBox: errors, warnings, confirmations
The MessageBox API is static — no instantiation, just calls. The three you'll use constantly:
sap.ui.require([
"sap/m/MessageBox",
"sap/m/MessageToast"
], function (MessageBox, MessageToast) {
// Error: something failed, user must acknowledge
MessageBox.error("The order could not be saved. Check the highlighted fields and try again.", {
title: "Save failed",
details: sTechnicalDetails, // expandable "Details" link
actions: [MessageBox.Action.CLOSE]
});
// Warning: proceed with caution
MessageBox.warning("This customer has 3 overdue invoices. Create the order anyway?", {
title: "Credit check",
actions: [MessageBox.Action.YES, MessageBox.Action.NO],
onClose: function (sAction) {
if (sAction === MessageBox.Action.YES) {
that._createOrderAnyway();
}
}
});
// Confirmation: destructive or significant action
MessageBox.confirm("Delete 4 selected line items? This cannot be undone.", {
title: "Confirm deletion",
actions: [MessageBox.Action.DELETE, MessageBox.Action.CANCEL],
emphasizedAction: MessageBox.Action.DELETE,
onClose: function (sAction) {
if (sAction === MessageBox.Action.DELETE) {
that._deleteItems();
}
}
});
});A few details worth knowing. The details parameter on error() adds an expandable section — perfect for stashing the technical message or backend error payload while keeping the main text human-readable. emphasizedAction highlights the primary button, which matters for destructive confirmations where the safe choice should be visually obvious... or rather, where the intended choice should stand out.
MessageBox also has success() and information() variants, but use them sparingly. A modal dialog celebrating every successful save gets exhausting fast. Which brings us to...
MessageToast: lightweight confirmations
MessageToast is one line, no decisions, no drama:
MessageToast.show("Order 4711 saved");
// with a wider toast for longer text
MessageToast.show("Draft saved. It will be submitted automatically at 18:00.", {
width: "24rem",
duration: 5000 // milliseconds before it fades
});The classic use cases: "Saved", "Copied to clipboard", "Draft discarded", "Filter applied — 12 results". The action completed, nothing is wrong, the user just deserves acknowledgment. A toast says "noted" without interrupting flow.
Toasts stack politely — firing several in quick succession queues them rather than overlapping. And they're automatically positioned above the mobile bottom nav if your app uses one, so they don't hide navigation.
The most common MessageToast mistake: using it for errors. A toast that says "Save failed" and vanishes after 3 seconds is a UX bug — the user may never see it, and even if they do, they can't act on it. Errors need the persistence of a MessageBox (or better, the MessageManager — see below).
Where MessageManager fits
There's a third player worth mentioning. When validation fails on form fields — a missing required value, a badly formatted date — neither a modal nor a toast is ideal. You want the error attached to the field itself, with a summary the user can click through.
That's sap.ui.core.message.MessageManager. Register it on the view, add messages against binding paths, and the framework routes them to the right controls automatically:
// in the controller
var oMessageManager = sap.ui.getCore().getMessageManager();
oView.setModel(oMessageManager.getMessageModel(), "message");
oMessageManager.registerObject(oView, true);
// when validation fails
oMessageManager.addMessages(
new sap.ui.core.message.Message({
message: "Delivery date cannot be in the past",
type: sap.ui.core.MessageType.Error,
target: "/Orders('4711')/DeliveryDate",
processor: oODataModel
})
);Fields bound to that path show ValueState.Error with the message inline. Pair it with a MessageView in a popover for the "3 errors — click to navigate" summary pattern. For form validation, this beats both MessageBox and MessageToast.
Decision cheat sheet
MessageBox.error — operation failed and the user must know before continuing. Always include what happened and what to do next. Stash technical details in details.
MessageBox.warning / confirm — the user is about to do something with consequences: deleting, overwriting, proceeding despite a risk. The dialog exists to get an explicit decision.
MessageToast — action succeeded or a background event occurred; no action needed. Keep the text under ~10 words. If the message needs more than a glance, it's not a toast.
MessageManager — field-level validation in forms. Errors live on the controls, with an optional summary popover.
Nothing at all — underrated option. Not every state change needs announcing. If the UI already shows the result (the new item appears in the list, the status flips to "Saved"), an additional toast is noise. Experienced Fiori designers treat silence as a valid feedback choice and reserve toasts for moments when the UI alone doesn't confirm what happened.
Bottom line
Modal for decisions and failures, toast for confirmations, MessageManager for field validation, silence when the UI speaks for itself. Get this small choice right consistently and the whole app feels calmer and more professional — users can't always say why, but they notice.