Description Of Issue: In today's Parallel Split configuration. If you have multiple lanes that produce unique outputs using unique variables. There is a high probability that the variables will be override. This means if you have operations or subflows later on in your process that require the information produced by one of the flows or operations in the parallel lane, you will not have this information.
The behavior that we see is:
When lane 1 finishes it's execution first, output variables JsonStringOutput1 (Lane1) and JsonStringOutput2(Lane2) are copied in to the flowcontext and later when lane 2 completes the execution output variables are copied in to the flow context in the order in which the lanes terminates. Thus overwriting the already existing JsonStringOutput1(Lane1) and JsonStringOutput2(Lane2) variables in the flow context.
If we had situations where we were to run two lanes that perform actions but its output didn’t need to be processed; we would still need some sort of output to inform the rest of the workflow if lane 1 or lane 2 succeeded via a condition check. Without this we are always assuming that everything executed in Parallel Splits is successful (which is bad).
Ask: To allow each lane in a Parallel Split to control there own workflow context and not override each others as if it were a single execution.
Benefits/Value: Allows customers to leverage the benefits of Parallel Splits and process the outputs of each lane in differently later on in the workflow.