Skip to Content

Adding t-code in menu and adding t-code in S_TCODE manually

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.           



You must be Logged on to comment or reply to a post.
  • 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.

    Hi Amit. Good blog post, but I would clarify the statement above.

    Custom tcodes should be treated in the same way as SAP standard tcodes and added to the role menu. If they have been developed properly the source code should (in most cases) contain authority checks, and therefore should be updated in SU24 with the corresponding objects and proposals. Unless your developers can provide a good reason as to why the custom tcode does not need authority checks, then I would expect them to insert relevant checks (ideally using standard SAP auth objects wherever possible).

    This will also make it much easier to accurately capture custom tcodes in any segregation of duties or critical permissions management tool.

    • Hi Will,

        I agree with you and it is always a best practice to include the auth. checke whenever a new customised T-code is created. Once the security team member adds that T-code in any role, he should also maintain those auth, object checks in Su24 for better security.


      Varun Jain

    • Yes, for all the txns objects should be maintained in SU24 with check indicator as Check so that, it reduces the future maintenance as when ever you remove the txns from the menu, it will automatically remove the corresponding objects from the role, which will reduce the SOD conflicts as well.

  • I just wish that SAP will give us something like S_TABU_NAM for programs.   P_GROUP just doesn’t work well, and creating Z transactions for any report that a person needs to run involves cost and time and results in so many Z TCodes.   I know it’s not related to SU24 but I wonder if something is planned.

  • For my two cents, however, there are times when it may be necessary to manually assign tcodes which may be checked by certain programs, but for which you do not want to make available in the user menu (I have seen this before).  Also, I don’t really see any problem in having a mix of manual and standard auths for a given object within a role.  Again sometimes there are very good reasons for configuring your roles this way.  Additionally, it’s important to point out that it’s good practice to deactivate several of the default auth objects which may be pulled into the role by assignment via the menu if they are not needed (or should not be assigned e.g. S_TRANSLAT).  I have to say in the 10+ years I’ve been working in Security I pretty much never use AGR_TCODES table and instead rely on AGR_1251 (filtered on S_TCODE if neccessary) and that any Compliance tool worth it’s salt should still correctly flag any violations resulting from manual assignments of auth values.

    • Hi Kevin,

      There are standard ways of dealing with each of the situations you mention above without using manually added authorizations. The one circumstance where manual auths have a valid use case is in Value roles. Otherwise, whilst using them may seem like the best option at the time, it’s just storing up problems for the future (and since you mention Compliance tools, the issue is not least pronounced with SoD remediation).



    • Hi Kevin

      IMHO I can’t see any reason to manually add S_TCODE values to any roles – it just seems so ‘wrong’.

      If a program calls a transaction during running (and the user has no authorisation to do this) then the calling transaction should either be set up (TCDCOUPLES no check? still not 100% sure about that) or via SU24 (no check?) sorry for the question marks 🙂

      Adding manually means the checked/proposed authority checks are excluded from the role it lives in, presumably, because the auth objects are not in the role then it may not work in isolation if checked and then makes the role look clean in CC/GRC/AC10.x.

      I think the best thing is to make the correct decisions about the program and SU24/TCDCOUPLES before going for the S_TCODE route – especially when you then have no idea why the damned thing is there in the first place 2 years down the line 🙂

      Phew.. glad I got that off my chest!



      One thing… if you set the tcode to not checked and it then allows the user to get to the ‘next level’ (claim a grapefruit in Nintendo) what happens to that called transaction’s authority-check in that program? Does it still ask if the user has the required auth objects and if not will it then stop anyway…

  • My original comment was meant to imply that this should mostly be done on an exception basis, but I stand by my original comments.  One example, if just for expediency sake, is to code values in ranges or with wildcard values (especially for support team or Emergency Access type roles).  Even SAP delivered roles (which I don’t necessarily rely on) frequently include manually inserted S_TCODE values with empty menus.  In the case of the role designs I have primarily created/ supported we nearly always use enabler roles to varying degrees and therefore need to rely on an analysis at the level of a composite role or user level already for SOD/ Sensitive permission.  As with any good role design having excellent role documentation will help to head off any issues down the road.  As for the Check/ Maintain question, as long as it’s a standard SAP tcode (or at least calling SAP function modules with the authority check embedded), it will still perform the authority check at runtime but will just pass it with a Return Code = 0.

    • Hi

      I understand the concept but do not accept the build as being correct.

      Business role access = never

      IT/Support access = during initial build but not during support phase

      What is the value in creating roles (for PRD) which will give ranges/manually added transactions which can then pick up user level access which may or may not be registered by which ever  SoD/IT critical system set up to find these?

      I agree with some moderate manual auth objects in the flakey pixie dust areas of support during initial build but not long term but not to the degree being proposed.

      “any Compliance tool worth it’s salt should still correctly flag any violations resulting from manual assignments of auth values” – we cannot base our evaluation purely on a system bought, configured or provided to secure the system.

      “I pretty much never use AGR_TCODES table and instead rely on AGR_1251 (filtered on S_TCODE if necessary” – if the role build is good this should not be required.

      But, hey – that’s down to our own personal perspective of this area 😉

      Edit – BTW – enabler roles… wonderful little things which, regardless of endless documentation, add a level of confusion to onshore/offshore/unit testing/UAT are in my opinion, a complete waste of time (quote me on that). I hate them as much as derived roles which have parents and grandparents.

      Kind regards


  • Good thoughts, S_TCODES should not be added manually in business role because it only adds ambiguity. But I do see some exceptions to add S_TCODE manually in role for
    system/communication user even its not best practice