The process design doesn't follow sound practices for splitting and merging branches using gateways. When you use a gateway to split a process into branches (like you did with the parallel gateway), all of those branches should reconvene at a merging gateway if you need to merge them back. Here is how I would approach your design:

Use a parallel gateway to hit all of the different branches. For the branches that don't need to reconvene, let them trail off and end at an end event. For the branches that DO need to merge, split them again using an inclusive (or parallel) gateway. For those branches, you can do all of your actions, but make sure they end at the merging inclusive gateway. Don't put an end event within there and don't use a gateway with a route that goes away from the merging gateway... this is what will cause the weird merging behavior you are experiencing. In my diagram below, the inclusive split gateway and the inclusive merge gateway is a closed loop with no end points or paths out. 

(The one exception to the rule is your timer catch events then end events. Since those do not interrupt your user tasks, those are fine between the gateways.)

So looking at your process, put the Info Gathering, supervisor info gathering and IT windows user tasks inside that inclusive gateway, and have the rest directly off the parallel gateway.