Skip to Content
Technical Articles
Author's profile photo Greg Malewski

How to document your SAP Fiori launchpad configuration?

A typical SAP project includes at least the delivery of documentation for a system that went live. One that the project team can use, to hand over the setup to a support team. Reliable documentation saves the support team tens of working days. This and other reasons for maintaining good documentation are discussed in the blog post below. The post describes as well the approach to the documentation process with Fiori Tracker, a free documentation tool.

Why do you need documentation for the SAP Fiori launchpad?

The need for support comes from the complexity of the links between applications, catalogs, and roles, as well as the number of people who collaborate to keep those links up to date. The popularity of the remote-first operation, often in asynchronous mode, adds to the difficulty of the entire process. Fiori launchpad setup documentation will help project and support team members navigate the Fiori launchpad set up as a product that gets planned, implemented, tested, maintained, and supported.

Planned – you need it as a space to agree and record what you plan to set up and later support.

Implemented – you need it for a handy reference of what you already have in the system. Documentation reference replaces time-consuming emails exchanges, emails searching, or system configuration reviews that require access and technical details awareness

Tested – you need it to clearly address what parts of the product have been tested and what still needs testing

Maintained – you need to tell what is the impact of the requested changes and how to make the best use of what you have set in the system already

Supported – you need it to identify and communicate what parts need fixing and match them with a capable support team member

There is one more important role of the documentation relevant to all the project phases. As the documentation gets approved you can use it to control the project scope. The main part of the documentation is the list of Fiori launchpad enabled applications that directly determine the project’s scope. Adding a new app to the Fiori launchpad, especially a custom one, has a major cost impact thus should be tracked. By keeping the rule of including the app entry in the documentation before implementing it, you will gain scope control, together with documentation accuracy. Additional FT component called Fiori Apps Usage lets you check what apps are launched by users and whether they are part of the scope already.

Why do you need a tool for documentation?

Many projects use a shared Excel spreadsheet to document the Fiori launchpad setup. At first glance, Excel looks like a decent choice for documentation. Unfortunately, in the long run, it will reveal the following difficulties:

– Different team members working on the same spreadsheet can easily cause inconsistencies. It will arise when you involve both functional and technical team members that might have different needs when it comes to documenting Fiori launchpad configuration.

– Excel can only show the 1-N relation of an application mapping to catalogs. When maintaining the catalog’s application list in Excel you will need to hold two lists of catalogs which will lead to duplications, in result inconsistencies.

– It is tricky to separate different authorization levels for members that only read and those who should edit parts of the documentation. For example, you might not want to allow all project members to add or remove applications from the documentation that represents the project’s scope

– Excel does not offer permanent records of the sign-offs. For example, you are going to need lasting records of the application and catalog testing sign-off to proceed with production imports.

– Excel does not hold the history and the authors of the changes.

– For Excels holding records for hundreds of applications, browsing and finding the right records will become impossible – to get the impression have a look at a real project example of the spreadsheet:


Example spreadsheet with apps mapping to catalogs

Freely editable Excel lists, for example for the applications, will not stay stable enough to serve as identification during team members’ and users’ dialogues. Because application identification is a key aspect of ensuring the reliability of Launchpad documentation, you will need to manage it tightly.

Application identification

The application’s records are the core information you’ll need in your Fiori launchpad documentation. Due to the variety of Fiori launchpad applications types, their clear identification is quite a challenge. The main problem the members of the project team face is the lack of a simple and unique identifier for an application. The identifier of choice should precisely point out the technical objects that make the application.

How Fiori Tracker helps to maintain the documentation?

Fiori Tracker is available for free to anyone for download and install. Once installed in one of your systems, you can start documenting your SAP Fiori launchpad contents. We recommend installing and running Fiori Tracker on your QA SAP Gateway. Fiori Tracker comes as a set of independent components, allowing you to choose which content types to track. The component that you need to document all applications, and catalogs, together with mapping between them is Fiori Tracker Core and contains two applications:

  1. FT Applications (with core relation: To-be catalogs) – for keeping “To-be” records of applications in scope
  2. FT Catalogs (with core relation: To-be apps) – for keeping “To-be” records of catalogs in scope


Let’s start with addressing application identification. The solution we have adopted in Fiori Tracker is the following:

We identify applications by relying on the convention used by SAP when specifying the App Id in the Fiori Applications library. This approach tackles two key aspects:

– Identification of standard applications that represent the majority of applications in projects
– Linking an application to its official documentation

Standard applications already have their App ID in the convention F<XXXX><Y> and the SAP Gui transaction name format. This naming way leaves App ids starting with “Z” and “Y” for custom applications and for extensions of the standard applications.

Documenting Fiori launchpad enabled applications

To start off you need to record all applications that you plan to enable in your Fiori launchpad. You can do that with the “FT Applications” app. The app starts with the current list of all applications in your project scope.

Starting view of “FT Applications” app

With the “Add” function you can add a new application entry:

Create application record form in “FT Applications” app

The recorded details include:

  • App ID – the check preventing the creation of duplicates is made
  • Tile title – The title that might be different from the official application name
  • Name – Contains the official application name
  • Area – Functional area is chosen from the list of areas in your project. The list is configurable
  • Type – The type of application is chosen from the list of types in your project. Fiori Tracker comes with predefined application types. The list is configurable.

Technical catalog, Semantic object, and action, flags indicating if an app can be started directly and if it is a lighthouse app are optional. They either serve as additional information or are used by optional Fiori Tracker suite components.

Documenting Fiori launchpad catalogs

Once you are done with applications, you can proceed with creating documentation entries for your launchpad Business Catalogs. The app to manage catalogs is called “FT Catalogs” and starts with the list of the catalogs in the project scope:

Starting view of “FT Catalogs” app

Add button creates an entry for the new catalog:

Create catalog record form in “FT Catalogs” app

The same functional area set is used to assign catalog and use Fiori Tracker reports on a specific stream or to assign stream default person responsible for sing-offs.

Maintaining mapping between catalogs and applications

Once all catalogs are in you can map applications to catalogs. You can do that from a catalog perspective, by opening chosen catalog detail view and its “Applications To-be” relation, and choosing “Edit”:

View on a chosen catalog record and its “Applications To-Be” relation in “FT Catalogs” app

Edit view for mapping application in “FT Catalogs” app

All marked apps get assigned to the catalog. In the same way as for catalogs, the mapping function is available from an application perspective:

Edit view for mapping catalogs in “FT Applications” app

These two apps will significantly reduce the time the project and support team need to agree and handle the launchpad catalogs and their apps. To save even more valuable time there are optional components that link application and catalog to other information records like roles, test users with their passwords, sign-off records, or application usage data.

I hope I have inspired you to give Fiori Tracker a go, and I wish you all the best in keeping your SAP Fiori launchpad team and users happy.

You can download and learn more about Fiori Track on its help page:

Related blogs:

  1. Fiori Tracker – Documentation automated – has a new release


Assigned Tags

      Be the first to leave a comment
      You must be Logged on to comment or reply to a post.