Skip to Content
Author's profile photo Sukhwinder Singh


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.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Jürgen Lins
      Jürgen Lins

      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.

      Author's profile photo Sukhwinder Singh
      Sukhwinder Singh
      Blog Post Author

      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...

      Author's profile photo Shai Sinai
      Shai Sinai

      Won't standard authorization object S_TRANSPRT (ACTVT=43) do the work?

      Author's profile photo Sukhwinder Singh
      Sukhwinder Singh
      Blog Post Author

      HEy dear!!!


      Its when you have to give the user sap all and have to revoke the same in sap all profile....

      Author's profile photo Colleen Hebbert
      Colleen Hebbert

      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



      Author's profile photo Sukhwinder Singh
      Sukhwinder Singh
      Blog Post Author

      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....



      Author's profile photo Colleen Hebbert
      Colleen Hebbert

      Recommend option 3: don't have sap_all in conjunction with train, trust and audit

      Author's profile photo Sukhwinder Singh
      Sukhwinder Singh
      Blog Post Author

      ahmmmmm I have not heard about this...... can you refer something against this..... ??

      It would be so nice of you .....

      Author's profile photo Colleen Hebbert
      Colleen Hebbert

      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***

      Author's profile photo Vinayak Budapanahalli
      Vinayak Budapanahalli

      Hey Sukhwinder,
      Nice blog along with the options.

      We have a weird problem with releasing the main transports.

      Very few users are able to release the transports in a system which was locked under the ChaRM. In which, technically, no one should be able to release the main TR, and this restriction is working absolutely fine for most of us. However, few developers were able to release the main TRs from SE10 transaction without even moving any status from ChaRM UI.

      As Colleen mentioned in the comment sections, can we try with s_transprt activity 43?

      Any advice on this?


      Vinayak Budapanahalli


      Author's profile photo Sukhwinder Singh
      Sukhwinder Singh
      Blog Post Author

      Hey Vinayak, thanks for going through my blog..

      Yes, activity 43 is responsible for allowing releasing the TRs. Don't assign activity 43 to the same users, those will not be able to release the TRs.


      Also, give a look at the TTypes given to those users.



      Sukhwinder Singh

      Author's profile photo Antoine Abergel
      Antoine Abergel



      I have followed the steps and it works perfectly for me ! I would like to know if there is a method that exists to check if the user in my Z table is authorized to delete a transport request.


      Thanks a lot !