10 Authorisation Challenges in SAP S/4HANA Projects

One of the first critical decisions when transitioning to SAP S/4HANA involves evaluating your current ECC authorisation concept. Key questions to consider include:

• Can the ECC authorisation concept be migrated directly to SAP S/4HANA?
• Can it serve as a solid foundation for designing new roles tailored to the S/4HANA environment?

In SAP ECC, authorisation administrators mostly worked behind the scenes. In SAP S/4HANA, with the Fiori Launchpad, authorisation roles directly affect the user interface and, therefore the user experience.

SAP S/4HANA 2020 introduced a new structure for the Fiori Launchpad using spaces and pages. These are designed to help users efficiently execute business processes and access data. To achieve this, business roles, authorisation roles, and spaces and pages must be carefully tailored to user needs. What may appear as simplification for end users often introduces technical and organisational complexity for administrators.

Fiori is the default user interface in SAP S/4HANA, with some applications accessible only via Fiori. While it offers a streamlined, intuitive experience for users, it introduces additional layers of complexity for administrators and project teams. The technical setup is more intricate, and maintenance efforts are higher. 

In large organisations, several stakeholders are involved in preparing the SAP Fiori Launchpad for users. Configuring authorisations for Fiori apps requires coordination across multiple teams:

• SAP Basis Administrators – responsible for Fiori Launchpad configuration 
• SAP Authorisation Administrators – assign the required authorisations
• Business Process Experts – determine access needs based on business requirements.
• Compliance Team – update segregation of duties (SoD) matrices for Fiori applications.

Clear coordination among these groups is essential for a smooth rollout. In smaller companies, a single authorisation administrator may handle all these tasks. In such cases, it’s important to communicate to management that the workload in S/4HANA is significantly higher than in ECC.

Another Fiori challenge is that the SAP_ALL profile is no longer sufficient. Previously, assigning SAP_ALL in sandbox or test systems allowed project team members to work without authorisation issues. In SAP S/4HANA, however, SAP_ALL only grants backend access; it does not include permissions to launch or navigate the Fiori Launchpad. Additional roles with Fiori-specific authorisations must be assigned, including a basic end-user role for launching the Fiori Launchpad.

Top-down navigation is a UX design pattern in which users start with a high-level overview and drill down into more detailed data, such as individual purchase orders or billing documents. This navigation only works if users have authorisation for every linked app in the navigation path.

Authorising users in Fiori involves multiple components, which means there can be many potential failure points.

While traditional tools like SU53 and STAUTHTRACE remain relevant, additional tools and transactions have been introduced for Fiori troubleshooting. The real challenge lies not only in using these tools but also in teaching users how to use tools like Fiori App Support. Moreover, as noted earlier, resolving Fiori issues often requires collaboration across teams, even when they’re mistakenly labelled as "authorisation issues."

SAP S/4HANA frequently introduces new authorisation objects – not to replace old ones, but to layer on top. A prime example is Business Partner authorisations. While new objects have been introduced, the traditional ECC objects for customer and vendor master data are still in use.

This means granting access to create or modify customers and vendors in S/4HANA requires maintaining nearly twice as many authorisation objects as in ECC.

Since SAP roles are closely tied to business processes and S/4HANA projects often involve broader business transformation, processes are likely to evolve throughout the project lifecycle.

Without proper planning, roles must be continuously updated to reflect changing requirements. Role design must be tightly linked to business process (re)design, with a clear sign-off milestone to allow sufficient time for role creation and testing.

Whether it's a new process step, a Fiori app replacing a transaction, or a custom development, changes must be reflected in authorisation roles.

SAP offers two licensing models: Product-Based Licensing and User-Based Licensing. Many organisations using the Private Cloud Edition choose the latter option, in which fees are tied to user types determined by assigned authorisations.

This makes accurate authorisation design critical. Over-assignment of permissions may lead to higher licensing costs, so it's essential to align roles with actual job functions.