SU24 Tips & Tricks – Fields you should not maintain
In contrast to application-specific fields, there are numerous object fields that you should not maintain in SU24 because they are specific to individual roles, or adding them to SU24 would significantly increase your maintenance effort.
Table of Contents
USORG Organizational fields
The best example is fields that you have maintained on the organizational field level in PFCG. These fields are reflected in table USORG, and you cannot maintain them in SU24. The SU24 application does not even offer the option to maintain them. SU24 will also respect custom fields which you have promoted to organizational fields. Some notable examples are:
- BUKRS ā Company code
- WERKS ā Plant
- EKORG ā Purchasing Organization
The reason why they do not belong in SU24 is that you should maintain them directly in your roles. Objects using these fields will have at least one additional field (mostly ACTVT) which should have a fixed value set in SU24. Ultimately, you should base the decision on what fields belong in SU24 on your organizational structure (see transaction EC01) and your requirements for grouping of organizational sets, if you are using the Xiting Authorizations Management Suite (XAMS)Ā (see transaction /n/XITING/ORG).
A word of caution on promoting a field to an organizational level status: You must consider that all authorizations of the promoted field within the same role will have the same field values regardless of the object. Many fields are however not appropriate for organizational levels if they do not have a real organizational flavor. Do not use this strategy if you cannot uniquely map the field to an organizational unit (at the role level) which you want to build roles for and have checked that the same field name will not negatively impact other authorization objects which you do not want to restrict in the same manner.
Unused Objects and Full Access Fields
SAP has several thousand applications, authorization objects, authorization field combinations, and therefore, SU24 proposals and maintaining them all for your roles in SU24 is a tedious and unnecessary process.
The art of maintaining SU24 is to focus on the fields you need for your roles. Any fields you do not care about can remain openĀ so that you do not have to maintain them in SU24. Then in the role, you can simply cascade a full access value (*) to all open fields:
A prerequisite to the above strategy is a well-maintained SU24 with complete proposals for the objects you use in your roles. Otherwise, you might unintentionally transfer full authorization to a field you want to control for the associated authorization instance in the role!
Tip:Ā You can use theĀ Xiting Role Profiler Watchdogs to check roles for functional capability in case you missed something! You can also use it to check roles based on their names to ensure they have nothing more and nothing less than you intended for them.
Special transactions that can have different values within the same role
Some transactions can have multiple activity fields. Examples include PFCG, which is hard to control, and SU01, which has a display-only cousin SU01D.
The profile generator (PFCG) has only one transaction and it covers all activity types (display, change or delete) for roles and even user assignments. There is no alternative, like in the case of SU01. As a result, you should leave the important ACTVT fields open in SU24 and restrict the activity field directly in the role. Note that, by default, SAP proposes all values, so an open field in SU24 is better than a changed authorization due to a preset SU24 proposal. Such a strategy reduces the chance of errors when making future role updates and it also reduces the maintenance effort over time.
The Maintain User transaction (SU01) exists in multiple variants, including a display-only version SU01D. As a result, a user may use more than one method to display user master records, depending on the user’s requirements. In case of SU01, you can also leave the ACTVT fields open in SU24, but a better option is to authorize the user for transaction SU01D and SUIM with display access as they should be doing their display work there. I will cover additional tricks on how to deal with users who are used to using SU01 in “display mode” in a future blog post.
Conclusion
Using the tips from these first two blogs, you should be able to build a role to 99% field completion. Achievable by making the initial investment in maintaining SU24 correctly for fields which you should maintain and fields which you should not. Stay tuned for additional articles with more SU24 Tips & Tricks.