This is the first part in a series of articles meant to give some more background information on the most important aspects of SAP Fiori 2.0, the user experience for S/4HANA. In this post, I will explain the different ways you can organize and manage applications in the SAP Fiori launchpad.

The launchpad is the environment in which all SAP Fiori applications run. Much of the glue and integration functionality (such as navigation, search, and notifications) that create a coherent experience across the apps is located in the launchpad.

One of the most important functions of the launchpad is to provide access to all the applications that a user needs.

Navigation vs. Discovery


There are two fundamental use cases for a user to access applications:

  1. Navigation: the user knows that there is an app that he wants to use and he needs an easy way to navigate to it.
  2. Discovery: the user has to complete a task and he assumes that there is a suitable app for this, but doesn’t know which one and therefore needs an easy way to discover the appropriate app.

Of course, in an enterprise environment there are generally clear rules about which users/roles are allowed to use which applications. An administrator will typically assign the user specific roles with the assumption that the user’s tasks have already been well defined. This was the principle on which current navigation concepts were based. Navigation consisted of a curated catalog or repository of apps from which the user could select.

However, as we learn more about our users and about how they are using the system, we want to be able to provide more tailored recommendations. There is also a certain level of fuzziness in the practice of role-assignment that we want to avoid. Often, administrators tend to define roles either too widely or too narrowly, risking either too liberal of an authorization, or forcing the user to request access to individual apps manually. What often ends up being the case is that users need to overcome certain hurdles to access the required functionality, and ultimately decreases effectiveness.

With SAP Fiori 2.0, we have developed a more granular concept to support easy navigation as well as discovery.



The primary place where a user will look for applications is the home page. This is the heart of the launchpad and the starting place for the user. The home page is similar to the corresponding concepts on mobile platforms or common operating systems. It’s a place where the user can create shortcuts to the apps he or she uses most frequently.

This also means that the home page should be considered a place where the user – and not the system administrator or boss – is king. Much of the functionality that allows administrators to make apps or groups of apps permanently visible and fixed to a certain position on the home page, though useful, ultimately reduces the users’ freedom and should be handled with extreme care. After all, who wants to own a home where other people decide on what furniture to buy and where to place it?

By combining launching and dashboard functionalities, the home page offers more flexibility than a regular desktop or device home without increasing the level of complexity for the user:

  • Launch tiles are used to represent the individual apps (or variants of these, using the apps Save as Tile function), similar to the app icons you might find on a desktop. In addition to their pure launching function, tiles also offer enough space to display information from the corresponding apps, such as a counter, KPI, or even data visualization. As the user can define what tiles should be visible on the home page, he or she can use this functionality to create an individualized dashboard.
  • The link area allows for an alternative visualization of apps on the home page as simple textual links. This possibility is extremely useful if a user needs direct access to a group of apps that don’t necessarily offer content worth visualizing on launch tiles.
  • Tile groups allow the user to better structure the home page according to his or her needs. Related apps can be grouped together. The groups also serve as anchors for the navigation bar on top of the page, allowing the user to scroll directly to a specific group. Within each group, either launch tiles or textual links can be used. This allows the user to control content density and the kind of information displayed on the home page.
  • The edit mode offers additional functionality to control the visibility and placement of apps and groups on the home page. To add new applications to the home page, the user can access the catalog. The catalog, which was introduced with the initial version of SAP Fiori, contains all the apps that are available to the user. For SAP Fiori 2.0, this catalog will be replaced with a more powerful “app store”-like component, which will be described later on in this article.


App Navigation


Initially, the navigation concept in SAP Fiori was inspired by mobile operating systems in the sense that apps were launched from a central home page. To access another application from within an open application, the user would need to return to the home page. This navigation concept, the so-called hub-and-spoke model, is simple and intuitive, but it doesn’t scale to a large suite of business applications.

Traditionally, this issue would have been solved with navigation menus that either reside on top or on the left of the screen, revealing the fixed navigation structure of the environment. Unfortunately, such an approach not only takes up valuable screen real estate, which is not an option for mobile use, but it also creates unnecessary complexity. Assuming that the home page holds access to all the apps that the user needs to accomplish his or her tasks, and assuming also that these apps sequentially guide the user through each task, having a comprehensive navigation menu would likely end up being more distracting than helpful.

We therefore decided to take a different approach to navigation for SAP Fiori 2.0. In addition to keeping the original hub-and-spoke navigation, we also introduced an additional navigation menu. While not yet fully implemented (2 and 3 are still lab preview), the navigation menu potentially offers three different navigation approaches:

  1. Hierarchy navigation: For every app, each screen forms part of a screen flow, which was defined during the initial design phase. No matter which screen the user chooses to access, the hierarchical navigation of the launchpad will offer the user the option to navigate to the parent screen of the corresponding app. For example, if a user receives an email notification for a work item, he or she can access this work item by clicking the link in the email. If the user now wanted to access the related worklist, this would not be possible using a historical back navigation. Instead, the worklist would need to be derived from the application structure and exposed in the hierarchy navigation.
  2. Related apps: Many apps form part of a bundle of apps that support similar tasks or different aspects of a domain. Such apps can be offered as a recommendation to the user depending on the current context and based on different heuristics. An example would be the My Opportunities app for field sales representatives (in CRM). This app forms a natural bundle with other CRM apps such as My Contacts, which could easily be accessed through a list of related apps.
  3. All apps: If none of the above proposals are sufficient, the user can also access the full navigation menu. This menu provides the user with structured access to all apps in the catalog. Compared to the traditional approaches of using a fix masthead or top level navigation, this menu is only temporarily visible on the screen and can also be used on a mobile phone.

While not technically part of the navigation menu, the launchpad will also offer an additional way for the user to navigate through SAP Fiori through a frequently used apps option in the so-called Me Area (more on this area in the next blog). This is an especially useful feature for users who only use a small number of apps on a frequent basis. In addition to this, the SAP Fiori launchpad will also provide separate access to both an app history and a used objects history.


If a user needs to find a certain functionality or application, but is not sure whether this is available or how it’s called exactly, the user will benefit from an intuitive way to browse and explore the available apps. For this purpose, we are planning to introduce the App Finder, an “app store”-like interface that will list all the apps that a user might potentially use. Apps in the App Finder will be sorted in the following way:

  1. Frontend server catalog: All apps that an administrator has added to the catalog in the frontend server. These are the apps that would typically appear in the user’s catalog of the SAP Fiori launchpad.
  2. User menu (SAP Logon): All apps that have been assigned to a user in a specific system. These are the apps that a user would find in the user menu in SAP Logon when logged on to a specific system.
  3. SAP menu (SAP Logon): All apps in a system, no matter if they were assigned to the user, or if the user has access to it. These are the apps that a user would find in the SAP menu in SAP Logon when logged in to a specific system.

As this is under development, this should be considered a lab preview with no commitment to the final product scope.

Let’s take a look at the case of the frontend server catalog apps. As the image illustrates, the idea of the App Finder is to feature applications either based on administrated rules or on matching algorithms, as is common in store interfaces.

Other common functionalities such as application descriptions, screenshots, and community content should accompany these apps so that the user can get a better idea of whether an app might be useful. From the App Finder, the user will be able to directly open an app or add it to the home page as part of his or her favorites. If the user doesn’t have access rights for a specific app, he or she should be able to directly request the rights through a GRC process.

While Top Apps features specific apps along certain recommendation criteria, the For You and All Apps perspectives offer a hierarchically structured view of different system-specific catalogs. Here the user can search or browse the entire catalog for suitable apps.

Even though the App Finder is not really a store in the sense that users can purchase and download apps, it is nevertheless a well-established paradigm that every user knows how to handle. Users will, however, be able to launch the apps, add them to the home page, and rate them.

Take Aways

With SAP Fiori 2.0, we have significantly enhanced the way apps are managed, making it even more suitable for a large suite of enterprise applications. With the distinction between navigation and discovery, we can now offer much more targeted support for the individual use cases. We are introducing new functionality to manage the user’s favorite apps, to navigate between apps, and to discover new apps without sacrificing the design principles of adaptiveness and simplicity. Furthermore, we are laying the foundation for contextual navigations and recommendations of applications, an area that will heavily evolve within the upcoming years.

At SAPPHIRE 2016, we showed a preview of SAP Fiori 2.0 in our development systems and the feedback was extremely positive. Parts of the abovementioned functionality will be included in the next releases of S/4HANA.

Not logged in
  • Anonym  4 years ago

    Which of the new Fiori 2.0 features are aviable in SAP /HANA as opposed to S/4HANA ?

    • Kai Richter   4 years ago

      Hi Adam,

      I am not sure what you are referring to with S/HANA? Is that Suite on HANA? I am not sure that Fiori 2.0 is available for Suite on HANA.

      So what you see in this article has been released to a significant part with the 1610 release of S/4HANA. This includes:
      – the viewport layout and animation
      – the me-area with settings, recent items
      – the notifications
      – a first version of the AppFinder (currently just with the catalogue tiles and the user menu and sap menu and no details pages etc.)
      – the navigation menu (without related and all apps)

      Most of those features are planned to be developed further with the upcoming releases to reach the target design presented here and to include enhancements and improvements based on user feedback. We plan to have most of the features completed with 1705 and 1708.

      I hope this helps.

      Best regards

    • Anonym  4 years ago

      We have Business Suite as opposed to S/4 HANA. Which Fiori 2.0 features can we use for Business Suite as we don’t have S/4 HANA

    • Supriya Bhatt   2 years ago

      Hi Kai,
      Thanks for this forum.
      Do we required extra overhead/cost to migrate all custom based appliactions developed in
      S/4 HANA 1610 version with FIORI ERP Application X1 1.0 release(with Front end server 4.0) to
      S4/HANA 1809 version with FIORI 2.0 (with Front end server 4.0)?
      Is that makes any difference in programming or migrating the application from S/4 HANA Fiori 1.0 to Fiori 2.0?


    • Kai Richter   2 years ago

      Hi Supriya,
      thank you for your feedback.
      Please understand that this forum is about design questions where we want to share and exchange on the design aspects of our products. Unfortunately, we can’t provide you with the technical answers you seem to be interested in. There are other forums on where you will find contact to technical experts.
      From a design perspective, we try to keep new design iterations compatible with existing solutions and we usually provide migration strategies that in most cases are automatically implemented in the UI technology. This includes the main change between Fiori 1 and 2 regarding the application title that can be switched off and will then be merged in the shell title.
      Thank you for your understanding.

  • Olaf Theiß   2 years ago

    Hello Kai,

    thank you for your explanation!

    I want to implement a launchpad to navigate within one single app.
    How do I have to install a tile to navigate
    a. to a single view within an app or
    b. to navigate to an app within an app (e.g. another app structure within the webapp) and
    c. how do I have to build the authorization/authentification in this case?

    e.g.: One accounting app with an area for booking and another area only for showing information.


    • Kai Richter   2 years ago

      Hi Olaf,

      thank you for your question.

      In fact, the home page is not intended for in-app navigation but the tiles should represent different apps. The way the home page is filled technically, is also through catalogues that contain references to the different applications and those references are no static links but resolved based on authorization etc. Therefore, in a standard home page you will also run into technical challenges.

      If you have clear (static) links into the different parts of your application, you could construct this setup but again, this is not recommended.

      What are the alternative options?
      – Use an overview page ( this is exactly what you need as the cards offered in the overview page can point to different aspects of your domain and don’t have the strong semantics of individual applications. Cards can also provide some insights into the apps or lists of relevant items so that you can much better jump into the right place of your app.
      – Use the side navigation ( if you really have a huge and complex app with many parts. This left side navigation panel can allow you direct navigation to any of these parts at any time.

      Finally, you can of course create smaller, task oriented apps that can be managed in the home page or an overview page as individual apps or cards showing more information.

      I hope this helps you find the right solution for your challenge?

      Best regards

    • Olaf Theiß   1 year ago

      Hallo Kai,

      thank you for the helpful answers.

      The overview-page is part of the cloud app but it should be optional for customers we develop apps for.
      As you recommended, we will think about an mandatory implementation oft he overview-page.

      I think, implementing a side-navigation is no possible option because we’re developing mainly operational apps.
      Side-navigation is „not intended for use in regular SAP Fiori applications“.
      We strictly develop our apps by considering the Fiori Giudelines.
      So we only use side-navigation in pure technical apps or apps for administrators.

      I have two more questions:
      – How is it possible to show tiles including micro-charts on the Fiori Launchpad (non-ABAP)?
      – Could you please explain the difference between connecting the Launchpad firstly by hosting an app (with URL) and secondly by connecting it by using an HTML5 repository?
      Our technical infrastructure: SCP, HANA, CFoundry, non-ABAP.

      Thank you very much!

      Best regards