Designing a workflow

A workflow can represent a repeatable business process. You need to define the process, the tasks and other activities involved, the relationship between them, and the conditions that are required to execute each task.

When you have designed the process, define it in terms of the workflow tools, namely the gateways, specific conditions, default flows, tasks and message destinations as described in Workflow Palette and Tools.

Before starting, review the following recommendations and considerations for building workflows:
  • When using a gateway, you should generally conclude the operation by pulling the paths together with the same gateway, as shown in the examples. This also allows the different paths between the gateways to complete before continuing the workflow.
  • Limit workflows to approximately 15 components. Incidents can change dynamically and a large or complicated workflow might take too long and miss the changes.
  • Create small workflows for simple, repeatable processes and then use these workflows as child workflows to simplify more complex workflows. This helps to limit the relative size of the workflow; however, you might want to limit the depth of nested workflows to prevent possible memory or performance issues.
  • When feasible, limit the use of Message Destinations that are configured to wait for an acknowledgment. The workflow stops when it reaches the message destination and waits until the message destination receives its acknowledgment before continuing. Optionally, you can add a Timer Event to proceed to a different part of the workflow if the acknowledgment is not received in a specific length of time.
  • The workflow also stops when it reaches a manual task and waits until a user marks the task as complete before continuing. Again, you can add a Timer Event to proceed to a different part of the workflow, such as an alternate task, if the manual task is not completed in a specific length of time.
  • Review your timers, especially when using repeating non-interrupting timers, to avoid having many workflow instances blocked on the closing of a task. For example, you may not want a timer to repeat every 15 minutes for a long period of time if a task is never closed; instead, set the repeating timer to a limited number of occurrences.
  • Use functions in workflows to perform data-gathering activities remotely and send the result back to the workflow.
  • Be sure to annotate your components and connections so that the workflow is self-documenting.

Here are a few simple examples of workflows.

The following example has two paths that execute together. There are 4 tasks (A, B, C, and D) and two parallel gateways. When a rule invokes this workflow, task A is added to the corresponding incident. Afterward, both the B and C tasks are added to the incident. The second parallel gateway is used to complete the circuit, which is a recommended practice. When both of the B and C tasks are completed, task D is added to the incident.

The surrounding text describes this graphic, which is a view of a workflow.

The following is an “exclusive gateway” example, where you can take one path only. There are a total of 5 tasks (A-E) and two exclusive gateways. When a rule invokes this workflow, task A is added to the corresponding incident. In this example, it determines the city where the incident occurred. Depending on the output of Task A, Task B, C, or D is added to the incident. Note that the gateway has a Default Flow connector to Task D so that if the city is not Boston or Cambridge, the workflow defaults to Task D.

The second exclusive gateway is used to complete the circuit, which is a recommended practice. Once B, C or D is completed, task E is added to the incident.

The surrounding text describes this graphic, which is an example of the workflow.

This is an “inclusive gateway” example, where you can take many paths, but only the ones that are true. After Task A is completed and the state is equal to Vermont (which is in the New England region) then both B and D are added to the incident. When both tasks are completed, Task E is added. Note that the Region is New England connector is the default flow in case the location from Task A is not New Hampshire or Vermont.

The surrounding text describes this graphic, which is an example of the workflow.

Each of the examples with an inclusive or exclusive gateway designate a Default Flow path, which is a path that is valid when none of the conditions assigned to the gateway’s outputs are met (that is, none of the statements are true). A Default Flow path cannot have a condition.