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.
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.
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
Thanks Lohit!
Hi Modak Gupta,
Actually I should thank you. Some how you pushed me to create my first document in SCN.
That's Nice...... looking forward for more!
cheers!
Hello Lohith !
It's well documented. Thank you so much !
Really, its a good document for everyone. You saved a lot of time for workflow consultants 🙂
Thank You.
Regards,
Murali Krishna.
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).
Regards,
Modak