Back Forward Flow form
Editing the Split/Join shape properties

 About Flow rules

Purpose

Use the Split-Join shape to require that multiple subflows of your flow be completed before the current flow continues execution. This allows subflows to execute asynchronously, in parallel. For an example, see the standard flow Work-.ParallelWork.

For example, a mortgage application workflow may require that facts about the home buyers be validated, and that a title search be completed. These two tasks are unrelated and can be performed in subflows that proceed independently and in parallel. Other processing later in the primary flow can require that both these two subflows complete.

Adding a Split/Join task to a flow

Drag the Split/Join shape (Split Join shape) onto the flow and drop it. When the Split/Join Properties panel appears, complete these fields:

Field

Description
Split Join Rule  
Name

Enter a text name for this Split/Join shape . Choose a name meaningful to application users who see this on the work object history display, the breadcrumbs control (for entry points), and the Where-Am-I? diagram.

The task name is only descriptive; it does not affect runtime execution of the flow. This name also appears inside the Split/Join shape on the Diagram tab.
Join When.. Flows are Finished

Choose Any or All. Choose:

  • All if the current flow is to resume only when all the split subflows return.
  • Any, if processing in the current flow is to resume after any one of the split subflows completes. At that time, processing of the other split subflows that have not completed is stopped. Open assignments for these subflows are cancelled.
Cost

Optional. You can associate a cost value (in any units) with this branch. For each work object, the system computes the sum of these cost values for the specific path it takes through the flow rule.

Audit Note

SmartPromptOptional. Select or enter the name of a Rule-Message rule to control the text of an instances added to the work object history (the "audit trail") when a flow execution completes this shape. Process Commander includes a few dozen standard messages in the Work- class. (Through field value rules, you can localize the corresponding text on work object history displays. See About the Localization wizard.)

NoteOptionally, to reduce the volume of history detail instances, your application can prevent system-generated messages from being added to work object history. See Controlling the volume of generated work object history instances and the Pega Developer Network article PDNPRKB-25196 How to control history instances written to the audit trail.
Audit Note

Optional. Click the plus sign to access a text box. Text entered here appears as a history instance for the work object recording that this Split/Join task was started.

NoteWhen you plan to localize the application using this rule, so the application can support users in various languages or locales, choose the text carefully and limit text length to 64 characters. A field value rule with this text as the final key part is needed for each locale. When practical, choose a caption already included in a language pack, to simplify later localization. See About the Localization wizard.
Entry Point?

Select to indicate that this Split-Join task is an entry point, which a user can return to using the breadcrumbs control or the standard flow action Previous. The default is cleared.

This check box works with Perform harness rules that include a breadcrumbs display and with assignments that offer the Work-.Previous flow action. In other cases, the check box has no effect.
Only going back?

This check box appears only when you select the Entry Point? check box. Select to restrict users at runtime who are at this entry point to choose only those entry points (on the breadcrumbs display) that identify earlier steps in the flow.

Leave unselected to allow users to select any entry point of the flow when at this entry point. They can click the breadcrumbs control or tab to complete or visit an earlier or later step.

TipFor maximum user flexibility, leave this check box unselected if your flow accepts inputs in any order. However, this approach is typically not workable for flows that contain fork and decision shapes, or that have intermediate tasks that are not entry points.

Then click  Apply . (To edit these shape properties after you save the Flow form, open the Diagram tab, right-click the shape, and select the Edit tab on the pop-up window.)

Connectors

1. Connect at least one incoming connector to the top of the Split/Join shape. Add at least one outgoing connector to the bottom of the shape.

2. Expand the Split/Join shape so that the rectangle becomes large enough to enclose the Flow shapes.

3. Select and drag a Flow shape (Flow) for one of the subflow to be started. Complete the SubFlow Process panel; then click  Apply  .

4. Repeat for each additional flow to be started. The Split/Join shape must contain at least two called subflows.

5. Split Join ExampleAdd a connector from the top triangle to the top of each called flow. Add at least one connector from the bottom of each called flow to the bottom triangle.

6. Complete the Connector Properties panels. If you choose Status for the connectors that start the subflows, you can associate a Likelihood value with each. At runtime, Process Commander starts the called flows in order of greatest likelihood.

zzz About Flow rules