The Wait Task is a process flow-control task that suspends a work
item’s progress until specified condition(s) have been met which are expressed
as one or more named Wait-Task Rules. The Wait Task is a process flow-control task that suspends a work
item’s progress until specified condition(s) have been met which are expressed
as one or more named Wait-Task Rules.
These rules that contain specific event-conditions which may cause the flow-control for a work item at the Wait Task to delay until the necessary conditions required by its Rules are met, such as any combination of the following:
§ Specified logical condition(s), created using the Expression Builder tool, are detected and satisfied by the Wait Task’s Rule(s).
§ Designated document(s) arrive in DocuPhase or change to a required state that is expected or required to continue the process;
§ A defined time-limit for the Wait Task is exceeded, allowing it to release its work item to flow down its ‘Timeout Path’.
Note: This new more general ‘Wait
Task’ replaces the ‘Document Wait Task’
which was used prior to Release 6.0.
‘Document Wait Tasks’ which have been automatically upgraded from
a prior release to 6.0 or beyond are shown with the ‘Converted Wait Task’ icon
rather than the new Wait Task icon (
).
The new Wait Task has added flexibility and power due to its new ability to ‘Wait for Logical Condition’ events to be detected and automatically trigger decisions and actions based on expressions that you are able to easily configure with the Expression Builder design tool (see the topic: Editing Wait Task Rule Expressions).
Complex logical expressions are possible. Also you may employ them in multiple modular rules which are applied by the Wait Task when rule-conditions match as well as at repeated intervals and maximum number of repetitions which you specify. A ‘Wait Task’ can now be configured to provide simple to complex control over the flow of work items on workflow paths.
By defining multiple named Wait Rules for a Wait Task, you can keep each rule simpler, more modular and easier to understand when you assign them meaningful Rule Names. Each Wait Rule’s order of evaluation for a task is controlled by where you position it in the Wait Task’s Rule List.
Also, you can Demote (i.e., Indent) rules to make them subordinate to the rule above as well as Promote (i.e., remove the Indention) a subordinated rule to remove the nesting. In other words, when a parent rule evaluates to a TRUE condition (i.e., the rule is satisfied), each of its subordinated rules are evaluated in their established order in the list.
An analogy to indented Wait Task Rules as program logic shows how a group of Rules can be evaluated sequentially, but Parent Rules provide a conditional guard condition that must be satisfied before its subordinated Child Rules can be evaluated, as illustrated below:
Aggregate-List-of Rules:
If (Do Parent-Rule A) = TRUE,
Then { Do Child-Rule A1; Do Child-Rule A2;
}
Do Rule B;
Do Rule C;
It is important to note the a Parent Rule cannot contain an Exit action internally, since this would cause the current work item to exit the Wait Task preventing any of its Child Rules from ever being evaluated. Progression will automatically detect this situation and prevent it from occurring.
Note: All of the Wait Rules for a Wait Task can optionally be viewed in combination so the workflow designer can easily inspect the combined logic of the sequence of parent and nested child rules.
Considering that many individual work items may flow through the same process and even the same Wait Task concurrently, each work item is able to flow independently of the other work items with no interference as some must wait while others are ready and able to continue their journey through workflow.