SAP Fiori for SAP S/4HANA –How to restrict filter values in SAP Fiori apps
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:
- 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
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
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?
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
- 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.
- 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.
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.
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.
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.
The resulting impact on the SAP Fiori app is that only the authorized filter values are available.
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.
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.
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.
thanks for this great explanatory article (again 🙂 ). Valuable to prevent unnecessary developments.
Can we apply the same authorization based approach on S/4HANA Cloud as well, where these maintenance applications were also released ?
I am wondering that if we can use Maintain Restrictions functionality copying standard Business Roles or we have to utilize Views all the time for that in the Cloud ?
Thank You in advance, Attila
It is a little more restrictive in the public cloud edition and I don't personally get the chance to do much in there... however I agree that the Maintain Restrictions UI which is part of Maintain Business Roles (New) looks a very similar concept! So if you are working in public cloud edition I would definitely recommend trying it out and letting us know!
Query: how to check the similar Authorization objects bring referred in webdynpro app. As most of the plant maintenance apps are still in webdynpro apps when navigating from fiori apps to their individual change or create transactions . How can we restrict the drop down values in those webdynpro apps. Will su24 work there as well?
You can use ST01 or STAUTHTRACE transaction on onPremise systems to track which authorization checks were executed on the application server when running legacy apps.
See this blog, how to trace authorization checks. You can get insight and even navigate to the ABAP source code where the check was done. Here is a blog for that.
However it is not really easy to spot out such generally. It depends on the application at which point the authorization check should be activated to trace it, so that You have not too much trace records. There are application level authorization checks, like You are authorized to run the application, and also which restrict the data selection for the drop-downs and value helps.
WD and FPM applications can use SE11 search helps attached to the Data Element like in GUI (Right click on the field to get technical details) or manual implementation dialogs or OVS. It is also possible that the values come from foreign key relationships of the table/structure being used behind the field or value list comes from domain fixed values / value tables under the data element. It always depends on the specific field you investigate. In many cases there are no authorization checks at all, like all the above except the value helps attached to the data element which has search help exits in place, or /custom dialogs which might also do authorization checks.
In case of value helps You can activate the trace right before triggering the value helps. It is a good starting point for less trace records and success. First I suggest call the technical help in WD to see how the values are fetched with the above explained methods. You can even navigate to the WD View/Context to see more details when needed.
Hope this helps !
We recently have a similar requirement. Referring to your Option 4: Create a public or role-specific view in the app-->Though we defaulted priority types via Variant, end users are still allowed change this. It works if we want to default Filters, but does it work if we want to restrict Priority Type? Or Am i missing something here. Please clarify.
Hi Pradeep yes correct, the users can still override your filter settings - it's a default only.
You could possibly look to a developer adaptation project or restrict it in the underlying CDS View ... but in many cases I would think it would be an overkill to do that.
You can read more on the public view approach in this blog post:
SAP Fiori for SAP S/4HANA – Yes Key Users can create default app settings for filters, tables, and charts
Thanks for your reply. I was able to achieve it by creating new authorization object with Required fields and creating Access control for Standard cds.
That's a nice answer... any chance you could do a blog post on the approach?
I have submitted blog for approval. Will add link here once its approved..
Amazing blog, thanks for sharing.
I had a question, I have a similar requirement for a standard app with standard Odata service, where I need to restrict the values at the FIROI end for a field, but the values of that field had to be populate from a Z table, which can have new entries every month. How will I be able to achieve this?
On the contrary, if I need to follow the option 2 mentioned in your blog to achieve this programatically, is there any refrence blog you can suggest which is as elaborative as the current one?
Thanks in advance!