A Split Join shape 
can appear on the Diagram tab of a flow rule. At runtime, this shape causes processing of a work item to split into two or more independent flow executions that operate asynchronously and then later rejoin. The modifier icon
marks a Process Modeler shape as a split-join shape.
This feature supports multitasking or parallel operation of work processing at the business process level. One department or business unit can, at its own pace and following its own flows, perform its functions for the work item while another department also works on the same work item. Similarly, if the split creates six subflows, they could be assigned to, and worked on, by six different users who are completing their assignments in parallel.
Increased business-level parallelism can improve end-to-end work item throughput, resulting in greater overall utilization of staff and improved customer service.
When the join occurs, the original flow can resume and advance. Depending on the details recorded in the Split Join Properties panel, joining can occur after all the split subprocesses complete,after some complete, or after any one of them completes.
The standard flow rule Work-.StandardParallelWork proves a simple example of Split Join use.
Do not confuse business process parallel processing with computational parallel processing. The split subprocesses execute asynchronously and independently, but often within the same Java thread on the same server node. When viewed at the computational level of microseconds (rather than minutes or hours), two Split Join subprocesses that contain only utility shapes do not execute in parallel on a single CPU.
During execution of a Split Join shape, the flow rule that contains the Split Join shape is known as the parent process flow; each of the split flows is called a subprocess.
Related terms