Moving back a workflow instance

Applies to version: 2020.1.x and above; author: Franciszek Sakławski

There are situations in which, after going through a path, you will need to go back to one of the previous steps of the workflow e.g. when the form has been incorrectly completed or you forgot to add an attachment to the instance.

The article describes two basic configuration methods:

1. Moving back an instance to the defined step
2. Moving back an instance to the previous step using the “Back to the previous step” predefined option.

Moving back the instance to the defined step

A simple workflow consisting of four steps was created:

• Registration
• Approval 1
• Approval 2
• Final step (positive)

At the “Approval 2” step, a path was defined that moves back the instance to the “Registration” step. When configuring the “Back to registration” path, assign the task to a person who registered the instance – by using the “Assign to the author” option.

Next, go to the Portal and check if this option works correctly. The instance is in the “Approval 2” step – click the “Back to registration” button.

The instance moved back to the “Registration” step and the task was assigned to the author to complete information on the form.

Moving back the instance by using the “Back to the previous step” predefined option

The action allows you to move back the instance to the previous step.

The simple workflow consisting of four steps was created:

• Registration
• Approval
• Final step (positive)
• Consultation

On the path going through the “Consultation” step, there is a black arrow pointing in the opposite direction to the direction of the path. It means that at a given step a path moves back the workflow to the previous step has been defined.

Two actions can be used to configure the path:

• Assign to users who completed tasks in previous step – a system will automatically recognize who completed the task in the previous step and reassign them to those people
• Assign to users who obtained tasks in previous step – a system assigns the task to the same people who had the active task in the previous step

Be careful when using the predefined task assignment. If you want to move back the workflow to the “Registration” step with such an assignment, then the system will not be able to assign the task, because at this step the task has not been created and completed before. So you need to select the “Assign to the author” option or another method of assigning tasks e.g. using a business rule, dynamic task assignment, or using the “Create a task” option.

Next, go to the Portal and check if this option works correctly. On the “Approval” step go through to the “Consultation” step.

The instance is waiting in the “Consultation” step, after clicking the “Reply” button the instance will be moved back to the “Approve” step.

The above examples are the basic methods of moving back to the instance. However, using more advanced types of configuration e.g. using the system step where, on the appropriate condition, the instance moves back to the defined step – you can create intricate combinations specifically tailored to your scenario.

When creating the workflow, you need remember what actions you configured, and keep in mind what ramifications repeating these actions would have. For some actions, executing them again once the workflow instances passes through the trigger one more time will make perfect sense – for others, it will not (e.g. an action that is meant to be triggered once per workflow, regardless of what steps it goes through). When configuring paths that allow you to navigate workflow instances to previous steps, consider the following options:

• Set additional execution conditions on the action, depending on whether the workflow was moved back. For example: use an action that sets the value of an invisible technical form field to “1” if one of the “move back” paths is used, then have execution conditions on other actions return “False” if the value of that technical field is “1”.
• Cancellation of related subworkflows
• Additional integration actions. If integration is used in the workflow (e.g. SAP entry, update, cancellation)