Having trouble with the video? Try this link.

You can use the Goto Backward hop to automatically send a workflow back to a step based on the conditions in the workflow.

For example, let’s say you are using the content request app. In the workflow, an editor may want a writer to redo an article, but if they send it back as a clarification, it won’t get proofread again.

Instead, you can put in a Goto right after the editor’s approval. We can add a yes/no field to ask if the content needs to be reworked. If the answer is yes, the Goto will send it back up the workflow and it will have to go through all the same steps it did before.

A Backward hop is the only way to implement looping iterations of your items. The Goto backward can work with sequential tasks, from within a parallel branch, or from inside a parallel branch back to any earlier parent task. Anytime you add a Goto, it will display a list of all the possible steps you can send the task forward or backward.

If you set a Goto to go back to a parent or earlier sequential task, all of the tasks will be done again, including those in other parallel branches.

Here’s what it looks like in the form. In this case, the editor has chosen to send the article back to the writer. The item shows in the writer’s task list again. You can see that the progress bar will document that a Goto has been triggered. After the writer has finished, it will go through the same proofreading and other tasks before it reaches the editor again. The editor will need to switch the field back to "no" to stop this loop.