Return the task to previous

is it possible to return the task to a previous one in the process? Example is in task 2 but wanted to go back to task 1

example

Hi Marcelo, yes, you can modify the process instance to move the ‘token’ from one spot in the process to any other spot in the process using Camunda’s REST APIs for process instance modification. For more information have a look at https://docs.camunda.org/manual/latest/reference/rest/process-instance/post-modification/

More information regarding process modification using Java APIs https://docs.camunda.org/manual/latest/user-guide/process-engine/process-instance-modification/

But you should be careful when modifying process instances as it can lead to unexpected behavior. Whenever possible, model processes to account for re-work and transitions.

Joe

2 Likes

@MarceloCP what’s your usecase for moving backwards to the completed task? Can you elaborate more on why you wanted to move from task 2 to task 1?

thanks, it worked perfectly

Usually, the initiator (node 1) fills in the application form, which is approved by “node 2” and “node 3”, and then arrives at “node 4”. Suddenly, it is found that there is an error in filling in one item, which needs to be “returned” to “1”, so that “1” can modify the content of the form before submitting it

Hello, how to use API to return, can you give an instance of API request, thank you

This is very helpful and it worked for me too.

I have posted a similar thread in the forum but then I saw this. I just wanted to link that thread here too to help others.

In terms of BPM, shouldnt you describe this rework scenario in your bpmn process? as you said, you need to go back and do some work AGAIN just because someone filled incorrect data.

I think the best way to do it is to really have an Exclusive gateway with a flow pointing back to the user task you want to go again.

Because theres no real way to go Back in a process, theres no way to get back what you’ve wasted in terms of time and resources. You are always creating new jobs/tasks and if you are creating a new task to do the same job again, it should be pointed as a REWORK (Rework - BPM Glossary) in your process, so you can get some data insight about how much effort you are wasting with incorrect data and maybe improve the input data process to do it right in the first time or even change the order of your approval nodes to get the error faster wasting less effort from the other nodes.

Thank you for your reply.
But you said that it is unrealistic to use the form of gateway to realize the return operation.
If there are 10 user task nodes and each task node is required to have the right to return, the flow chart will be very complex according to your statement.
In addition, if the flow chart contains other types of conditional gateways in addition to the return conditional gateway, the complexity of this flow chart is unimaginable, and the workload is particularly large. This method you said is not a solution to the problem

In addition, for the approval task node, the node itself should have the right to refuse approval. As you said, the approver can only perform the consent operation, which is obviously unreasonable. In addition, the return operation is not only returned to the start node, but can be returned to any previous approval node. For example, if there are ten previous approval nodes, Then, according to your meaning, you need to make 10 return gateways, and the previous nodes can return, that is, 9. The number of return gateways = 10 + 9 + 8 +…

Well, you could use Link elements too if you prefer ir, to have fewer lines in your bpmns. Or maybe the instance modification is really the right choice if its feeling nice as it is.
I just dont like to use it as a common path in my processes. Its a piece of process flow that will be hidden. No one will look to your process and knows that the task can go back etc…I often use the instance modification API only to fix some technical problem or something, but not as part of my business process. But i guess it goes with the pattern you follow in your projects, hehe.

Other thing id like to warn you about is to keep your Screen flow decoupled of your Process flow. Maybe you have Back buttons on your screens and you are thinking of it as one user task to each screen (ive seen it already in some projects). Dont know if its your scenario, but if it is, your screen flow should have as many screens needed to complete a single user task… I like to keep this screen flow logic in our BFFs (backend for frontend) and only complete the user task when this BFF has collected all the data. This way you can add multiple channels (web, mobile, chatbots, etc) with different screen flow for the same user task.

Im sorry if im talking too much about it and its different from what you need. Just wanted to share some tips about the problems i had and the ways we do it know

Thank you for your reply.
According to your method, I tried. There is no problem with the others, but one problem is how to return to the start node

Hmm, why do you need to execute start event again? in truth you arent starting a process again…if someday you count the start event executions you would have a wrong number if you could do that.

If you have something executing in java at start event, maybe you could do it in a first Service Task with a java delegate or script, and this will even be more readable when someone see your diagram

if you have many tasks that could go back to any one of them, maybe you could have a single Exclusive gateway to connect them. Lets say every user task could end with a result variable with value BACK and another variable that says the specific task that they want to go back to. So you make your task go to this exclusive gateway and this uses the variable in a expression to decide for wich task it will go back.

This way you dont need to have all of the tasks point to every other, and still has your diagram showing that anyone of them could go to anyother.

You could even use a Link Event to go to this gateway. This way you dont have many lines overlaping each other