The reason we didn't want to put a join parallel gateway before reaching the wait 1 task , is to give the possibilty to the user to complete that task , we could put the join before the end none event but this will complicate our model as we have a long process to model (too many rows to model at the end if so)
1. We don't want to terminate the active paths so end terminate event won't help in this case
2.If we merge like you did in the your model , the process should wait for the task wait 2 to be completed to give the execution to another user to complete the Wait 1 task.
The error is thrown if the last remaining task (after the other parallel path reached the end event already) is referencing a form.
This is what the support told us :
The reason for this is is the parent execution being ended by the first end event and while loading the form, the engine trying to get form field values of earlier task forms by accessing the parent execution, as someone might have used a form field with the same field id somewhere before the parallel gateway.
Based on your reasons it makes sense to model it this way. Also, as per BPMN spec it is not really necessary to merge/join the parallel gateway (a new learning for me too) into a "None" end event!. This has been asked before on this communityBehaviour Parallel Gateway without Join. The activiti engine is working all good executing both the execution paths in parallel and you can see that by viewing the process in admin application. I believe it is the logic for UI that is failing in this case! If this is an urgent thing, I'm afraid changing the model to have a parallel join is the only option (as far as I'm aware!)