Reasons to document Fiori Launchpad applications externally

[GregMalewski]

Introduction

Keeping a list of your SAP Fiori Launchpad apps outside the system is crucial. It helps you track custom apps, find them quickly, and store extra details. An external registry is especially useful when the Fiori Launchpad isn't accessible.

Core arguments explained

Maintaining a robust registry of all applications outside the SAP Fiori launchpad is necessary for the following reasons:

1. Inclusion of custom applications

Projects typically include a substantial number of custom and extended applications. In addition to utilizing SAP's standard Fiori library, your project team also requires a reliable documentation reference for these unique IDs associated with your custom and extended applications.

2. Efficient searchability by unique app ID

Project members need to be able to identify and locate applications, and their accompanying details swiftly by their unique ID. Team members need a unique handle to tell the correct application when communicating with each other. This functionality is critical during the development, testing, and support phases. The Fiori launchpad, with its focus on user experience rather than project-specific needs, does not facilitate this level of reference. Consequently, there is no reliable way to find an app solely by its ID in the Fiori launchpad.

3. Capability to retain supplementary details

App details like application type or technology help match the request with capable support team members or plan the upgrade tasks. During the implementation app's functional stream assignment helps to identify the app's responsible person. App IDs linked with catalogs and roles tell you what will be the impact of the planned changes and let you take full advantage of the current SAP Fiori launchpad setup. In the case of SAP standard apps, you will find those additional details in the SAP Fior library although you might want to have some of those details adjusted to your specific needs. For custom apps, you are going to need a place to store supplementary details.

4. Accessibility without using Fiori Launchpad

Recording the decision to include an application in the Fiori launchpad configuration is imperative for project management. This record helps to circumvent debates about whether an application should be available but isn't and to maintain control over the project's scope. Given the significant implications, including cost, of adding an application to the scope, such a decision must be deliberate, not an inadvertent result of an entry in the Fiori launchpad configuration. Additionally, there are occasions when the project team may need to consult the application registry while the Fiori launchpad is not accessible, particularly during system troubleshooting, upgrades, or migrations (such as transitioning from SAP Gateway Hub to an embedded system). This registry is also vital in the early phases of a new system implementation before the SAP system is operational for login. Furthermore, the registry serves as a key resource for configuration provisioning, which is a time-intensive process involving developers, functional consultants, and the roles and authorizations team, all of whom must coordinate the handover of requirements.

 Summary

Even a simple list of the applications in scope and their identifiers saves the implementation and support teams tens of working days. It has saved weeks of work on our projects and allowed us to focus on development and technical issues instead of spending time on repeated meetings and lengthy communication. Therefore, I encourage everyone in the Fiori space to keep documentation and make S/4HANA implantations faster and less costly.

I’m curious to hear your opinions – feel free to comment or contact me on Linkedin.

See also blog posts on Reasons to use a tool to document Fiori launchpad, and Practical project roles in SAP Fiori application handling.