One of the first challenges the security administration team faces when embarking on their SAP S/4HANA implementation is how to provide the project team members with access to SAP Fiori Launchpad.  

A “chicken and egg” situation arises when project members do not know what SAP Fiori access they will require until they have validated the SAP Fiori apps and assessed the fit to standard. And to do this, they need access to the applications. 

The failure to address this access requirement early will impact SAP Fiori user experience adoption.  Since SAP Fiori is the way business users consume the new business value of SAP S/4HANA, this can also significantly reduce the business value derived from the SAP S/4HANA solution.  

When project team members do not have Fiori Launchpad access, they tend to resort to using SAP GUI as part of their fit-to-standard workshops.  This means the business users do not experience Fiori Launchpad nor assess the current best practice for SAP S/4HANA or the standard content for gaps.   That is, they are seeing older “just like SAP Business Suite” GUI transaction codes and ABAP Web Dynpro applications instead of SAP Fiori apps. This may also lead to an increase in custom developments and integration as the (old) standard does not meet business requirements. 

Project team members may also make false assumptions that they can later simply swap SAP Fiori apps for SAP GUI transactions, without further fit-gap or analysis.  This can lead to confusion, disappointment and missed opportunities for the business users and stakeholders. 

Further they can miss many of the out-of-the-box SAP Fiori launchpad features that benefit all users and are shared across all SAP Fiori apps, such as: 

• Search to quickly identify business objects from reference ids 
• Flexible follow my train of thought app to app navigation  
• Dynamic filtering and tailoring of charts, tables, and cards  
• Personalization to improve productivity 

• Key user adaptation and extension of apps without developer tooling 

What makes this even more challenging: Security Administrators cannot easily gather requirements as they would in SAP Business Suite by asking for an ‘SU53’ authorization failure list.   

Tip: For those of you that are new to SAP security authorizations – SU53 is the transaction code users would execute in SAPGUI to check last failed authorisation checks. 

This blog provides an overview and suggested approach to providing the project team with access to Fiori Launchpad in non-production environments (e.g. Sandpit, Development and Test). The aim is to provide you with choices to help set your project up for a successful implementation. 

Why Project User access requirements are different in SAP S/4HANA 

SAP Business Role templates are designed based on the day in the life of a typical end user for the core process. Project users are not end users. Their day in the life is problem definitions, solution proposals, workshops, meetings… and sometimes they find the time to access the system to configure, prototype, validate and test. 

This means project users are impersonating multiple end users’ “day in the lives” as they take an end to end business process view of the solution they are delivering. 

Why is Project Access a challenge now? 

Project user access has always been a challenge to grant the right level of access (see further below). However, in pre-SAP S/4HANA days (i.e. SAP R/3 and SAP ECC), project teams would make use of the SAPGUI command prompts and design their favourites to navigate the system. 

In SAP Fiori, access is stricter.  For the business and for your Production environment this is a good thing.  However, for the project team it means favourites cannot be created without a tile already available. The closest functionality to the command prompt is the Enterprise Search and that also requires authorization access. 

Key Differences in Project System access compared to Production System access 

Project system access is significantly different to Production system access. Typically, in a production environment an explicit security model is taken to provide access which usually results in least privileges, i.e. users are only granted the access that they require for their job. The access granted usually also considers the regulatory process compliance requirements, data access controls, and segregation of duties. And these design rules apply to support team users as well. 

Project systems, on the other access generally take a most cost-effective approach to provide access by leveraging an implicit security model: users are granted anything/everything except what you explicitly don’t want them to have. 

The implicit security model aims to provide the project users with more than enough to complete their jobs. The cost-effectiveness goals are:  

• reduce project idleness (i.e. avoid project delay as users cannot do their job)  
• reduce administrative support costs 
• avoid overwhelming the security team with too many support requests (recognizing in a project environment, security is also providing a support function). 

There are 3 general guiding principles to determine the appropriateness of access using an implicit security model for project system access: 

1 – Unacceptable Risk to Project Environment Integrity and Availability: unacceptable risk of financial cost or project impacts if users perform systems functions that result in a system restore or unplanned downtime. For example, Switch Framework (transaction code SWF5) is reserved for the System Administrator only as mistakes may result in irreversible updates to the database requiring a system restore. There is a financial impact to the project to lose time on system restores.

2 – Unacceptable Risk to the Production Environment Integrity and Availability: unauthorized or untested changes are migrated to production resulting in an integrity or performance issue of Production. This will result in outages to the business and impede critical business operations. For example, restricting which users can create, release, and import transports throughout the landscape

3 – Obligation to protect confidential data: prevent unauthorized users from having access to confidential/sensitive unscrambled production data. For example, data migration staging clients will contain productive data and needs to be restricted to users with “need to know” access (i.e. explicit security model). 

When applying the user experience lens to the mix, a fourth guiding principle is added: 

4 – Adverse Impacts to System Performance – will the amount of access make it impossible to use. For example, the user is assigned so much access the system is subject to time outs. To the business user, having this access would be as useful as having none. Unlike the above 3 principles, this decision may sit with the business user who is being affected. 

These questions are helpful to understand the risk of the access your project users are requesting and provide justification as to why access is denied. In some cases, the project team only want the access to perform a setup step which could be processed on their behalf by another team.  

When access is restricted, operational procedures and guidance must be provided to the project team to let them know who can help them instead. Project users don’t complain because they don’t have access. They get frustrated because they can’t do their job. Give them a solution, even if the system access is not it. 

As a side note: most customers would treat Pre-Production environment as part of Production as there is a higher chance of sensitive production data that has not been de-identified/scrambled. Therefore, customers would typically grant users the same access in pre-production that they have in production. 

Understanding the Landscape and Project Environment 

The next part of determining the design approach for project access is an understanding of the overall system architecture, environment and client strategies, and the solution test strategy.  The environment strategy should provide guidance on the client usage, which may assist in assessing the guiding questions of the implicit security model. 

The system landscape may identify a need for a different project user access approach between the environments – for example the access granted in Sandpit could vary to what is required in Master Configuration Development Client, and System Test Clients. 

Finally, you need to be aware of the company’s policies and general guidelines for management of access. There may be suitable technical solutions (e.g. generic test users) that are ideal for providing access but are non-compliant with IT Security Frameworks.  

The Use of SAP_ALL 

Historically, project systems access in non-production systems has often been neglected.  Projects start up without an approach to managing non-production access. Typically the SAP_ALL profile is assigned as a stopgap solution that becomes near-impossible to remove mid-project out of fear it will impede project delivery. Generally, it’s easier long-term to increase access rights then to revoke them later.  

In the context of Fiori Access, it’s going to come up at some point so might as well address this topic before SAP Fiori Authorisations is captured: No! No! Noooooooooo! No! Project users should not have SAP_ALL. It does not meet the Implicit Security model and it won’t work in Fiori Launchpad. 

SAP_ALL in Fiori Launchpad will only provide project users with Enterprise Search access and the default OData services to access the launchpad. The user will have no access to any SAP Fiori apps,  no tiles or links will show on their launchpad, and no catalogs of will show in the App Finder. 

In SAP Fiori, SAP_ALL is not SAP ALL! 

And now that leads into, what access should the project team have in non-production Systems? 

SAP Fiori Access for Project Users 

Circling back to the beginning of this blog – SAP Fiori Launchpad access needs to avoid the chicken-and-egg scenario.  

In project systems the following options (or combinations) are available: 

1. SAP S/4HANA Standard Business Roles and Test Users 
2. SAP Standard Business Catalogs 
3. SAP Standard Technical Catalogs 
4. Custom Catalogs 

Each option has its merits and drawbacks. The right-fit will (again) depend on the landscape and use case. 

1 – S/4HANA Standard Business Roles with Test Users 

This approach is based on best practice recommendations and leverages the task list activation to get your system up and running ready for workshops. As part of the task list (transaction STC01 for SAP_FIORI_CONTENT_ACTIVATION) activation, you have the option to: 

• Activate SAP Fiori apps on mass 
• Copy SAP Business Role templates to custom names and generate the authorizations 
• Create a test user per business role – great functionality to set up demo users for workshops in Sandpit 

For example, you can choose to run the Task List only for the relevant business role and user steps and specify the SAP Business Role Templates that are in scope. There is an option to “Generate new Business Roles with Prefix: which will remove the SAP at the beginning of the role and replace the prefix instead (e.g. SAP_BR becomes AUC_BR). If “Create users with generated Business Roles (SU01)” is selected, then a user master per custom business role will be create and the role will be assigned. 

Once you have created the role and test users, you may choose to mass assign the default role to the test users for SAP Fiori launchpad (FLP) access and then reset the passwords. 

For more information on these tasks lists, refer to blog: 

Refer to Blog SAP Fiori for SAP S/4HANA – New Rapid Content Activation on SAP S/4HANA 1909, 1809 & 1709 – Part 1 – Overview – for information on the content 

https://blogs.sap.com/2019/03/16/fiori-for-s4hana-new-rapid-content-activation-on-s4hana-1809-1709-part-1-overview/ 

Unlike the other approaches, this one will provide the team with business groups (i.e. Home Page will contain applications and links). Therefore, if you take this approach it is recommended you use generic demo users instead of assigning all roles to the project users’ accounts.  Assigning multiple SAP business role template to project user accounts  will result in a very cluttered home page and performance issues in rendering thousands of tiles.  

If you decide to take this approach, you may choose to make an exception to typical user master setup and have the test users as a Service user (password will not expire). Set all users to have the same password and communicate this to the project. Note: you will need to consider any security policies for use of generic accounts and publishing passwords. 

2 – SAP Standard Business Catalogs 

For this option, you would build custom authorization roles in transaction PFCG that provide access to the SAP standard business catalogs that are relevant for your project. You can extract these catalogs from Fiori Apps Library or use the ALV export to Excel from Fiori launchpad content manager (GUI transaction codes /UI2/FLPCM_CONF and /UI2/FLPCM_CUST) 

In this example, a single role has been built with approximately 120 Fiori SAP Business Catalogs includes in the role. The “Include Application” (in edit mode in transaction PFCG select role and go to the menu> right click on catalog > choose details > you will see check box is not selected) was selected as mass creation program was used. However, authorization data has not been maintained. A separate authorization role will be built in transaction PFCG to provide the authorizations. 

Once the role was assigned to the test user, it took about 45 second to refresh the Fiori Home Page and then navigate and load the App Finder. 

The first time, some caching is occuring which will take some time. This time does effect user expierence and may be part of the factors as to the overall approach that you take. You may choose to build multiple authorization roles to group the catalogs together and decide per user if they should receive all roles or some. Again, there will be a trade-off with administratrive support. 

Approach to building the “right-fit” project access 

You can take the approach of using /UI2/FLPCM_CONF as it contains all catalogs that are currently in the system. However, you will need clean up the list a bit in Microsoft Excel to reduce unnecessary catalogs.  This is critical for good system performance and to avoid long load times for the user. For example, you may want to: 

• Remove catalogs for any key modules/functions that are not relevant and will never be used by your project (e.g. if plant maintenance is not part of your project, then don’t include the access) 
• Remove country specific catalogs (filter and search ISO country codes). For example, in S/4HANA 1909 FSP1 there are 52 country-specific catalogs for SAP_FIN_BC_GL_REPORTING_* catalogs
• Add any known custom Catalogs for customer specific items (this may not be a day one but part of your approach to grant newly built access) 

The aim is to provide the catalogs the project team will use without continually asking for more whilst balancing this against their SAP Fiori launchpad user experience.  More catalogs will take some time to load. 

How many Catalogs in a Role and which ones? 

Depending on the specific requirement, you may choose to build a role per process area or an all-encompassing role.  This will come down mostly to which system/client is the access intended for. 

From my project experiences, I’ve built single role with 700+ catalogs work in Fiori Launchpad (reduced the total available catalogs by 50% based the above strategy of what to remove). When SAP Business Client (thick client) was used, we observed minimal performance impact. However, if you do choose this option, do not include Fiori Groups. Keep the Home page blank to avoid a high level of OData calls to the backend where there are dynamic tiles. The App Finder can manage the call to load the text information of the Tiles and the use can then personalise the home page and add the key Applications to it. 

If you choose to build roles with catalogs per process area you will need to think about what access the project user should receive. It is easy to assume a procurement functional expert only requires procurement to pay. However, they won’t appreciate being unable to complete end to end testing if they lack Finance access or another integration point. The project user will end up raising a request with security team for additional access and end up with the equivalent access that a single all-encompassing role would grant. 

The fall back, is to encourage a set of dedicated generic users that the project team use for prototyping, demonstrating, and systems test. Again, the common theme: knowing the landscape and environment your project operates in will determine if possible. Some customers will not allow the sharing of generic test users. 

 3 – SAP Standard Technical Catalogs 

The SAP_TC_* catalogs are added to one of more authorisation roles in transaction PFCG. Users would not any Fiori Groups to improve performance. 

For example, the authorisation role has a technical catalog SAP_TC_FIN_ACC_COMMON (SAP: Financials – Accounting) and SAP_TC_CA_CONFIG_COMMON (Configuration Apps). The catalogs have been added without including applications to avoid importing the executables (transactions, Webdynpros, OData, etc). Users would receive an additional back-end role with authorizations to execute the application. 

This is one of the quickest ways to provide project users SAP Fiori launchpad access (with less need of mass maintenance tools). However, from a usability point of view, the App Finder will become a wall of Apps (see below). 

4 – Custom Catalogs 

In this scenario, custom catalogs are built and provided to the project user. These are assigned to the project users via their authorisation roles no different options 2 and 3. 

Custom Catalogs will be required for project access when: 

• Custom SAP Fiori apps or SAPUI5 apps are built, and access is needed.  Naturally SAP standard will not provide access to apps you have custom–built. These catalogs will need to be updated each time an app is deployed 
• Custom catalogs to provide shell target mappings for FLP content based on launchpad design and configuration steps 
• Provide access to GUI transaction codes, ABAP WebDynpro applications, or Web Client UIs that are not already in a SAP standard catalog 
• Provide access to URLs to be provided as tiles or links, as URLs are always added via custom configuration. For example, links to cloud SaaS apps 

The other reason for use of custom catalogs in project access is to start refining applications in scope. SAP Standard Catalogs can be copied into the customer namespace. Unnecessary applications can the be removed to reduce the noise. This scenario would typically apply outside of Sandpit. In Sandpit project users may want access to a specific SAP Fiori app that is not currently in scope to assess whether it should be added to the scope. 

Which Option When 

Below is a summary of when you may choose to use a specific option to provide project access: 

Sandpit Environment versus Sandpit Client 

SAP Fiori app activations include client–independent aspects, such as ICF nodes, and generally requires you to include all changes in a transport or make a local object. Security best practices recommends only the required ICF nodes are activated to reduce cybersecurity surface attack areas (i.e. less opportunities for unauthorised access to your system). 

If you have a dedicated SAP system for Sandpit, then you may have a lot more flexibility with your technical change and release team or environment managers. Usually, Sandpit Environments provide users with almost-SAP_ALL level access for prototyping purposes. In some customers, the system is refreshed regularly (users are warned to export their changes before lost forever) and if you break the system, you will wait for the next refresh (and possibly buy your colleagues a coffee with a very apologetic look on your face!). 

What this means: Sandpit Environment provides greater flexibility to mass activate all and sundry without any consideration to the overall landscape – all items can be activated as local objects. 

If you, however, have been provided with a Sandpit Client and its part of your development system (typically is the case), then you need to consider the impact of mass activating applications. Alternatively, the project may need to include a reconciliation step to clean-up or exclude some functions from being migrated through to production. 

In short, before you are let loose with Sandpit – check with your environment owner what the rules of engagement are and understand the impact to the overall technical integrity of your build (i.e. mass activate as a local object in a Sandpit client makes it difficult to transport later).

Summary 

Project Access is an additional aspect to setting up users in SAP Fiori launchpad. Take the time at the beginning to think through your strategy and approach to managing access and decide what’s best for your project.  

Doing this at the beginning will save the escalations and complaints for lack of access. More importantly, we have a greater success for SAP Fiori launchpad adoption when everyone is using it from Day 1 – Project team included! 

Becoming a SAP Fiori for SAP S/4HANA guru 

In the comments please let us know your thoughts on setting up access for Project Users. 

What strategies or practices you have found that work at your site? 

What has been the response of your users? 

You’ll find much more on our SAP Fiori for SAP S/4HANA wiki 

Sponsored by the S/4HANA RIG