Currently, the CA Service Desk Manager Classic Workflow is more or less sequential in operation. Many a times, it becomes a common requirement to restart the workflow task from the beginning in case it is rejected / disapproved at a mid point. The OOTB 'reject' function stops the workflow at that point and the change order does not progress any further. This forces the business to open a new Change Order (which means copy the same and possibly link the previous rejected one). This becomes unproductive in nature.
The request is to have the capability to restart the workflow task from the beginning in case a task is rejected in the mid-point - something that can be defined and triggered using the task behavior. So, a particular task in a workflow task template in a category can be configured for a status (like 'Reject') to trigger the behavior to 'Restart' from the first task (which is a common business practice as you have to go through the complete approval process in case of an approval rejection instead of cancelling the entire change order).
This can be done in a crude way using the 'Reopen' status but that is completely manual. Someone has to go to the individual task and edit it to change the status to 'Reopen' - every possibility of human error especially even if the task is completed, it still has the edit capability. The new capability can provide the mechanism to 'Reopen' the first task to restart the workflows again without manual intervention. That way the system can be configured to prevent accidental task 'Reopen'.
Additionally, the restart may also be done from the previous tasks or the one before. This enables to loop back to a point where a part of the task needs to be repeated or additional information is needed.
As an example:
Say there is a task list as below -
100 Input Data in CO form
200 Review Submitted CO
300 Manager Approval
400 Business Approval
500 CM Approval
600 Implement Change
700 Post Implementation Review
This functionality will enable to loop back to Task 100 from say Task 400 if Task 400 is Rejected. The workflow will start at Task 100 again and go through all the steps. Also, in cases, it can go from say Task 300 to Task 200 if more information is required or say from Task 600 to Task 400 if the implementation has to be rescheduled. In such situations, it saves the pain to close the current WF and open a fresh one.
I believe this will provide a very strong capability for the Classic Workflow which is pretty easy to configure and facilitates quick deployments and adoption. The concept can also be extended to Request/Incident/Problem.
I have added a sample workflow diagram that may be achieved using the capability described above.