Skip to Content
Product Information

Fiori Tracker – Fiori at scale tooling that cuts deployment time


Update from 19 October 2020: Fiori Tracker has new release (2020 FPS01)

The challenge

Fiori Tracker came to life as a result of the struggle that we faced on our S/4 HANA project, with 800 applications enabled through Fiori launchpad. Agreeing with Functional experts on how apps should be grouped and then exposed through roles set by Basis experts was taking way too long. Massive Excel spreadsheets (separate for each of 8 streams) with lists of apps and, each made in its way, requirements coming from Functional experts to Basis in different formats, same apps installed by different people, and those were only some of the issues that were making the whole technical process a nightmare.

At first, we managed to merge all the requirements into one XLS file. The resulting Excel was a large vlookup-driven set of tabs. To keep it consistent when adding or changing content was almost a full-time job. Only this way we finally started getting functional requirements in line with what Basis could do in the system. Lastly, Basis could prepare the roles for the testing users, getting us closer to project goals.

Scope changes

Even if you are not iterating in an agile way, the change into the initial design of catalogs will eventually reach you. After each round of tests, the contents of the groups and catalogs will need adjustments. Moving and adding apps is a vital part of any project stage and gets more and more intensive with closing to go-live. It became critical for a technical team to know what are the already tested and approved apps and what is a late addition that the team has not yet verified.

In the described case we have started from scratch but also in case of starting with copies of standard roles and catalogs (which is the current SAP recommendation) at some point, the content of you copied groups will differ from what you started with, so the need to document changed contents is still there.

Move to the app

Seeing the effort needed, we knew that instead of spending the time to keep massive Excel consistent, we could develop an app that does the same for us automatically. We moved all apps and their assignments into tables and exposed them with the Fiori app. Now all project members got one, always up to date, central view on the “to-be” state. It was clear which apps are new arrivals that still need testing and which the team tested already. We also gained clarity on responsibility. It became clear which Functional areas are ready and which are still in preparation. Plain decomposition of the status tuned out to be a crucial factor in the project’s accomplishment.

Year after the first version

Once a central repository of all Fiori launchpad apps, catalogs and roles were in one place, the additional needs around them voiced by customers, set path for other functions:

  • Data on apps usage
  • Roles to users assignment
  • Status on open issues
  • Change requests
  • URL reference from documentation in Solution manager
  • URL reference from reported problems
  • Registry of test users
  • Reports for the audit team
  • Reports for PMO (Project manager) on Functional area preparation progress, and controlling project scope (separately on app types)

We ended up with a set of apps that are now called Fiori Tracker. Those apps automate the daily work and save the time of not only for UX lead (Fiori developers), Basis and Functional experts but also:

  • Testers
  • Support experts
  • PMO members (Project manager)

Feature overview

Fiori Tracker allows you to document and review both “to be” and “as is” state. By “to-be,” we understand what is the planned setup of your applications as a result of decisions taken by functional experts in the “Prepare” phase. “To be” state serves as a reference for your provisioning during the “Realize” and “Deploy” phases. In case there are issues with apps, “To-be” allows you to make sure what applications are in the scope of the solution and how the project team should configure them.
We gathered the main functionalities in role-based Fiori apps. The main ones are:

  • Applications
  • Catalogs
  • Roles

All three have similar architecture and start with the lists supported with As-you-type suggestions and filters on functional area and application type. From the lists you can drill down into specific Fiori content object details and type-specific information. On this level each object has three tabs:

  • “To-be”
  • “As-is”
  • Info records

Wherever the data is system-specific, you can read it separately for each of the chosen “managed systems.” UX lead defines the “managed systems” as a Fiori Tracker configuration activity. For example, you can review a specific application usage separately for your development, quality, and production system.

Here is the summary of available functions for Applications:



The same set of records is used to support usage records collected in the “Application usage” app.

Feature highlights

“Applications” app lets the user drill down from app-level to its details and catalogs that UX lead assigned it. In contrast to Excel spreadsheets, it is easy to navigate even if apps belong to many catalogs.

Info records provide additional information like:

  • History
  • Sign offs
  • Provisionings
  • Comments
  • Change request
  • Test users (separately for each managed system)

“Catalogs” app in a similar way as “Applications” lets the user drill down to applications and roles. Same “Info records are available.

“Roles” app also gives links to the list of catalogs, applications, and users. Fiori Tracker presents the “To-be” user to role assignment separately for each of the “managed systems.”

You can install Fiori Tracker by downloading the transports from GitHub and following the installation steps described in the readme.

If you are interested in more details on Fiori Tracker functionality, please check the manual at and the description of some of the use cases at

Let me know in the comments if you think that Fiori Tracker could be useful in your project and what other functions you see as valuable in the context of managing SAP Fiori launchpad content.


You must be Logged on to comment or reply to a post.
    • Hey Bharath,

      Thanks for your comment. I have updated


      That was the fastest ever launch of Fiori Tracker. From importing the transports to enabling the Managed system in just two calls. And it would have been just one call if it wasn’t for our mistake (one object was missing in the import).

      Excellent work!

      Best regards


  • Hello Greg,

    We are having some issues in the configuration of Fiori tracker on S/4HANA ON PREMISE 1909.

    1. Unable to find the service ZFIORIODATAMNG for Odata Manager tile
    2. View of Requests & Requests Admin Tile tile is not found (RequestList.view.xml not found)
    3. Cannot read property 'SID' of undefined error for Application Usage and  Application usage Missing apps tile.

    Can you please let me where we can find the detailed document for configuration of Fiori tracker so that we can follow the same and resolve our issues.

  • Thanks Grey!

    We installed the latest release as suggested for Fiori Tracker Core (2020SP03), there is only one role in the Transport and that role holds 2 tiles in the catalog - Applications and Business Catalogs. Unable to view rest of the tiles.

    I wanted to check if it is mandatory to import transports for,

    1. Catalogs Report (2020FPS01)
    2. Installation of  'As-is' Main API located on Central system (2020FPS01)
    3. Installation of  'As-is' Connector located on Central system (2020FPS01)
    • Hi Keerthi,

      Starting from release 2020, we have decoupled Fiori Tracker Suite apps into separate products. So the look in the Fiori Launchpad will differ from the one you see in the blog post.

      Fiori Tracker Core's two tiles that you got are correct as this product brings the core function for documenting your project in-scope apps, catalogs, and links between them.

      If you want the "As-is" functions proceed with the "As-is" API and Connector.




    • Hi,

      Not yet. We are preparing for the SAP Cloud version and are open to anyone who would like to help to test it on its installation.



  • Thanks Grag, for such amazing SAPUI5 utility for Fiori applications tracking purpose.

    Just quick question, we have installed 1909SPS08 version Fiori tracker in our landscape, In this version of tracker will defect all our standard Fiori application and custom application configuration automatically from the gateway system or do we have to create each and every tile, role, catalog and business group entries in this Fiori tracker Administration application in order to mange application usage?.

    Please advice to us.


    Ganesh Babu

    • Hi Ganeshbabu,

      So glad to hear it! 🙂

      Fiori Application Usage component will log all apps usage for users with Fiori Tacker Plugin role regardless of the "To-be" entries in Fiori Tracker Core. This means it can run independently. Fiori Tracker Core gives the friendly naming and linkage to other launchpad content objects like catalogs and roles and additional info records like sing-offs.

      Best regards


      • Thanks Greg for your quick response. 🙂


        We are glad to see Fiori tracker plugin in the launchpad services. one thing is it necessary have  to create application entry in Fiori Administration application tile in order to track their usage. And we have seen some challenges in Fiori tracker tool which is not populating our existing Catalogs, Groups in respective Business Catalog and Group tiles.

        Please suggest if any thing we missed out.



        Ganesh Babu

        • I hope I got your question right: there is no need for the user to have access to the Fiori Administration tile to enable tracking for this user. Once the user has the role for Fiori Apps Usage Plugin the tracking will start.

          For other topics please send me an email ( and I will set up a meeting or we will assist you on Fiori Tracker Slack.