Automation Rule Example 4
Create a Rework Loop in a Workflow
When the completion of a task has failed, the status of its successors does not get updated to ‘Assigned’ and the workflow is placed in the status ‘Progress Halted’. The workflow manager can then decide how to get the implementation going again. For some workflows, this always means reworking a task that was completed earlier.
In this example there are 3 tasks that are to be completed sequentially:
- Develop new release
- Transfer new release to test
- Test the new release
- Transfer new release to test
If the third task fails, the workflow manager wants an automation rule to set the status of the first task back to ‘Assigned’ and the other two tasks back to ‘Registered’. That would ensure that the workflow loops back to the first task.
The following sections describe how the workflow manager can define the key parts of this automation rule.
Trigger
Because the rule needs to be executed after the third task has been set to ‘Failed’, the option ‘On status update’ is selected in the Trigger field.
Expressions
The following expressions are defined for the rule so that they can subsequently be used to define the condition for the rule, as well as the actions that it needs to execute:
1. has_failed
The expression has_failed specifies that the Status field of the third task is set to ‘Failed’. It is defined as follows:
status = failed
2. note
The expression note is added to look up the note that was added to the third task when its status was set to ‘Failed’. This will be last note of the task and it should describe why the task failed. This expression is defined as follows:
notes[last].text
3. develop_task
The expression develop_task is used to identify the task for developing the new release. The subject of this task is ‘Develop new release’, which means that the expression can be defined as follows:
workflow.tasks['Develop new release']
4. transfer_task
The expression develop_task is used to identify the task for transferring the new release to the test environment. Because the subject of this task is ‘Transfer new release to test’, the expression can be defined as follows:
workflow.tasks['Transfer new release to test']
Condition
After the expressions have been defined in the rule, the condition, which needs to be met in order for the rule to be executed, can be set. In this example, the status of the task needs to be ‘Failed’. Since there is already an expression for this, the condition that needs to be true is simply:
has_failed
That is all that needs to be entered in the Condition field of the rule.
Update 1
The first action that needs to be executed by the rule is the addition of a note in the development task to inform the developer why the task has been reopened. The expression develop_task already exists for this task. This expression can therefore be selected in the Update field.
Add note
Because the objective of the first action is to add a note to the development task, the default option ‘Set’ needs to be updated to ‘Add note’. That provides a rich text field in which the note can be defined. To include the last note of the failed task, the expression that was defined for this last note can be used in the note:
The new release did not pass all tests:
{{note}}
Update 2
The second action of the rule needs to reopen the development task. So again the Update field can be set to the expression develop_task.
Set
Because the objective of the second action is to set the status of the development task back to ‘Assigned’, the following needs to be specified in the Set field:
status = assigned
Update 3
The third action of the rule needs to update transfer task. The Update field can therefore be set to the expression transfer_task.
Set
The objective of the third action is to set the status of the transfer task back to ‘Registered’. This can be specified in the Set field as follows:
status = registered
Update 4
The fourth action of the rule needs to update the status of the test task. Since this is the task for which the automation rule is defined, the Update field does not need to have a value. That causes it to default to the current record (i.e. the test task).
Set
The fourth action needs to set the status of the test task back to ‘Registered’, which can be defined in the Set field as follows:
status = registered
Update 5
The fifth action needs to update the status of the workflow, which was set to ‘Progress Halted’ after the test task had failed. To indicate that the workflow needs to be updated, simply specify workflow in the Update field.
Set
To ensure that the fifth action sets the status of the workflow back to ‘Implementation’, the following needs to be specified in the Set field:
status = implementation
Demo Data
This example can be found in the ‘Information Technology – Widget Data Center’ account of the Xurrent demo data. It is included in the workflow template ‘Non-standard application change’. To review this example, log into your Xurrent demo instance at Xurrent-demo.com by entering the name and password of the instance. Once you have accessed your instance, select the Xurrent account ‘Information Technology – Widget Data Center’. Next, log in as Grace Weller (email address: grace.weller@widget.com and password: Xurrent). When you are logged in as Grace, you can open the workflow template in the Records console.