As an RPA developer, I am always striving to get the most out of RPA tools. For the past eight months, I have been developing RPA processes using UiPath, and I have been pleased with the power and range of activities it offers. One UiPath activity that has shown itself to be very effective and yet underutilized is the Parallel activity. The Parallel activity has helped me resolve multiple challenges with RPA development, from performance tuning to reducing code duplication. This blog will walk UiPath users through the Parallel activity and its functionality. Hopefully, the information below will help RPA developers gain a deeper understanding of UiPath and build more robust bots.

Overview of the Parallel Activity

The Parallel activity in UiPath does exactly what it sounds like. It allows you to run multiple sequences in parallel with each other. Additionally, you can set a condition that, when true, will terminate all threads immediately.

This can be useful in multiple situations, including:

• You have a large volume of data to process, as well as a long sequence of UI interactions that need to happen, but the data is not needed until after those interactions are complete
• You are watching for multiple different elements in the User Interface (UI) and need to take a path based on which elements appear
• You are watching for elements in the UI that may or may not show up
• You use a command that produces a result normally requiring manual intervention before it can resolve

Useful Situations

Here are a few of the specific situations where I have found Parallel to be a useful approach.

Chrome Pop-Ups

It is common practice in RPA to run a task kill command at the start of any bot run to ensure the environment is clean. With Chrome, this has the unfortunate side-effect of causing the “Restore pages?” pop-up to appear.

Restore Pages Pop-Up

Another common one from Chrome you can typically expect is the save password pop-up.

Save Password Pop-Up

Unfortunately, this pop-up cannot simply be ignored. If there is anything on the screen the bot needs to be able to access, this pop-up will cause the command to fail. Additionally, you cannot assume it will always appear (especially with the save password pop-up). This means you need to use a Check App State command to see if it is there or not, which typically takes five seconds.

This is where Parallel comes in. My typical approach when I know this is a possibility is to use a Parallel block with two Check App State commands. The first is to watch for and handle the Save Password pop-up. The second is to validate the login was successful.

Example: Parallel to handle Save Passwords Pop-Up

Multiple Flow Entry Points

One common issue I had to deal with often was steps in a flow that may or may not occur. This was especially common with SAP. When logging in, there are at least two possible windows that could appear before the success confirmation (one for multiple logged in sessions, the other for a count of failed password attempts). Without Parallel, this requires one of two approaches. The first is to watch for each window sequentially, costing about 10 seconds per completely successful login. The second is to check for the success page first. This would take only 5 – 10 seconds for a completely successful login, but almost always results in code duplication since you must check for a login success twice.

Using a Parallel task, it is possible to remove all the wait time and the code replication. In the SAP example above, you would have three threads watching for different screens.

Multiple Outcomes of a Single Operation

Normally, when I implement a UI operation, I will use UiPath’s built-in validation to ensure the operation is completed successfully. However, in a process I recently developed for a client, several of the button clicks would result in two possible outcomes. This means I cannot use the built-in validation since I can only look for one possible outcome.

The way I would handle this when I was using tools without Parallel was to check for the case I was expecting, followed by the less likely case. Since there were two different places this would happen for each record in this process, there would be at least 5 seconds per record lost if I took this approach. However, using Parallel, I was able to watch for both conditions simultaneously and avoid the bulk of the lost time.

Authorizing GSuite API Calls

Ideally, when using the GSuite API, no manual authorization should be required to execute the API. However, if you find yourself in that position, you can use the Parallel activity as a work-around.

The complication here comes from the fact that the bot will not move past the API call command until it either receives approval, or it times out, meaning the bot cannot click on the authorization prompts. However, if you use parallel, you can split it into two threads. The first thread will make the API call, while the second will watch for the GSuite authorization prompts. This will allow the bot to authorize the API call without help from the user.

Things to Watch Out For

Parallel is an extremely powerful command in UiPath. However, there are a few things you need to keep in mind when using it.

Terminating Threads Can Cause Issues

One extremely useful feature of the Parallel activity is the ability to include a condition to terminate all the threads immediately. However, there are some commands that will throw an exception that does not appear to be catchable within UiPath.

Exception thrown by ending threads

Multiple UI Interaction Threads

This second issue is not something wrong with the activity. This is an issue with parallel processing in general. When you split a program across multiple threads, you must be careful about writing to the same thing at the same time. Normally, this would be memory. For RPA, this also means the application you are automating, the keyboard, and the mouse. All threads will execute independently of each other. This means if more than one thread is using the UI, you must make sure only one thread will access any given application at a time. In all our above examples, this was accomplished with Check App State commands. Since each thread was accessing the UI, but only to read it, there was no concern of thread safety.

The Parallel command in UiPath is an extremely powerful and versatile tool. If used properly, it can be a great way to increase the performance of your processes. The content above is in no way a comprehensive tutorial on the UiPath Parallel activity but is instead meant to help developers understand the feature at a high level in hopes they will explore the activity and use cases where it may be applied.