Intro

The Settings dialog is a centralized configuration space where users can manage personal preferences such as account details, appearance, language and region, accessibility, and notifications. It lets users tailor their experience without leaving the current product context.

When to Use

Use the Settings component when users need to access or modify settings without navigating away from the current page. For content guidelines, see the Content Area tab.

Anatomy

The Settings dialog includes:

1. Header with title: A dialog header with a fixed position.
2. Settings item with an icon: Represents a settings section.
3. Fixed header with title: A settings section header with a fixed position.
4. Content area: Contains swap slots and can accommodate different components. The content area is not part of the Settings dialog base control. The core dialog component provides structure only, leaving content to be determined by the use case or line of business. For details, see the Content Area tab.
5. Dialog footer with action: Closes the dialog.

Anatomy of the Settings dialog

Additional Features

1. Search: Search is an optional feature that lets users search across the left menu items. Offer the search field when there are many menu items and the list requires scrolling. Avoid it when there are only a few items and no scrolling is needed.

Search in the Settings dialog

2. Tabs: Use tabs when a settings item contains a lot of related information that can't be split into multiple sections.

3. Fixed settings item: Pins the settings item to the bottom left. Use this when a settings item needs to stand out and stay fixed while the rest of the list scrolls.

Tabs for a settings item (2), fixed settings item (3)

4. Back button: Use the Back button :icon-nav-back when users need to drill into several levels of a settings section and navigate back.

Back button

Behavior and Interaction

The dialog takes full focus, interrupting current app processing and dimming or blocking the main screen. It appears at the center of the screen.

A toast appears after the dialog closes and the settings are applied.

Toast message after applying settings

Search

Search filters the existing list of menu items as the user types. This differs from "Search as you type" in that items are already displayed before the user starts typing.

Settings dialog with search – default

Filtering begins after the user enters the first character. The filter uses a "starts with any" pattern: items are included when any word in the label starts with the typed characters. If the result list contains the currently selected item, the selected state is still shown.

Settings dialog with search – search result

Save behavior

Implicit save is the recommended behavior for user settings, regardless of layout. The sections below describe other available approaches.

In-page experience – implicit save

In this pattern, settings appear directly on a dedicated page in the application. Use this pattern for larger configurations or settings that require more space, structured content, or multiple sections.

Best practices:

• Apply changes immediately after user interaction.
• Use a message strip to give users instant feedback so they understand what changed.

In-page experience – explicit save

In this pattern, settings appear on a dedicated page and changes are applied only after the user selects the Save action. Use this model for complex configurations where users may modify multiple settings before committing their changes.

Best practices:

• Provide persistent Save and Cancel actions using a floating footer.
• Prevent navigation away from the page without confirming unsaved changes.

Dialog experience – implicit save

In this pattern, settings are presented in a modal dialog and changes are applied automatically when the user modifies a setting. Use this approach for quick configuration tasks that don't require an explicit save action.

Best practices:

• Apply changes immediately after the user modifies the setting.
• If the change triggers a system action (for example, a page reload), inform the user before applying it.

Dialog experience – explicit save

In this pattern, settings are presented in a modal dialog and changes are applied only after the user selects the Save action in the dialog footer. This approach is suitable when the dialog contains multiple settings that users should review before applying the changes.

Best practices:

• Provide Save and Cancel actions in the dialog footer.
• Apply changes only after the user selects Save.
• Clearly indicate when the dialog has unsaved changes and use in-field validations where required (dirty state).
• Discard changes when the user selects Cancel or closes the dialog.

Navigating away from "Settings"

Sometimes a setting requires users to leave the current Settings dialog or page to complete additional configuration elsewhere in the product.

Best practices:

• Avoid navigating away from settings whenever possible. Settings dialogs are designed for quick, focused configuration within the current context.
• Navigate away from settings only when the configuration requires complex workflows, large forms, or specialized management screens that can't be accommodated within the settings experience.
• Clearly communicate when a setting will take users to another location in the application.
• Clearly communicate if navigating away could result in data loss.
• Provide a clear navigation affordance (for example, a link or navigation indicator) so users understand that additional configuration exists elsewhere.

Unsaved changes in the product screen

Before opening the Settings dialog, handle any unsaved changes in the product screen. This prevents data loss.

If the product screen still has unsaved changes when settings are saved, show a confirmation dialog to warn the user that these changes will be lost.

Responsiveness

The Settings dialog behaves differently on a smartphone than on a tablet or desktop.

Size S

On size S (320px), the dialog can be stretched to fill the screen or used as a standard dialog. To enable full-screen mode, set the stretch property to true (the default is false).

We recommend using the dialog in full-screen mode to help users focus on the content. This applies to both portrait and landscape orientations. Note that the height of the dialog may increase automatically if the text size is significantly increased.

Size S (mobile) – 320px

Size M

If the content height exceeds the screen height, users can scroll through the content area.

• Minimum width: 80% of the screen size
• Minimum height: 88% of the screen size

Size M – 600px

Size L / XL / XXL

The following values apply for sizes L (1024–1439px), XL (1440–1919px), and XXL (≥ 1920px):

• Minimum width: 960px
• Maximum width: 960px
• Minimum height: 680px or 88% of the screen size
• Maximum height: 680px

If the content height exceeds the screen height, users can scroll through the content area.

Sizes L, XL, and XXL

Accessibility

SAP follows international standards, such as WCAG and WAI-ARIA, and strives to make our business solutions accessible and inclusive.

For more information, see Accessibility in SAP Fiori and the Accessibility Design Tools Handbook.

Keyboard navigation

The following keyboard combinations are supported by the settings component.

Note: On Mac, use Command (⌘) in place of Ctrl.

Screen reader support

For additional details on screen reader support and Accessible Rich Internet Applications (ARIA), see SAPUI5 Screen Reader Support and WAI-ARIA Authoring.

Related Links