Routing to WorkList and Origin Stage from a Rejection Flow
I have a Case Type where there are Multiple Stages with Multiple Approval Flows and only one Rejection Flow.
The Approver picks up the case from a Work Basket/Work Queue and occasionally an Approver might reject a case and the case then enters the Rejection Stage.
After an end user (say Rejector) has worked on the Rejection Flow, the case NOW needs to be routed to the Original Approver/User's WorkList (not the WorkBasket it was picked up from) and the case should start again from that Stage it was rejected from.
I have tried 'Revert to Original Stage' Smart shape but it routes it to the Original stage's Work Basket only.
I have tried using an Assignment 'Resubmit for Approval" but this is creating a completely new Assignment and placing it in the User's WorkList but I am not able to route it to the Stage it came from. As it is creating new Assignment, end user is unable to comprehend what the new Assignment is.
Can some one please explain or rather show me how this can be achieved i.e. once a case has been worked HOW to route a case to a stage it was in and into the Worklist of the user who had originally worked on it?
Thanks for your reply. The Issue is not WHO the Approver/Rejector is as there are many ways to find out that value including the WorkParty as you mentioned. The issue is routing to the ORIGINAL STAGE from where it entered the Rejection Stage AND be present in the user's Work List.
Since the case is being routed to WorkList, HOW can we route the CASE itself to the stage (or point in the work flow) from where it was rejected. PEGA out of the box routes it to a Work Queue from where a user can pick it up. How do we send it to a Work List AND preserve the Stage, so that when the user opens the case again, they land on stage and the place they rejected the case.
In my screen shot, Black lines indicate when a user Rejected a case. The colored lines indicate where the Case needs to go back to AND be in the User's Work List.
A end user has certain number of WorkBaskets he has access to. So when they open their Portal they are seeing an Assignment which is having a different name viz. rawap in my example. As it has a different name from what they are used to, they are unable to understand what this new Assignment is, when they open their WorkList.
'rawap' is the name we have given for the assignment when the case is routed to the WL of the Original Approver.
I have also the attached the different stages in my Application.
Can you please explain what you mean by 'instead of using assignment, why can't you use the same approval flow and route to same user' with a diagram. I am in an alternate stage and I need to route the assignment back to the WorkList person who rejected it in a multi stage approval flow.
We ran into a similar problem and what we did was that we duplicated the Approval Smart shape for when a case needs to be sent to a WorkList and when it needs to be sent to a Work Queue from a Rejection stage.
In the routing to a WorkList we capture the original user in .pyApproverName property before the case reaches the Rejection Stage. ONLY this 'pyApproverName' property is being picked up by the Smart Shape.
Although there is unnecessary duplication, the above approach worked for us. Try it.