TL;DR: Explicit authorizations are your best bet for limiting the values in filters of SAP Fiori apps. You can identify which AuthObjects to set from the authorization proposals of the related OData Services, i.e. the OData Services are listed against the SAP Fiori app in the SAP Fiori apps library. Where authorizations are not applied, you can use public or role-specific views to preset correct filter values. Avoid deleting SAP standard configuration codes.
A few days ago one of my SAP S/4HANA customers came to me with a problem:
“We have configured our own values for various dropdown fields.
Now in our SAP Fiori apps both our own values and the original SAP values are showing.
We don't want to lose the standard SAP values in case we need them for troubleshooting or comparison.
How do we hide the standard SAP values so that our users only select our values?”
The customer’s primary concern was to avoid confusion for business users. They didn’t want maintenance techs learning to use the app to be presented with a lot of irrelevant values.
After a few discussions with some functional experts - and a little experimentation – it was clear this was a reasonably common request. Given that hundreds of SAP Fiori apps contain a filter bar, we thought it was worth sharing how we resolved it.
In brief, after evaluating the options it was clear that:
But the real trick is how to find which authorizations you need to set! You will learn how you can find this in the explanation below.
If you want to know more about creating public and role-specific views, refer to blog post SAP Fiori for SAP S/4HANA – New options for managing Views for filters tables and charts
Note: All screenshots in this blog post are from the author’s SAP S/4HANA 2022 trial system, however the approach described works much the same in previous SAP S/4HANA releases (with some minor differences e.g. in the look and feel of Adapt Filters). The customer in question was using SAP S/4HANA 2021.
The customer was using some of the SAP Fiori apps for enterprise asset management (EAM), such as:
These apps all use the Fiori elements list report floorplan which includes a smart filter bar and a table showing the results found.
The customer had configured their own values for the fields:
When they used the apps, for these fields the filters showed their custom values and the SAP standard values.
For example: In F2071 Find Maintenance Notification, the filter on Notification Type brings:
The customer was concerned – rightly – that this would be confusing for their business users. They only wanted their business users to see their custom values.
But how what was the best way to remove the unwanted SAP values?
After a few discussions, these were the options considered for hiding the default SAP values:
This is possible but risky.
While some of our functional consultants confirmed this was something they had seen done at some customers it’s not ideal. Whenever you delete standard SAP values you risk removing dependent configuration entries that your own custom values may depend on.
Plus, if you discover something is not working as you want, it’s very useful to have the standard SAP values to review.
Decision: Risky. Avoid this approach.
This is possible but high effort.
It requires a developer to do a detailed evaluation of the app, most likely create a copy of the app, and then adjust the copy using the Business Application Studio or VSCode.
Depending on how the app was written (freestyle vs. Fiori elements), and depending on the experience of the developer, this can be quite complex and time-consuming.
Creating a copy of the app is an additional TCO (total cost of ownership) burden as the support of the app is then the customer’s responsibility. Any improvements or corrections made to the original app must also be applied manually to the copy. Even where an adaptation project is possible, that’s another piece of code you and your customer must support. For example, if the business needs to add another custom value, they may need to call a developer back in to change the app.
Also, SAP Fiori developer skills are at a premium and this seemed a very expensive and effortful way of making what should be a relatively simple change.
Decision: Expensive. Effortful. Avoid this approach.
This sounded like a possible answer but needed some a little experimentation to confirm.
Like many sandbox and development systems, many of the business roles were authorized with AuthObject set to “*” i.e. all values. So, what would happen if users were only authorized to use the custom values and not the standard SAP values? Success!
This took care of most of the fields that the customer needed to restrict as most of them could be controlled through authorizations.
Decision: Relatively easy. Effective. Preferred approach.
To restrict filter values, you need to:
So perhaps the trickiest part of this approach is working out how to find the AuthObjects. AuthObjects are the lowest level of the security role. AuthObjects control which activities and objects users are allowed to perform.
Hint: This is the time to start getting your security administrator involved. They will have access to the right tools to find and adjust authorizations. They are also responsible for updating the related business roles with the authorizations you find.
There are several ways to find AuthObjects – some are easy than others:
Hint: What about using the SAP Fiori launchpad App Support? App Support captures failed authorizations, in this use case there are no failed authorizations because the user can see all values, i.e. all authorizations have been passed successfully.
Authorization proposals turned out to be the easiest way to find the AuthObjects with a simple 3 step process:
For example, for notification types, you can see the AuthObject is called I_QMEL which has the short text "PM/QM Notification Types". The Check Indicator value "Check" confirms that this authorization is checked by the OData Service.
IMPORTANT: When using transaction SU24, you will need to use a different value for the Type of Application parameter depending on whether your SAP Fiori app uses and ODatav2 or an ODatav4 service. Most older apps use ODatav2 - the matching parameter value is "SAP Gateway Business Suite Enablement - Service". Increasingly new apps use ODatav4 - the matching parameter value is "SAP Gateway OData V4 Service Group & Assignments".
So the second challenge is to know which business roles need to be changed.
Here the easiest tool to help find this was the Launchpad Content Manager (Client-specific). You can reach this from the Fiori launchpad if you have the Fiori Administrator role (by default called Z_FIORI_FOUNDATION_ADMIN) or by calling GUI transaction /UI2/FLPCM_CUST.
Hint: The Fiori Administrator role is generated by your technical team using task list SAP_FIORI_FOUNDATION_S4. It grants all the launchpad content and layout tools to people assigned this role.
By going to the Tiles/Target Mapping tab it is an easy matter to search for the app by its id. By default this shows the business catalogs that hold the app. You can even use the Show Usage in Roles feature to find the roles.
You can see in this example that both standard SAP business roles and custom business roles in which the app is assigned are listed.
Obviously, the customer only needed to change their custom business roles. You can even select a role and launch straight into the role maintenance transaction using the button Open in PFCG. You can even export the list of roles to a spreadsheet in case you need to discuss the change with the role owners first.
For example, for individual maintenance you adjust the AuthObjects in the Authorization Data maintenance area which is reached from the Authorization tab of transaction PFCG. In the example below, you can see the 3 values to be kept are maintained against the AuthObject I_QMEL. The other values are unchanged. The generate button is highlighted.
The resulting impact on the SAP Fiori app is that only the authorized filter values are available.
For most of the filter values the customer needed to control we could find authorization objects for the fields. However, some filter fields were not controlled by authorizations, such as Priority.
This was a different challenge as the same priority code could mean something different depending on the priority type that was relevant. In the example below you can see that priority 1 is very high for some most priority types; high for SL and SR; low for priority type SR; and so on.
Priority Type was obviously important in restricting which priorities were relevant. Time to check Adapt Filters! You can see the button immediately after the Go button.
Sure enough Priority Type was an optional available filter.
By selecting the Priority Type it is added as a filter, and you can use the up/down arrow heads to adjust the sequence of filters in the filter bar.
You can then select which priority types are relevant for the user.
This restricted the Priorities to only those relevant for selection.
To save those settings so they were defaulted for our maintenance technicians, you can simply create a role-specific or public view.
Decision: Easy. Effective. Reasonable alternative where fields are not covered by authorizations.
You’ll find much more on the community topic page for SAP Fiori for SAP S/4HANA
Other helpful links in the SAP Community:
Brought to you by the SAP S/4HANA Customer Care and RIG.
A few days ago one of my SAP S/4HANA customers came to me with a problem:
“We have configured our own values for various dropdown fields.
Now in our SAP Fiori apps both our own values and the original SAP values are showing.
We don't want to lose the standard SAP values in case we need them for troubleshooting or comparison.
How do we hide the standard SAP values so that our users only select our values?”
Example of what the customer wanted to achieve - keep the custom values, hide the filter values in the Notification Type filter of F2071 Find Maintenance Notifications
The customer’s primary concern was to avoid confusion for business users. They didn’t want maintenance techs learning to use the app to be presented with a lot of irrelevant values.
After a few discussions with some functional experts - and a little experimentation – it was clear this was a reasonably common request. Given that hundreds of SAP Fiori apps contain a filter bar, we thought it was worth sharing how we resolved it.
In brief, after evaluating the options it was clear that:
- Authorizations were the best approach to restrict filter values
- When authorizations are not available for a filter value, a public or role-specific view is an acceptable alternative
But the real trick is how to find which authorizations you need to set! You will learn how you can find this in the explanation below.
If you want to know more about creating public and role-specific views, refer to blog post SAP Fiori for SAP S/4HANA – New options for managing Views for filters tables and charts
Note: All screenshots in this blog post are from the author’s SAP S/4HANA 2022 trial system, however the approach described works much the same in previous SAP S/4HANA releases (with some minor differences e.g. in the look and feel of Adapt Filters). The customer in question was using SAP S/4HANA 2021.
The example use case
The customer was using some of the SAP Fiori apps for enterprise asset management (EAM), such as:
- F2071 Find Maintenance Notifications
- F2175 Find Maintenance Orders
- F2173 Find Maintenance Orders and Operations
These apps all use the Fiori elements list report floorplan which includes a smart filter bar and a table showing the results found.
The customer had configured their own values for the fields:
- Notification Type,
- Order Type,
- Maintenance Activity Type, and
- Priority
When they used the apps, for these fields the filters showed their custom values and the SAP standard values.
For example: In F2071 Find Maintenance Notification, the filter on Notification Type brings:
- SAP standard values M1, M2, M3
- Custom values MA, MF, MR
By default app F2071 Maintenance Notifications showed both SAP values and custom values in the Notification Type filter
The customer was concerned – rightly – that this would be confusing for their business users. They only wanted their business users to see their custom values.
But how what was the best way to remove the unwanted SAP values?
The aim of the customer - hide the default SAP values in the Notification Type filter
Options for restricting filter dropdown values
After a few discussions, these were the options considered for hiding the default SAP values:
- Delete the standard SAP values
- Do a complex extension to hide the values programmatically
- Restrict filter values with authorizations
- Create a public or role-specific view in the app
Option 1: Delete the standard SAP values
This is possible but risky.
While some of our functional consultants confirmed this was something they had seen done at some customers it’s not ideal. Whenever you delete standard SAP values you risk removing dependent configuration entries that your own custom values may depend on.
Plus, if you discover something is not working as you want, it’s very useful to have the standard SAP values to review.
Decision: Risky. Avoid this approach.
Option 2: Do a complex extension to hide the values programmatically
This is possible but high effort.
It requires a developer to do a detailed evaluation of the app, most likely create a copy of the app, and then adjust the copy using the Business Application Studio or VSCode.
Depending on how the app was written (freestyle vs. Fiori elements), and depending on the experience of the developer, this can be quite complex and time-consuming.
Creating a copy of the app is an additional TCO (total cost of ownership) burden as the support of the app is then the customer’s responsibility. Any improvements or corrections made to the original app must also be applied manually to the copy. Even where an adaptation project is possible, that’s another piece of code you and your customer must support. For example, if the business needs to add another custom value, they may need to call a developer back in to change the app.
Also, SAP Fiori developer skills are at a premium and this seemed a very expensive and effortful way of making what should be a relatively simple change.
Decision: Expensive. Effortful. Avoid this approach.
Option 3: Restrict filter values with authorizations
This sounded like a possible answer but needed some a little experimentation to confirm.
Like many sandbox and development systems, many of the business roles were authorized with AuthObject set to “*” i.e. all values. So, what would happen if users were only authorized to use the custom values and not the standard SAP values? Success!
This took care of most of the fields that the customer needed to restrict as most of them could be controlled through authorizations.
Decision: Relatively easy. Effective. Preferred approach.
How to restrict filter values with authorizations
To restrict filter values, you need to:
- Identify which AuthObjects to set
- Identify which Business Roles need to be changed
- Adjust the AuthObjects in the role and regenerate the authorization profile
Finding the AuthObjects of a SAP Fiori app
So perhaps the trickiest part of this approach is working out how to find the AuthObjects. AuthObjects are the lowest level of the security role. AuthObjects control which activities and objects users are allowed to perform.
Hint: This is the time to start getting your security administrator involved. They will have access to the right tools to find and adjust authorizations. They are also responsible for updating the related business roles with the authorizations you find.
There are several ways to find AuthObjects – some are easy than others:
- AuthObjects may be listed in the app documentation or a SAP Note for that app.
- Authorization trace (transaction STAUTHTRACE) you could run an authorization trace across the user. It might still be quite tricky to find which AuthObject relates to which field of the app.
- Authorization proposals as explained in Getting back to Standard Proposals with SU24 Authorisation Variants
Hint: What about using the SAP Fiori launchpad App Support? App Support captures failed authorizations, in this use case there are no failed authorizations because the user can see all values, i.e. all authorizations have been passed successfully.
Authorization proposals turned out to be the easiest way to find the AuthObjects with a simple 3 step process:
- Find the OData Service(s) of the SAP Fiori app. This was easily found in the SAP Fiori apps library
Example of finding the OData Service of the SAP Fiori app on the tab Implementation Information section Configuration in the SAP Fiori apps library
- Find the authorization proposals for the OData Service. This was easily found in transaction SU24. By searching on the for the gateway service and using the OData Service id, you can find all the AuthObjects evaluated by the app.
Example of selecting the gateway service and the OData Service in GUI transaction SU24
Example of the list of AuthObjects evaluated by the OData Service as shown in transaction SU24
- Find the AuthObject for the field. While some apps can apply several authorizations (this service applied 45) this was still a relatively simple process to scroll through the list and identify the correct AuthObject.
Example of finding the AuthObject for Notification Types by reading the short text of the listed AuthObjects in SU24
For example, for notification types, you can see the AuthObject is called I_QMEL which has the short text "PM/QM Notification Types". The Check Indicator value "Check" confirms that this authorization is checked by the OData Service.
IMPORTANT: When using transaction SU24, you will need to use a different value for the Type of Application parameter depending on whether your SAP Fiori app uses and ODatav2 or an ODatav4 service. Most older apps use ODatav2 - the matching parameter value is "SAP Gateway Business Suite Enablement - Service". Increasingly new apps use ODatav4 - the matching parameter value is "SAP Gateway OData V4 Service Group & Assignments".
Identifying which business roles need to be changed
So the second challenge is to know which business roles need to be changed.
Here the easiest tool to help find this was the Launchpad Content Manager (Client-specific). You can reach this from the Fiori launchpad if you have the Fiori Administrator role (by default called Z_FIORI_FOUNDATION_ADMIN) or by calling GUI transaction /UI2/FLPCM_CUST.
Hint: The Fiori Administrator role is generated by your technical team using task list SAP_FIORI_FOUNDATION_S4. It grants all the launchpad content and layout tools to people assigned this role.
The launchpad of the Fiori Administrator role highlighting the tile Launchpad Content Manager Client-Specific
By going to the Tiles/Target Mapping tab it is an easy matter to search for the app by its id. By default this shows the business catalogs that hold the app. You can even use the Show Usage in Roles feature to find the roles.
Example of Launchpad Content Manager Tiles and Target Mappings tab showing the resulting catalogs found when searching for app F2071 and highlighting the Show Usage in Roles button
You can see in this example that both standard SAP business roles and custom business roles in which the app is assigned are listed.
Example in Launchpad Content Manager showing the SAP and custom business roles to which app F2071 is assigned
Obviously, the customer only needed to change their custom business roles. You can even select a role and launch straight into the role maintenance transaction using the button Open in PFCG. You can even export the list of roles to a spreadsheet in case you need to discuss the change with the role owners first.
Example in Launchpad Content Manager highlighting the Export button and the Open in PFCG button in the Roles containing tile/target mapping pane
Process to adjust the Authorizations
- Edit the role’s authorization data to set explicit values for the relevant AuthObject. You can use tools such as GUI transaction PFCG which provides both individual role maintenance and Mass Maintenance of Authorization Values options.
- Once the AuthObjects have been changed, you then need to regenerate the role’s authorization profile to update the role and apply it to users.
For example, for individual maintenance you adjust the AuthObjects in the Authorization Data maintenance area which is reached from the Authorization tab of transaction PFCG. In the example below, you can see the 3 values to be kept are maintained against the AuthObject I_QMEL. The other values are unchanged. The generate button is highlighted.
Example of adjusting the authorizations for AuthObject I_QMEL in the Change Role Authorizations dialog
The resulting impact on the SAP Fiori app is that only the authorized filter values are available.
Now that authorizations have been adjusted the SAP Fiori app F2071 only displays the custom values for the Notification Type filter
Option 4: Create a public or role-specific view in the app
For most of the filter values the customer needed to control we could find authorization objects for the fields. However, some filter fields were not controlled by authorizations, such as Priority.
This was a different challenge as the same priority code could mean something different depending on the priority type that was relevant. In the example below you can see that priority 1 is very high for some most priority types; high for SL and SR; low for priority type SR; and so on.
Example of the default values for the Priority filter showing priorities for many different priority types
Priority Type was obviously important in restricting which priorities were relevant. Time to check Adapt Filters! You can see the button immediately after the Go button.
Example of the filter bar highlighting the standard Adapt Filters button in the filter area ofSAP Fiori app F2071 Find Maintenance Notifications
Sure enough Priority Type was an optional available filter.
Example of finding the Priority Type filter in the Adapt Filters dialog of SAP Fiori app F2071
By selecting the Priority Type it is added as a filter, and you can use the up/down arrow heads to adjust the sequence of filters in the filter bar.
Example showing Priority Type selected as an additional filter and the up/down arrowhead icons have been used to position the filter within the filter bar
You can then select which priority types are relevant for the user.
Example of restricting the available priority types using the Priority Type filter
This restricted the Priorities to only those relevant for selection.
Example showing the impact on the Priorities filter once Priority Types have been restricted
To save those settings so they were defaulted for our maintenance technicians, you can simply create a role-specific or public view.
Example showing the top of the filter bar where the user selects the custom public view for Plant Maintenance and Service Notifications
Decision: Easy. Effective. Reasonable alternative where fields are not covered by authorizations.
Becoming a SAP Fiori for SAP S/4HANA guru
You’ll find much more on the community topic page for SAP Fiori for SAP S/4HANA
Other helpful links in the SAP Community:
- Follow our tag SAP S/4HANA RIGfor more from the SAP S/4HANA Customer Care and RIG
- See all questions and answers about SAP Fiori for SAP S/4HANA
- Follow SAP Fiori for SAP S/4HANAfor more blogs and updates
- Ask a Question about SAP Fiori for SAP S/4HANA
Brought to you by the SAP S/4HANA Customer Care and RIG.
- SAP Managed Tags:
14 Comments
