Can a case exist in flows in different stages?
While I'm still a little unsold on the v7-style Process & Stages paradigm (see Expressing the details in process flow steps)...
I do have one simple question at hand.
Consider a case with parallel processes. Is it possible for one process to move forward to a new stage, while the other process stays behind.
That doesn't make conceptual sense, really, but I think it's technically possible -- I've seen it.
But what are the full ramifications of this design?
***Updated by moderator: Marissa to close post***
This post has been archived for educational purposes. Contents and links will no longer be updated. If you have the same/similar question, please write a new post.
Pegasystems Inc.
US
Feedback from new users of Pega systems is that they find multiple assignments / parallel processes on a case confusing. If there are optional processes in a stage, there is a good chance that the user may click on one and try to cancel out if they do not wish to move forward - system has to differentiate between ending the 'flow' (and 'clean up' the assignment(s)) verses discarding changes done on the assignment in the user's latest attempt to update the case. Also actions drop-down would show multiple assignments and local actions at each assignment.
One design option is to not use optional processes and to 'chain' automatically launched processes in a stage such that there is only one active assignment on the case which would be used to advance the case from one stage to another (Finishing the assignment through connector flow actions) - but have additional flow actions modeled and conditionally shown as local actions at that stage. This addresses the usability problem around multiple assignments and also allows only the person having the security to perform on the "active assignment" to advance the case to other stages.
I'm still learning PEGA 7 and have yet to tackle parallel processes on this version - though I've had this in 6.1 Smart Investigate (SI). I think conceptually you have to be careful with parallel processes, most users and stakeholders are not ready for this. With SI our businesses began to get confused when there were parrellel assignments (processes) - we had to have clear training about who the owner of the overall case was as opposed to some of the parallel assignment. Thus far we have disabled parrelel assignments, each one needs to be completed before the next - this is a much simpler flow for an end user to understand.
My initial thoughts are that you treat a parallel process as a sub-case and then treat it as such during your design discussions with the business. For example a customer requests a new Credit Card as they have lost thier current one the main flow kicks off a cancellation of this credit card so it is not misused and then a the parallel process for issueing the new card is kicked off by way of a different case type triggered in this initial case. This is easier to playback than having one overaching case with different flows and assignments overlapping.
Would be keen to understand how others have tackled this though.