Fiori Authorisations in S/4HANA: Concept, Catalogues & Troubleshooting

With the move to S/4HANA and SAP Fiori, the authorisation model changes fundamentally. In addition to classic backend authorisations, new layers are added: Fiori catalogues, OData service authorisations and Launchpad configurations. Many authorisation teams face the challenge of understanding and correctly implementing these new concepts.

The Three-Layer Architecture

Fiori authorisations are based on three layers, all of which must be correctly configured:

• Frontend layer: Fiori catalogues and groups control which tiles a user sees in the Launchpad
• OData layer: Authorisation objects S_SERVICE (IWSG, IWSV) control access to the OData services that deliver the data
• Backend layer: Classic SAP authorisations (transactions, authorisation objects) control actual data processing

A user can only use a tile successfully if all three layers contain the required authorisations. If a layer is missing, the user either does not see the tile or receives error messages when calling it.

Managing Fiori Catalogues and Groups

Catalogues bundle related Fiori apps. Groups organise the display in the Launchpad. SAP delivers predefined catalogues and groups with the business role content. Best practice: create custom (Z_) catalogues and groups based on SAP standard catalogues but adapted to your requirements. This keeps you compatible during updates.

Administration is done via transaction /UI2/FLPD_CUST (customising) or /UI2/FLPD_CONF (configuration). Assign catalogues and groups via roles – not directly to users.

Configuring OData Service Authorisations

Every Fiori app uses one or more OData services for data communication. The authorisation objects S_SERVICE with types IWSG (service group) and IWSV (service) control access. Since S/4HANA 2020, the authorisation objects S_START (for Launchpad apps) and S_RFCACL are also relevant.

Identify the required OData services per app via the Fiori Apps Library (fioriappslibrary.hana.ondemand.com) or via the technical catalogue assignments in the system.

Troubleshooting: Common Errors and Solutions

The most common Fiori authorisation problems:

• Tile not visible: Check the catalogue assignment in the role and cache invalidation
• HTTP 403 on app start: OData service authorisation is missing. Check S_SERVICE in the role
• Data not visible: Backend authorisations (e.g. company code, plant) are missing or incorrectly restricted
• Tile visible but counter shows 0: The app can call the OData service but backend authorisations filter out all data

Debugging tools: Transaction /n/UI2/SEMOBJ for semantic objects, SU53 for failed authorisation checks, and the Fiori Launchpad diagnosis app (/UI2/FLP_DIAGNOSIS) for systematic error analysis.

Migration from SAP GUI to Fiori

When migrating from GUI transactions to Fiori apps, existing roles need to be extended. Backend authorisations remain identical in most cases – only the Fiori-specific authorisations are added. Use SAP's mapping tables that assign GUI transactions to the corresponding Fiori apps as a planning basis.

Practical Best Practices

The following recommendations have proved effective in projects: start with SAP-delivered business roles as a reference. Create custom catalogues and groups with a Z_ prefix. Test every Fiori app with a test user who only has the intended role. Document the mapping of Fiori apps to catalogues, services and backend authorisations. Train your authorisation team in the new concepts – Fiori authorisations require a different understanding than classic GUI authorisation design.

Conclusion

Fiori authorisations are more complex than the classic GUI model but perfectly manageable with the right understanding of the three-layer architecture. Invest in knowledge building and clean documentation – this saves considerable troubleshooting effort later.

Get in touch →

Related Articles

Need support with this topic?

We help you with implementation – from analysis to go-live.

Get in touch

← All articles