{"id":2016,"date":"2017-03-27T06:00:25","date_gmt":"2017-03-27T10:00:25","guid":{"rendered":"https:\/\/www.xiting.us\/?p=2016"},"modified":"2025-10-01T10:49:03","modified_gmt":"2025-10-01T08:49:03","slug":"su24-tips-tricks-field-maintenance","status":"publish","type":"post","link":"https:\/\/xiting.com\/en\/su24-tips-tricks-field-maintenance\/","title":{"rendered":"SU24 Tips & Tricks – Fields you should maintain"},"content":{"rendered":"\t\t
\n\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

When you create a role in the profile generator (PFCG) and add objects via the role menu, the SAP system automatically merges authorization proposals from transaction SU24 into the role. How accurate and complete these proposals\u00a0are, depends on how well you have maintained them in SU24. Our experience has demonstrated that a well-maintained proposals database results in more robust roles for end-users and less role maintenance effort in the long-run.<\/p>

When you edit a role in PFCG, you may have seen a button that SAP labeled “Expert Mode.” You can find more information about “Expert Mode” in the\u00a0SAP Note 113290<\/a>. However, it is important to understand that SAP calls it \u201cExpert Mode\u201d for a reason: when faced with requirements to change authorizations with a role in mind, the expert methodology of doing this is to determine which transaction require change and maintain SU24 for that transaction accordingly. But the role will not know about this and other roles which can also benefit from the authorization proposal due to having the same transaction in the role will not either.<\/p>

The question of when and how to maintain SU24 is often complex, and some security administrators even consider it an art form to create elegant authorization concepts with a complete where-used-list that requires minimal role maintenance work via PFCG.<\/p>

If you carefully maintain SU24, all roles can profit from the proposals. And if you maintain all roles via the menu or the organizational field levels, you can simultaneously decrease your workload and increase role quality by approximately 90%.<\/p>

Fields you should always maintain<\/h2>

There are fields of objects which uniquely belong to applications – not only limited to transaction codes but also RFC-enabled function modules, Web Dynpro applications, web servers and all other types of modern application types available in SU24. For the sake of simplicity, we use transactions as examples going forward.<\/p>

If the transaction is uniquely destined for a specific field value (e.g., transaction FB03 needs only field ACTVT with value ’03’) or if pre-defined parameters are passed to it (e.g., transaction XT30 needs only S_PROGRAM, field P_GROUP, and value \u2018TRZ\u2019) then there is no reason not to add the field value to SU24. Leaving a proposal field open in SU24 creates redundant work as you will have to maintain the value later in the role anyway.<\/p>

Such examples of field values no-brainers because and they belong in SU24 if you use the respective transaction in a role. Not adding such proposals increases the risk of adding more authorizations than needed in the role and thereby over-authorizing the user for important object fields.<\/p>

Example 1: ACTVT and other activities<\/h3>

One of the most crucial fields is ACTVT. Thousands of applications with SU24 contexts use it, and it is incredibly easy to maintain. But there are additional fields that also control the “activity type” via authorization objects, but they may not be called ACTVT. Some examples include:<\/p>