Idea ID: 2747155

OO Parallel Split - Output Variable Context

Status : Waiting for Votes
over 1 year ago


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.


  • The parallel step was designed from start to execute different  steps in parallel within the same context.  Operating within the same context does give you some authoring freedom, but comes with drawbacks,  one of them being as you have noticed that the last lane to complete will overwrite  certain variables  as it relates to the rest of the flow.

    While the contents of the lane itself can be shielded from interference  by packing them within a subflow  this does indeed pose a challenge when it comes to error handling for the various lanes.

    In order to help you with  error handling for both parallel and multi-instance steps I have created a demo content pack which delves into this issue for both parallel and multi-instance.  The flows in that content pack have callouts which explain the principles and challenges faced when doing the error handling. All flows can be run from any environment since they  handle synthetic data.

    Content pack can be downloaded from:

    Hope this helps,

    Vlad Moldovan