Application Development Blog Posts
Learn and share on deeper, cross technology development topics such as integration and connectivity, automation, cloud extensibility, developing at scale, and security.
Showing results for 
Search instead for 
Did you mean: 
Former Member

Transaction codes should never be added manually to S_TCODE instead it should always be added as a menu item within a role. If not followed as stated it would result in a number of ambiguity within SAP system and your security approach will not be effective.

Let’s try understanding the implications with an example. I have created two roles with different approach i.e. adding tcode in role menu and adding S_TCODE manually in to authorization tab. I have noted down some points on the behavior of these roles to give a clear understanding.

Here is how the auth tab looks in these cases

Tcode added in role menu

when we add tcode in menu and precede to authorization tab the profile generator automatically pulls all the maintained authorization objects for that tcode. These pulled authorization objects contains authorizations which are eventually assigned to users when the role is assigned to him.
Here I have added tcode SE01 in the role menu and it has pulled below authorization objects (refer above screen shot)
For instance take object S_DATASET  has been pulled along with below authorization which will allow user to perform Activity 06, 33, 34 through program SAPLSTRF for any file

In the same way other objects have been pulled along with their standard authorizations as maintained in profile generator tables (USOBT_C, USOBX_C). When a user is assigned this role he will eventually get all these authorizations thus able to use the complete functionality of transaction SE01.

S_TCODE added manually
Authorization tab in this case looks like

Functionality of a Tcode is governed by various authorization objects associated with it and since we have added Tcode SE01 in S_TCODE manually we don’t have any other authorization objects which are necessary to make SE01 function properly. This role will only allow user to execute SE01 and any further authorization check related with SE01 will fail.  Even after having access to SE01 user is not able to use all its functionality.

Generally (not always) custom tcodes are not associated with additional authorization objects/checks so for custom tcode this approach may work fine but not for SAP standard tcodes as they are generally bounded with so many authorization objects/checks.

So to avoid any potential issues/escalations from end users always follow the standard procedure for creating role i.e. add Tcodes to menu and never add it manually to S_TCODE.

Other ambiguities arising due to this (adding S_TCODE manually in role)

  • SUIM report won’t pull such roles when you are searching roles through transaction assignment 


  • But these roles can be found using criteria below in SUIM


          But we are not sure if the role has other relevant object in it.

  • As the role`s menu doesn’t have tcode, user having that role does not have any node for this tcode in his user menu (tree) so to execute this tcode user has to use transaction window rather than navigating through user menu. Most of the end users use user menu and transaction window is generally used by technical users.

  • Manually adding the S_TCODE object will bring in two instances of the object in the role. This will not create any authorization issue but it is breaking the homogeneity of the role as manually added instances cannot be merged with other standard instance


  • During analysis such roles will be always skipped through data browser (using SE16) unless we include authorization object as one selection criterion. E.g. Table AGR_TCODES won’t pull expected result for such roles.

  • Some risk remediation tools which identifies risks and SODs will generate reports taking into consideration tcodes assigned to a role. Due to such role these tool might produce incorrect results.           



Labels in this area