Skip to Content
Author's profile photo Former Member

Agent Assignment at one shot without RHMOVE30 before starting First Workflow in System

After series of comments with Modak Gupta on document The most common Missing Link in Workflow Cutover – Agent Assignment and RHMOVE30 supported with document created by Mehreen Dudhwalla and following one of the post of Pavan Bhamidipati I have included the steps to make sure whenever we do agent assignment for dialog task it asks you for Customizing request.

Till now we have followed the tradition of Using the Program RHMOVE30 which has very well served the purpose. However I feel instead of running this program every time for all the Dialog tasks  its better to do configuration so that every time you do agent assignment it asks you for Customizing Request.

Please follow the below step :

Step 1 : Go to T-Code OOCR and remove the flag ‘X’  of the selected record shown below and save it.


Testing :Now IF you try to do agent assignment for any dialog task it will  ask you for custom TR as shown below.

Agent Assignment.jpg

Agent A1.jpg

Knowledge Transfer: If you notice what we have achieved with this is agent assignment creates Lock Indicator for Object Type Standard Task similar to T-Code PP01 as shown below. Go to PP01 and enter details as shown and select Classification/Lock Ind .


On click of Create it will take you to the screen shown below which allows you to make task classification as shown below and on save it asks for TR.

PP01 Create.jpg

Concept of RHMOVE30 : When you assign agent or make it general for dialog task it makes an entry in HRP1217 table with the flag General_Task Field as ‘X’ and this record against the Task is transferred  to TR .

Hope the document helps you in making sure that none of your workflows will never go to Agent Assignment problem when ever you transport WFs across Quality & Production systems.

Happy Workflows

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Modak Gupta
      Modak Gupta

      Thanks Lohit!

      Author's profile photo Former Member
      Former Member
      Blog Post Author

      Hi Modak Gupta,

      Actually I should thank you. Some how you pushed me to create my first document in SCN.

      Author's profile photo Modak Gupta
      Modak Gupta

      That's Nice...... looking forward for more!


      Author's profile photo Suresh Subramanian
      Suresh Subramanian

      Hello Lohith !

           It's well documented. Thank you so much !

      Author's profile photo Murali Krishna
      Murali Krishna

      Really, its a good document for everyone. You saved a lot of time for workflow consultants 🙂

      Thank You.


      Murali Krishna.

      Author's profile photo Modak Gupta
      Modak Gupta

      Hi All

      Just found one drawback to this approach today and wanted to share with you!!

      To include the Agent Assignment in a transport request, this approach is fine. However, removing the "X' from OOCR (TRSP-CORR) can result in a larger issue that PD Objects which are intended to be changeable in QA or PRD cannot be modified then.

      For example, I had maintained the above settings in my Development System (and development client); system forced me to save the changes (OOCR Changes) in a customizing request. When that request went to the test client - all was fine, till I tried using OOCU_RESP.

      I had created a responsibility rule and wanted to assign responsible agents to it (different in different clients). I could not use PFAC because "System / Client was not modifiable" ; Hence I tried using OOCU_RESP to assign responsibilities. I got the same message "System / Client was not modifiable" and could not assign the agents. The whole purpose of OOCU_RESP was defeated.

      The same is mentioned in the note 1416609 - PD Object can be changed although changes are not allowed (although in a different way - but it is clear). If T77S0: TRSP CORR X Transport Switch (X = No Transport) is cleared, system will prevent any changes to the PD Objects (OOCU_RESP is included) based on System Settings.

      The above is just one example - our HCM guys will be after us if they face issues in QA/PRD 😉  for their expected-to-be-modifiable-objects-going-display-only

      Hence: Use this option if you are sure that PD object modification will not be required in NON Development systems (I doubt that there will be any such case ever).