Looping through a List in Automation Anywhere Process Composer

You can use task bot for looping in through the list and based on the list items, you can then call subtask bot depending on your requirement.

You can pass the value as an input variable to the subtask as well.

I don't see the need of Process Composer here. You can explain in more detail if I am missing something.

​@DS78 ​@LAHCEN AGLAGAL Correct, DS! You can perform some rudimentary looping using the Go To element within Process Composer, but Process Composer’s focus is really to direct the task bots, API tasks, forms, etc., and move data from one element to another. I recorded a video on this topic that should be live shortly.

​@DS78  ​@Aaron.Gleason  Thank you for the guidance.

However, I'm concerned about error handling. I need a way to manage retries. For example, if a child bot fails, I want to restart the entire parent process from the beginning.

My initial thought was to use a "GO TO" action, which I know doesn't exist in Task Bots.

You can still do that by using a flag - a Boolean variable tracking the status for your bot success or failure.

​@DS78 ​@Aaron.Gleason 
Thanks for your help. I'll try to come back to u

From what you've described, Task Bots are a better fit for iterating through a list than Process Composer. You can retrieve the list in the parent bot, use a Loop (For each item in the list) to process each element, and pass the current item as an input variable to a child bot if needed. This also makes error handling and retries much easier to manage within the Task Bot, while Process Composer can remain focused on orchestrating the overall workflow rather than performing item-by-item iteration.

​@jasonjohns533 The answer is “yes” and “no”. Task Bots and Processes perform different functions. Think of Task Bots as the “tools” and the Process as the “instructions on how to use the tools”. Task Bots will run without Processes -- that’s standard RPA. Processes won’t do much without a Task Bot, API Task, Form, or other elements. It can only move the flow of the Process and the data associated with it.

Where Processes really hit their stride is the ability to work with data “back in time”. For example, if we start a Process with a Task Bot who sets its output value to “ABC”, then the Process feeds “ABC” into another Task Bot which outputs “DEF”, inside the Process you still have access to the original output value (ABC) and the new output value (DEF). That’s something that would be difficult to do with standard RPA.

Being able to gather data from multiple tools at multiple execution points is one of the strengths of Processes.

Thinking of Task Bots as the workers and Processes as the orchestration layer makes the distinction much clearer. The ability for a Process to retain and reference outputs from multiple execution steps is especially valuable for complex workflows, approvals, and branching logic where maintaining context across the entire process is important. It also makes debugging and extending automations much easier than trying to manage everything within a single Task Bot

Processes handle things at the work item level.  Use a loop to pass work items into a process and allow an instance of the process to create and handle each work item.

It is much easier to see the difference when you think about Task Bots as the workers and Processes as the orchestration layer. For complicated workflows, approvals, and branching logic, when preserving context across the whole process is crucial, a process's capacity to store and refer to outputs from several execution phases is particularly beneficial. Additionally, it is far simpler to troubleshoot and expand automations than attempting to handle everything with a single Task Bot.