🎯 UiPath Tutorial: Using the Pick Activity

[ManFrancko (Franck MONGO)]

Author : Franck MONGO. - Intelligent Process Automation Consultant
Using generative AI, I enhance RPA developers’ daily tasks with my tools, available at https://linktr.ee/ipacopilot

Introduction

In this tutorial, we will be exploring the Pick Activity in UiPath, a powerful tool that allows developers to handle multiple activities that are based on event triggers. We will delve into its properties, how to use it, and provide practical examples. We will also provide troubleshooting tips to help you resolve common issues that you might encounter when using the Pick Activity.

What is the Pick Activity

The Pick Activity in UiPath is an event-driven activity that waits for one or more specified activities to be triggered. It contains multiple branches, each with a trigger and an associated activity. When a trigger event occurs, the Pick Activity executes the associated activity and then stops listening for other events. This makes it a useful tool for handling multiple potential events in a workflow.

Properties of the Pick Activity

The Pick Activity has the following key properties:

• DisplayName: The name displayed for the activity in the Designer panel.
• Branches: The branches that contain the triggers and their associated activities. Each branch represents a possible event and the action to be taken when that event occurs.

Using the Pick Activity: A Step-by-Step Guide

Let’s now dive into a step-by-step guide on how to use the Pick Activity in UiPath Studio.

Here is a diagrammatic representation of how the Pick Activity works :

In the diagram above:

1. The Developer creates a Pick Activity in UiPath Studio.
2. The developer configures the properties of the Pick Activity, such as the Branches.
3. The Pick Activity waits for a trigger event from the UI elements.
4. When a trigger event occurs, the Pick Activity executes the associated activity.

Practical Examples of the Pick Activity

Here are some practical examples of how the Pick Activity can be used in UiPath:

• Monitoring Multiple UI Events: The Pick Activity can be used to monitor multiple UI events and execute specific actions based on the event that occurs first. For example, you can configure the Pick Activity to perform different actions depending on whether a button is clicked or a checkbox is checked on a web page.
• Handling Multiple File System Events: The Pick Activity can also be used to handle multiple file system events. For example, you can configure it to perform different actions depending on whether a file is created, modified, or deleted in a specific directory.

Diagrammatic Representation of Troubleshooting Tips for the Pick Activity

This diagram should always contain conditions. With regard to the most common types of error, we suggest the following resolution tips.

In the diagram above:

1. Start with the Pick Activity.
2. Check if the triggers in the Pick Activity are set up correctly. If not, correct the triggers.
3. Check the order of the branches in the Pick Activity. If it’s not correct, correct the order of the branches.
4. If the Pick Activity is not working as expected, adjust the timeout period or the properties of the individual activities within the branches.
5. Handle exceptions within the Pick Activity to prevent the entire workflow from stopping when an error occurs

Conclusion

The Pick Activity is a powerful tool in UiPath that allows developers to handle multiple potential events in a workflow. By understanding its properties and how to use it effectively, you can create more robust and flexible automations. Happy automating !

Author : Franck MONGO. - Intelligent Process Automation Consultant
Using generative AI, I enhance RPA developers’ daily tasks with my tools, available at https://linktr.ee/ipacopilot

[mateuszmacheta]

I’m sorry, but I don’t think order of pick branches is key, but it helps if the most frequently expected triggers are placed closest to the left.
In order words - if you have different order it won’t behave differently, rather may give you slightly different execution time.

[efelantti]

Out of pure interest, investigated this a little bit In theory, the order should matter only if the running time of the branches is the same (or close enough?). After testing, it seems that order does matter, when the actions inside the triggers are not started in new threads (invoked as isolated workflows). In that case, interestingly the rightmost trigger seems to be started first.

Test scenario #1 (non-isolated invokes):

Result:

Test scenario #2 (isolated invokes): (note, here I allowed for some more iterations)

Result:

[mateuszmacheta]

Interesting post! However, I think your conclusion about rightmost trigger being checked first is wrong.
Try with different delays for Test scenario #1 and see if right still “wins”

[efelantti]

You are right, it does not seem to be that straightforward Tested it with some different values, with 100 iterations each. (Can’t bother to test with higher delay values than 30 seconds. )

Delay (milliseconds)	Leftmost	Middle	Rightmost
0	100	0	0
1	8	20	72
10	7	19	74
100	5	25	70
500	1	19	80
2000	6	18	76
5000	18	25	57
30 0000	9	7	84

However it does look like that rightmost is favoured, except when delay is set to 0.

[mateuszmacheta]

My explanation is that UiPath does the following when executing Pick activity: it goes to 1st branch and checks for trigger, if trigger did not fire then it proceeds to next one. It all repeats until it it reaches last branch, then it just goes back to the first one. You can even verify it visually when running in Debug mode and enabling Slow Step.
Now, I don’t know exactly how it’s working under the hood, but let’s imagine that in your case these checks took roughly 0.35 seconds. And also just wanted to note that your specific case for testing it not a typical one - we typically use pick branch where triggers do not “fire” simultaneously like you made it.
If one check takes 0.35 seconds, so after 1st branch is checked (and fails) we move on to 2nd branch at 0.35 seconds elapsed, after 2nd branch is checked (and fails) we move on to 3rd branch after 0.7 seconds are elapsed, and during execution of third branch (which would end roughly around 1.05 second if trigger would fail) 1 seconds finishes and trigger is fired.
I think maybe the time it takes for one check may be that long that making delay a whole number favors 3rd branch.

[Jeroen_van_Loon]

Correct, it’s not a fully synced parallel check for the triggers. UiPath rotates thorough them one by one. If this is from right to left or in sequence of creation (lets say you add branches on the left) I don’t know (or care tbh).

Another important effect of pick/pick branch is the result when ‘none’ of the triggers is fired. Depending on the type of trigger is can just follow one actions of the branches at random, depending on where it timed oud in its rotation of checking the triggers.

Example: if you are using classic design activities, you could have 3 ‘element exists’ triggers who each search for a specific UI element. Lets also say the timeout on all activities is the default 30 secs. If, after 30 secs, none of the elements appeared, a random* branch is followed and its action executed, since none of the element exists will throw an exception.

*(the branch the robot was inspecting serially when the timeout occurred)

[kevin.scott]

Just to check my understanding here, I could use a Pick activity if my use case is such that I know either one or another button will appear on a page, but I can’t predict which.

I can use the Pick activity to click whichever appears and proceed. Without a pick activity, I’d have to configure a click for one, put it in a Try/Catch, and in the Exception block, configure a click for the other.

The benefit to the Pick activity in this use case is I don’t have to wait for the first click to time out in the Try/Catch.

[mateuszmacheta]

Yes, you’re correct about benefits. Pick checks for either of element appearing and alternates between them, meaning that it reacts the fastest to either element appearing.

I think for typical approach I would use Check App State and not Try Catch, but regardless, I think you understand the essence of it.