Flows — Concepts and terms

Application developers use Microsoft Visio to create, edit, and evolve a flow. Process Commander uploads the resulting VSD file, including the Shape Parameters details from the workstation. Both the diagram image (a JPG file) and the rule details are saved with the flow rule.

Visio provides an attractive, easy-to-interpret and easy-to-manipulate presentation of the business process.

To start Visio on your workstation, click the Flow Edit toolbar button (). Create and evolve the flow in Visio as needed using familiar Windows techniques such as drag-and-drop. As you work, you can enter the names of utility shapes, decision shapes, assignment shapes, router shapes, flow actions and the rules that these shapes reference. If some of the activities and other rules for these shapes do not yet exist, you can leave the rule in draft mode.

As you exit from Visio, the system uploads the flow diagram (and the extensive data structure that Visio contains), and saves it in the flow rule.

You can't test a flow rule that has Availability set to No/Draft. You can test the flow rule if the Availability is set to Yes, even if the Visio DRAFT mode () is in force, indicating that not all the activities, properties, or other rules are yet defined.

At runtime, a user can start the execution of a flow by entering a new work object. The system examines the property pyFlowName, in the model instance for the class, to determine which flow to start. The flow operates on the work object to advance it through the business process that the flow implements, performing automated steps automatically, or creating assignments for users as appropriate.

You can think of a work object as located "on" one shape or arrow of the flow at any one instant, until the work object becomes resolved or the flow ends. Alternatively, you can think of the flow operating on the data (properties) in the work object until the flow finishes or the work object becomes resolved. Both points of view are correct.

A flow may define many optional detours, side trips, and branches reflecting decisions reached along the way. The path that one work object follows through the flow depends on its own requirements, automatic decisions in rules (such as decision tree rules and map value rules) and on available resources. For example:

• One mortgage application that fails to meet the automatic credit approval rules may require special research, while others are handled automatically
• An arriving customer service call in Mary’s territory may be routed to Tom if Mary is unavailable
• A request that is in a foreign language may be routed to a manager who can decide who among his or her team is best qualified to handle the request. Normal requests, not in a foreign language, may be routed automatically based on a round-robin algorithm.
• The system can randomly select one work object out of every hundred for a quality review.

As a flow rule executes, the following processing often occurs:

• The system generates a unique work object ID for a new work object. (This occurs for starter flows, those for which the Creates a new work object? box on the Flow form is selected.)
• As needed, it creates assignments for human users reflecting the need for more facts, judgments, and places the assignment into an appropriate user worklist or workbasket. After a user (or in some cases an agent or external participant) perform an assignment, the work object progresses farther through the flow.
• The system automatically makes decisions, urgency calculations, and gathers data automatically from many sources including outside systems.
• Rules promote compliance with service level goals, and alerts management or raises the urgency value when processing does not meet these goals. This is known as escalation.
• Processing of the flow ends when a FlowEnd shape is reached. The work object may or may not be resolved at that point.

The Process Explorer tool presents — for the currently selected application — starter flow rules and the subflows they call in a graphical form. See Process and Rules category — Processes page.

• A flow rule that contains no assignments, and so can execute from start to end without human input, is known as a straight-through process.
• A flow rule that consists only of assignments or decisions and meets other criteria is known as a screen flow.
• A flow that creates a new work object is called a starter flow.
• A flow that is called by another flow is known as a subflow; the calling flow is called parent flow. Processing of a subflow is synchronous, meaning that the calling flow execution pauses for the duration of the subflow. When the subflow execution reaches an End shape, the calling flow can continue (if additional shapes are present). See Flow rule — Completing the Diagram tab — Call or Branch to a Subflow.

In some business processes, the order of certain steps is not important as long as all the steps get done. In other situations, a step can be considered complete when either of two other steps finishes.

The Split/Join facility () supports such asynchronous operation, by allowing processing of two or more subflows to proceed in parallel. For example, a contract may need approval of both a legal reviewer and a purchasing department reviewer, but order is not important. In the 1980's era of paper forms and in-boxes, only one of these two has the paper — artificial sequencing. With a work-object and a flow that uses Split-Join, each subflow can create an assignment, and the two reviewers can proceed independently.

See Flow rule — Completing the Diagram — Split/Join shape.

Split-Join parallel processing occurs only when considered at the business process level. Although two assignments exist, they both belong to a single work object. During the minutes or seconds that either user performs the assignment (thus updating the work object), the system locks the work object and so the work object is not available to the other user.

Similarly, at a more atomic level, if the two users both access a single-node Process Commander system that has a single JVM and single CPU chip, no parallel processing occurs at the Java thread level, even when the two users work on different work objects.

The Split-forEach facility () causes multiple subflows to start, one for each page of a Page List property. Processing can resume after any one, or all, of the subflows end.

See Flow rule — Completing the Diagram tab — Split-forEach shape.

A Spin-Off shape () starts asynchronous execution of a different flow, on the same work object or a different work object. Processing of the current flow does not pause or wait for results from the other flow.

See Flow rule — Completing the Diagram tab — Spin-Off shape.

Process Commander offers ways for a flow execution to be started for an existing (open) work object. These are alternatives to calling a subflow, using a Split-Join shape, or using a Split-forEach shape:

• Users can access an open work object in update mode, click the  Start a new process   button, and choose a second flow to start. This button is available on most Update work object forms. Users may be prompted to enter flow parameters to complete the operation. The  Start a new process   button lists all the eligible flow rules with the Can be added to a work object? box selected on the Flow form. (To include this button on a work object form, reference the standard section rule Work-.Flows in a harness rule.)
• Users can select the standard flow action Work-.AddFlow, Work-.AddCovered, or Work-.AddtoCover to start a new flow execution.

Several system-maintained properties in a work object record the current state of flow executions in process. For example, the integer property @baseclass.pxFlowCount indicates how many flow executions are in process for the work object.

The Page Group property @baseclass.pxFlow contains a page of facts about each execution:

• pyFlowType — Second key part of the flow rule
• pxAssignmentKey — Key of the current assignment instance for this flow execution. typically an instances of the Assign-Workbasket or Assign-Worklist class.
• pyLastFlowStep — Internal name of the most recent shape or connector processed
• pyNextFlowStep — Internal name of the next shape or connector to be processed
• pyFlowParameters — A classless page containing parameters used to start this flow