Skip to Content


In this doc we will discuss various methods to restrict the user to release the Transport request in SAP.

THis scanerio is used when you are having third party support and you want to check all TRs at your end and dont want to give them authorization to release the TRs.


We don’t have any enhancement points in program so we will go with BADI.

First Method: Authorization Check Method

This is a little bit complex method but you will learn authorization object creation & using it in SAPUser Roles.

Go to SU21:

Fill the Object name, class, authorization field:


Click on permitted activities & fill Release Code activity i.e. 43:

Now save it all.

Now Punch Tcode SE19 &

Create Implementation of CTS_REQUEST_CHECK Badi as in following Screenshot:


Select 2nd option which is area to check coding before releasing a request:

Use your coding in this method to restrict as per requirement.

What we have used here is an authorization check, so following is the code:

Save it. Don’t forget to activate it as well as BADI in previous screen.

Now give the user  the Authorization object we created, with the help of BASIS Consultant:

Users having upper listed object (Z_TR_REL) can only release the TR.

Otherwise will have following error while releasing the TR.

JOB Done!!


2nd Method: Table Entries check method

This one is easier as we don’t have to go to every user role. We just have to enter the User name in table & that will be checked while releasing the TR.

Create a Z table with following fields & maintenance view:

Save & Activate the Table.


Now open SE19 & do the same procedure as mentioned (to add coding in 2nd option):

Code will be different for this one as it will check the table & the username entered there will not able to release the TR.

NOTE: If you want opposite of this, do following coding in the block:

Now save it. Activate it.


Make entries in table we created earlier:


Now create TR from the SAP ID & Check.

Voila !! JOB DONE!!..


Thanks all for reading this as it is my first time blog & hope you all get benefits from this.

You must be Logged on to comment or reply to a post.
  • Unfortunately you have not explained any scenario under which this would be needed, also no words when you would use the first option and when and why the second option.

    • Thnkx deae..


      Added that point..

      And for your info this is when we are having 3rd party support for some upgradation and we want to keep our system secure and dont want then to release any request… this is what we use then…

          • but there is a good chance SAP_ALL is regenerated with Z objects included. So you are stuck with same issue as S_TRANSPRT for option 1 with custom object



          • Yups!!! Thanks I didnot consider that one… Noted….

            Then you have to go with second option only.


            It feels good when receive queries…. thanks dear….



          • Build dedicated security roles to assign to users instead of sap_profile. That way you can rely on s_transprt activity 43


            This is best practise not to give users sap_all


            Even if a basic starting point is to build your sap_all role and strip out permissions you don’t want your users to have


            Training to tell them they must follow process and not release the change


            Trust that they don’t use debug change or another workaround to release it


            ***update your can use a step in SU25 to run a program to build the role and exclude objects or classes from it. Much faster than PFCG manually built role***