The missing Fiori principle

Published by Tobias Hofmann on

10 min read

When SAP announced Fiori 10 years ago, Fiori was not only about a set of apps. Fiori is about design. It is a design language guided by 5 principles: role-based, coherent, adaptive, simple and delightful.

It speaks for the principles that these were not changes since SAP announced Fiori. From the 5 principles, the first one – role-based – is also the one that caused the most turmoil.

This principle demanded a change in thinking how to develop and deliver apps. To no longer deliver a generic transaction. To go from one transaction to several apps. One app to solve a specific problem for a given role. Applying this principle not only changed the number of apps delivered to end users. Developers were also “forced” to figure out who their users are. This implied that the layers of organizations brought between the developer and the end user over the years had to be torn down. While this brought back the requirement of listening to the end user to the developer, the principle is still based on the role of the user. And not on the user and the users’ tasks itself inside that role. It is not about the user, but about the role in which the user acts. While this seems to be negligible, it is not. While a user can act in one (or more roles), it is still a person. The role might be that of a product manager, with a task to manage the stock of products. The person in the role has yet still very individual, personal requirements.

The missing Fiori principle:



Personal goes a step further than role based. It is the final step in ensuring that the user gets the most out of the app. The Fiori design guidelines already include a section about views for filters or for table personalization. SAP offers UI flexibility in the Fiori Launchpad. This allows to also adopt the UI of the app to individual needs. For the more technical skilled user, additional fields can be added to the app too. Even before these recent innovations, users could do the first step of personalization of the Fiori experience by adding apps / tiles to their launchpad. They were able to select needed apps, rearrange them or put them at the top of the page. This was the base version of a personal Fiori experience. The “save to tile” feature allows to even further personalize the launchpad. From the user entry point to Fiori, the launchpad, personal is possible since a long time.

Why is this an additional principle? For the actual app that is delivered to the user, it is impossible to tailor the app to each and every requirement a user might have. For the role it is possible. This allows to focus on the role for app development. Role based allows to develop apps for a wide range of users, that can then adopt the app via personalization. The last step is highly individual, therefore “outsourced” to the user. Why is it important? The personal aspect is important. It is a unique differentiator for SAP Fiori.


How does this look like? Let’s take as an example a user that has to role of managing products. The task is to check weekly if a specific product is in stock, what is the feedback, etc. The SAPUI5 demo kit contains a sample app that allows to exercise the personalization in detail: Key User Adaption for SAP Fiori Elements.

The manage products app follows the Fiori principles. As a result, it is a rather generic app for managing products. For the example, assume that the user is tasked with not only managing products in general. The task is to monitor computer products that are running out of stock or are sold out or that match a minimum rating.

Personal Fiori Launchpad

The user can personalize the Fiori Launchpad to add the manage product app.

First step of personalization is the add the app to the Fiori Launchpad. Via editing the home page and the app finder, this is an easy task. The user can add the app to a group named “Weekly tasks”. Every user can have different daily, weekly or monthly tasks. Some might arrange for LoB, or for tasks. The launchpad might not look the same for two people in the same company.

View management

The app is perfect for the role, yet too generic for the specific task. There are 31 possible filter values, 20 table columns, and the detail page contains all information. A “problem” with the standard Fiori theme horizon is that some parts are written rather large and bold. Here: Standard at the filter bar. Using a Fiori apps as-is makes this look confusing. Using personalization, this starts to make sense. The task for the user is to check the availability of products in the TV category. Filtering is easy. Personalization is possible by saving the view with a name, like Computer products. This makes entering the filter values a one-time task. A catchy view title helps to understand what is seen.

Saving the filter as a view is already adding tremendous value. Next task can be to adjust the filter bar. Remove what is not needed. Same for the table (for the table is disabled in the example app. Filtering the availability is also not possible, maybe a bug?). Hiding not needed fields makes it easier to consume the presented information.

UI Adoption

This new start page of the app is already highly adjusted to the task of the user. The detail page can also be adjusted to the user. The default detail view is quite extensive. If not to say: confusing. Is all this information needed? Or is something even missing? Some field that was not included in the standard app?

The user might only need a small number of fields. All other is actually too much and distracting. Adjusting the detail page can easily be done by using adoption.

This feature is powerful as not only the controls can be changed. Sections can be added or removed. S/4HANA users can add new fields or business logic.

UI Flexibility

UI flexibility allows a user to adopt the UI as needed, without coding. Fields that are available in the app, but maybe not part of the standard view, can be added, or fields can be hidden. Rearranging fields allows to adjust information display as needed.

The user can hide or rearrange fields. Everything that is not needed for the task can be removed, and information needed added or grouped. In the example, the group Information was adjusted.


Personalization allows users to adjust a Fiori app more to their current task than just to their role. These personal features allow to customize a Fiori app individually. An app can be delivered to the user as a generic app. Developed to fit a specific role. The user can than take the app and adjust it easily to its own needs. Compared to the other Fiori principles, the personal principle cannot be directly implemented by the developer. The developer’s task is to ensure that the app offers everything needed for personalization.

Technically, the missing principle is already there. Unfortunately, many times it is not applied. Once, by customers. Custom freestyle UI5 apps were rarely developed with these features included. And smart controls that come with the personalization feature were not always used, yet unique IDs. But also because of SAP. There are still many older – or legacy – Fiori apps available that cannot be personalized by the user. Developers and end users used to these older Fiori apps simply were not aware of the feature. Starting with Fiori Elements, this should not be an issue any longer. View or table personalization should be included in any Fiori Elements app. The Fiori Launchpad needs to support the personalization too. Here the solution was to ensure it works for the S/4HANA launchpad (cloud, on premise, BTP).

Somehow, the documentation about this great feature is not in the Fiori Design Guidelines, but in the UI5 documentation. With UI flexibility, users can now also adjust the UI layout, and the content, to their needs. Some things are missing to allow users to get the most out of personalization. Adjusting the UI creates a new version of the app. These can be addressed via the parameter sap-ui-fl-version. Adding 2 or more versions as tile is possible, but not so easy for the end user. Here the idea is more like one active version, and not several depending on the user task.


Maybe SAP is going to add personal as the sixth principle to SAP Fiori. Having it listed as an official principal should raise visibility, availability and usage. The more Fiori apps are offering full support of personalization, the better for the user.

Let the world know

Tobias Hofmann

Doing stuff with SAP since 1998. Open, web, UX, cloud. I am not a Basis guy, but very knowledgeable about Basis stuff, as it's the foundation of everything I do (DevOps). Performance is king, and unit tests is something I actually do. Developing HTML5 apps when HTML5 wasn't around. HCP/SCP user since 2012, NetWeaver since 2002, ABAP since 1998.


Leave a Reply

Avatar placeholder

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.