Can you really restrict any developer from executing any t-code?


We all know this. Nothing new. But thought of sharing a story at the end of this post, so lets build the plot..

Basis and Security put some roles in place to prevent developers from accessing certain transaction. But, are they really successful in their mission?

‘/h’ is the most deadliest tool in a developer’s arsenal. Developer always figure out a way to get to the forbidden transaction.


There are several ways to break the transaction restriction role, but I found FM ‘ALINK_CALL_TRANSACTION‘ the most convenient one. Using this FM as shown below, you can execute almost all the transactions (unless there are special multi-level security).

Check, I do not have authorization to t-code ‘RZ11‘.


So, I plan to use FM ‘ALINK_CALL_TRANSACTION’. Put a break point after the ‘AUTHORITY_CHECK_TCODE’ call.


Execute the FM and provide the t-code you want to execute.


The debugger stops after authority check.



Change the sy-subrc value to ‘1’. I emphasize, it is NOT ‘0’ but ‘1’. 🙂

Press F8 / Execute.


Here you are in the t-code ‘RZ11’.. Enjoy!!!

Note: Please use such tricks judiously and ethically.

A real story from history

On the 16th day of July, in the summer of 2010, a bunch of 9; young, hard working and exceptional SAP Technical folks were branded as Hackers and unceremoniously rolled off from a project. The reason stated was: Developers used some transactions which they did not have authorization to. And the most ridiculous thing: it was all in Non Production system.

Food for thought: If developers do not use ‘/h’ and/or debugging technique in Non Production, then are they really developers? 

This post is dedicated to those 9 Samaritans.. 🙂

So folks, please take note of the above real story and use your discretion while accessing any forbidden fruit in any landscape of your client’s system.


Image source: via Free Stock Photos


  1. In our PRD system, I cannot change fields, so se37 or changing values in debug wouldn’t work. We have sepecial IDs we can check out to allow when needed.

    Sounds like the security and basis were not doing a good job.

    • Hi Steve. Thank you very much for your message. You have mentioned the right practice for PRD.

      Ideally, we should not be debugging in PRD. Whatever developers want to play, only NON-PRD should be their playground.

      In case of rare event where we are not able to replicate the issue in NON-PRD, only then probably those special IDs should be used in PRD.



Please enter your comment!
Please enter your name here