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