More and more companies are turning to SAP FIORI: FIORI apps are clear, easy to use and ideal for mobile devices. However, authorizations for FIORI work differently than for ERP transactions, which is why a well thought-out FIORI authorization concept is essential. Searching for missing authorizations on the fly and adding authorizations after the fact can become a show stopper.
It is no secret that SAP authorizations are often treated stepmotherly in an implementation project. In the "pre-FIORI era", people often went live with a rough authorization concept that was gradually refined. The way this worked was that the user would call up transaction SU53 when an authorization was missing and send a screenshot of it to the authorization team. The team then determined the missing authorization object, added it to the authorization role, and the user was able to continue working. Although this procedure kept the authorization team busy in the first days and weeks after go-live, it proved its worth in many projects.
Now FIORI is being introduced in the company, and why should FIORI authorizations be handled any differently than ERP transactions? If you think like that, life will punish you - at the latest during go-live. The challenge of finding the missing authorizations in FIORI is big, time-consuming and usually cannot be handled as easily as usual by the authorization team. Reason: The screenshots from SU53 usually no longer help the authorization team to identify missing authorizations.
This is due to the technology on which the FIORI application is built. The user works with the FIORI interface, where he enters his data. This is our frontend, which runs in a browser. The request from the FIORI app is addressed to the SAP system, because that is still where the database that processes our request is located. This is the backend system. So the data entered in the FIORI app is transmitted to the backend, using an interface called OData. Authorizations in FIORI are thus divided into different levels. Due to the technological conditions of a front (gateway) and backend system, authorizations must be assigned in both systems - unless an embedded gateway is used.
Firstly, it must be ensured that the relevant FIORI apps can be used by the user in the FIORI launchpad. For this purpose, the FIORI catalog and the corresponding FIORI group are assigned to the user.
Secondly, the user must be authorized for communication between the front-end and back-end systems and the OData services used by the app must be activated.
If the user lacks these authorizations when running a FIORI app, transaction SU53 often fails because not all authorizations are tracked by SU53. If this is the case, one reaches for further tools such as transactions /N/IWFND/ERROR_LOG or /N/IWBEP/ERROR_LOG. If this is also unsuccessful, debugging is often the only option. It goes without saying that the authorization adjustment then becomes much more time-consuming. If you multiply the effort by the number of errors, the result is an extremely unfavorable situation during operation. How can this be avoided?
Don't let it get to the point where time-consuming authorization adjustments become the order of the day during ongoing operations. A well thought-out authorization concept is the be-all and end-all for successful use of FIORI. The good news is that SAP has developed a helpful tool here: The FIORI Apps Library. The library is a publicly accessible collection of all FIORI applications that are available. In addition to the description of the application, it contains further information that is helpful for using and implementing the app, but also for creating an authorization concept.
Here's how it works: you enter a search term in the FIORI Apps Library, say "create purchase order" or "ME21N". Press Enter to display a hit list of all FIORI Apps matching the search term. Select the app you are looking for, and you will be shown important information about permissions, among other things:
ICF nodes and OData services required for the app.
Required target mappings for the FIORI catalog
Catalogs and "ready-to-use" business roles provided by SAP in the standard system.
Once you have identified a business role that you want to map in your company, it already contains most of the applications required for this. It is recommended that you only activate the FIORI apps that you actually need.
It is also possible to access the FIORI App Library via industries, roles, SAP Best Practices and other objects. Experience shows that in order to minimize the risk in ongoing operations, it is worth taking a closer look at FIORI authorizations in advance.
But especially at the start of an S/4HANA project, you want to get an insight into the existing FIORI apps as quickly as possible - even if the authorization concept has not yet been created. Does the authorization team have to be involved here from the start? Or can the SAP_ALL simply be assigned?
Both questions can be answered with a "no". SAP_ALL authorization is indeed the proven solution in sandbox systems to avoid the authorization problems, but you will not see any FIORI apps in the launchpad even with SAP_ALL. FIORI catalogs and groups are not part of the SAP_ALL authorization.
Now, to avoid having to create an elaborate authorization concept in the initial phase, you can simply assign your users the standard SAP business roles that you find in the FIORI Library. This gives the user all the authorizations to display FIORI apps in the Launchpad and also to execute them without errors. In addition, all necessary configuration steps for the FIORI Apps contained in the business role can be carried out quickly and easily by SAP Basis via a so-called task list.
In summary, a detailed FIORI concept is essential for the success of your S/4HANA implementation with FIORI. For the start of the project, however, it is completely sufficient to work with the business roles provided by SAP in order to quickly get to know FIORI Apps.