One of the common questions I receive from customers and partners is “how can you deliver a display only version for a Manage App”? There are more than 500 of these apps delivered out-of-the-box with SAP S/4HANA, providing an easy way to filter and act on a vast number of SAP Business objects.
The motivation behind this question is usually a role design approach where display roles are built for each functional area. In this design approach, security teams attempt to provide users with a “display all” capability for their functional area to avoid future support requests for ad-hoc reporting requirements. Users will automatically receive the display role relating to their functional area as part of their system access. Confidentiality requirements may sometimes necessitate several levels of display access, but the idea remains the same: if the app is read only or can be restricted to read only then it is added to the display role.
I’ve always been a proponent of this role design approach. Building “display only” roles allow us to:
- Provide display only access easily to a broad user base
- Provide the ability to downgrade access organization-wide to display only (e.g. to support certain time periods for a business processes when maintenance is not allowed)
- Provide support and super user access to allow display access to production without requiring Firefighter or temporary elevation of privileges
- Provide auditors with easy access to see what is happening in an area
- Reduce duplication of application access (less security build restrictions, regression tests, etc) as several user populations receive the same display access
- Easily identify the correct security role to assign a user (i.e. if the access only exists in one role then the answer is easy)
- Reduce change requests on security team to provide Adhoc reporting and display access
Hint: Manage apps are typically marked in the SAP Fiori apps reference library as Application Type = Transactional and UI Technology Type = SAP Fiori elements. They typically use the SAP Fiori elements floorplan “List Report” or “Worklist”.
The SAP ECC Days with Classic UI transactions
In SAP ECC system transactional access had two main patterns.
Pattern 1: A transaction code was allocated for each Activity to an object (e.g. transactions FI01 through to FI03 provide Access to Create, Maintain, Display of Bank Master Data). As security administrators, most times we could deduce the access level based on the transaction code (01 Create, 02 Change, 03 Display, etc).
Pattern 2: The other pattern would be one transaction code to provide access to an object. Within the transaction, action buttons would allow for different activity levels (e.g. transaction FS00 to Maintain GL Accounts). Manage Apps in SAP Fiori operate a bit like this scenario – single entry point that with several buttons to control the actions.
In the “build a display role approach” for the examples above, transaction codes FI03 (Display Bank) and FS00 Edit G/L Account Centrally would be granted and all underlying authorisations restricted to display only. Transaction FI01 and FI02 would most likely be assigned to a Finance Master Data Role.
Creating display only roles with SAP Fiori “Manage” apps
In SAP Fiori, it’s not quite as simple. “Manage” apps is an example of how the User Experience (UX) paradigm can conflict with this (potentially outdated) security design approach:
- SAP Fiori Apps may be based on a consolidation of several UI classic applications together (e.g. FI01, FI02, FI03 Create/Maintain/Display Banks are now a single app Manage Banks)
- Action Buttons may be available regardless of the user’s authorisations
- Fiori Application authorisations checks are not evaluated until a user performs an action that triggers a call to the backend.
- From a security authorisation point of view, transaction SU24 data (where authorisation proposals for applications is maintained to simplify role build) most likely assumes maintenance level access. You will need to change several default proposals to streamline your security role build.
In relation to authorisation checks, this can be quite frustrating for the user to take the time to enter or maintain the data only to receive a message at the end advising them of lack of access. The ability to enter edit mode may cause unnecessary alarm and incidents amongst business users who are concerned access has not been appropriately restricted.
From a UX standpoint, Fiori Launchpad has been built with usability in mind and application tiles are not the only access pathway to meet the original intent of the ECC “display only” use case, i.e. to provide the user with display level access to the master or transaction data.
Example: SAP Fiori App F1366A Manage Bank Accounts in Display Mode
Manage Banks Accounts (BankAccount-manageMasterData) supersedes classic UI transactions for Create Bank (FI01), Maintain Bank (FI02), Display Bank (FI03). The SAP Fiori app provides a 1-stop shop for all maintenance activities of the Cash Manager. The app has been designed to fit with the needs and tasks of the Cash Manager. If you were to use the SAP Business Roles as delivered, only the Cash Manager is assigned this app.
But what happens if you give this app to other users – who are not Cash Managers – and who only need to display bank information? Although the user is restricted to display only authorization, they can still view and press the create button and Fiori opens a new record to complete.
The user may invest time to enter the required information then presses save.
This can be considered bad user experience and will cause incidents as users complain of lack of access or concern, they have inappropriate access assigned. From a strict SAP Fiori role-based perspective, this should not happen, because the app is not intended for use by other users needing display only access and should not be assigned to anyone who is not a Cash Manager.
Better ways to provide display access in SAP Fiori
The easiest way to provide users access to display access is via Enterprise Search. This will let users search for the object using keywords and wildcards. For example, search for banks by name or code.
The search results bring them summary details of the object. For example, for banks you can see details such as bank name, bank country, bank key, SWIFT code, and several other fields.
If the user is only permitted to see the summary details the main id – in the example the bank name – is a flat text.
If the user is permitted to see more complete details, they can also be assigned the related Object Page (technically this is done by assigning the associated target mapping for the displayFactSheet semantic action). This converts the main id to a hyperlink to the object page. For example, clicking on the bank name takes you into the bank object page.
This approach allows users to get to the data faster and avoids assigning the original app.
Users must be authorised to the user the search and have the target mappings to open the App to view more details. If the user has the required target mapping, they can click on the hyperlink and navigate directly to the underlying Fiori App to view the search results.
This solution deviates from the ECC security approach but may meet the user’s true requirement. User who are not responsible for managing master data are less likely to need a master data list of all records. In most cases, they may be attempting to find a specific record based on known information. Enterprise Search is the better fit. Taking this approach finds the right balance between UX and security.
Technically: Object Page (action=displayFactSheet) apps can also be assigned to user as a tile on their launchpad and allow direct entry. Or the user can bookmark their favourite bank to their entry page using the Save as tile icon.
Again, this would be a better UX and security approach.
Even so, you may still have a use case to provide the Manage App in Display only mode
Ask yourself if the access is to meet a business requirement or a security design requirement? If it’s a security design requirement (i.e. all “display” in a display role) then you may want to reconsider the role design approach for display access.
In most cases, Enterprise Search or an alternative Fiori Application will provide users with their requirements. It won’t, however, support the traditional security role design approach of putting all display level access into a role.
Use the in-app extension ADAPT UI to provide a Display only App Variant
The final scenario is where there is a use case to provide the app as read only. The common scenarios here are for Support Users or System Auditors.
ADAPT UI in SAP Fiori allows the Key User to create an App Variant of the Manage App. Who is this key user? Whoever you designate to create the app variant. For example, the key user could be a Fiori configuration expert, subject matter expert, Functional expert, Security, or dedicated UX expert, or even a central process governance team.
This Key User must be authorised to execute the ADAPT UI option in your development environment, for example by being assigned the security role SAP_UI_FLEX_KEY_USER.
When you enter the app In UI Adaptation mode, you can remove the action buttons, and save an app variant into a transport request.
Buttons can be removed or relabeled. For example, Initiate Review Process, Create Document, Create Bank action buttons have been removed. Import and Export Bank Accounts has been renamed to Export Bank Accounts.
Hint 1: If renaming, you then need to check if the navigation target requires another App Variant to also limit it to display.
Hint 2: You may also need to navigate into a record to check for additional action buttons as shown below (click on the bank results to get to the details screen where you have additional action buttons like copy, send closing request to bank, manage attachments)
Buttons such as Copy, Send Closing Request to Bank are removed and Manage Attachment is changed to View Attachments.
Once all the adjustments have been made the App Variant is defined.
On Save, an app variant Configuration Id is generated and provided.
To assign the app variant to your display only users, the app variant id must be added to a new Fiori Application definition in a technical catalog, and then to a Fiori Catalog and security role. To make the target mapping unique to the app variant, make sure you assign different semantic action to the original app. You should assign it to the same Semantic Object so you can find it easily, and so that it can be used in existing dynamic links such as search results, Related Apps buttons, Smart Link dialogs, and jump-to options in analytics.
In the end state solution, the user can access the Display version of the app. In App Finder, Display Bank Account App appears.
The user clicks the App and the App will open as Display Bank. It is a variant of Manage Bank without action buttons related to maintenance.
ADAPT UI will provide users with the App. The main shortcoming is app-to-app navigation. Users will not be able to navigate from one app back to the original “manage” app as they will not have the target mapping assigned. Therefore, it is so important to use the same Semantic Object to maximize availability in dynamic links.
