What is the best practice for Selector?


I’m suffering with the performance and accuracy of UI Element Selector. When I’m doing unit testing or run modular by modular, the automation is running fine which under acceptable level. However, when I put every piece together and run, it is either slow performance which take longer time to find an UI Element or just cannot find the UI Element which is showing there.

So would like to know what’s the best practice to configure the selector in terms of performance and accuracy. When using UI Explore to indicate an element especially for web page element, it returns lots of attributes, should we keep as little as attributes for better performance?

Or are there any other properties can help to improve the efficiency, for example delay after/before?

Looking for some experience sharing? Thank you.

  1. UIExplorer is the best way to tune the selectors.

  2. Using Simulate Clicks in the properties panel, the performance will be faster because of background working functionality.

  3. Setting the Wait for Ready to None in the properties panel of click activities which will show you a significant improvement in the Clicks.

  4. Setting minimum required attributes which uniquely identifies the elements improves the *performance.

  5. Instead of clicks, try to use keyboard shortcuts.

Karthik Byggari


Please see after every click activity use uiexplorer in that window u can find selectors like aaname .Please take it as selector if it is dynamically changing please take rows nd columns.

Shaik Azmal


Thanks for sharing and it really makes sense for the performance.

In regarding to the accuracy, I have a particular question the selector which I configured works fine most of time, let’s say 2 out 10 times it will fail. Since it works fine 80% of time, so you cannot say the selector is wrong, but if it is correct why is not 100% working? (The testing senarios is exactly same, I just try to run it as many times as possible, so there shouldn’t be any issue caused by dynamic items)

Interesting issue and want to know the factors, so the accuracy of automation can be improved instead of catch exception and re-do it again.

Hi @sgchris !

I am doing research on selectors just as a refresher, and to see if there is any new revelations and it does seem that there isn’t a lot of information floating around, so you’re the lucky customer that gets the experience and knowledge I have accumulated over the last couple years, dropped into your thread. I just think it’s a good place to put it because I am a HUGE fan of the term ‘Best Practice’ and I think that selectors Best Practices are still coming together, so here’s what I know works:

Let’s start here and I think it will illuminate why there is such sparse information about the subject: Asking how to get a really good selector, is like asking the internet what to get your girlfriend or boyfriend as an anniversary gift. Everyone is different, so you have to be a little investigative in your choices and understand that it’s not a perfect science, picking a selector but you can get a good sense of what works by looking at the site holistically and trying to get a sense of the Web Developers architecture. I’ll go into how to get a click 100% of the time shortly, but let me explain the genealogy of a selector.

When you develop a website, you have the same freedom that someone developing an RPA has. You have multiple ways to get to the same place and so you have a variety of ways that a website can be built, and you have the freedom to name your parts and pieces and areas and buttons as you please, but a good selector digs deep into the descriptors or directions. You’re giving your RPA step by step directions on what to find and click in that confusing code that makes up that site, including what you want to click. Let’s say in hierarchy order, Application; website; body or title etc; css table or chart or area; element of that table; button named ‘Submit’. That’s a great selector because it goes all the way to where you are going from where you are starting with a full map of what’s going on.

Best case scenario you don’t ever want to have to use a click, so if you MUST, then it better work all the time. It can be the single point of failure that makes an RPA that’s otherwise perfect, into something you don’t feel confident will work for years to come without you babysitting. You should be able to confidently walk away from an RPA you’ve developed and know it can handle you being gone. I’ve gone so far as to learn VBA so I can manipulate VB objects in an Excel file just to avoid using a click, because they are like OCR. Near perfect, but it can geek out sometimes.

The BEST way to get your mouse to click on what you want and to avoid ever missing a click is to use checks and balances to that click. Selectors are by no means, the be-all end-all so you DEFINITELY want to use an anchor for what you are clicking if it’s possible. It’s like pointing in the general direction of the click in addition to the directions you give with the selector. It’s like looking where you are going to throw. You can even give it a hint that the Anchor is to the left or right of what you want it to look for. You’ll have much more success with this working with your click.

You can and really should also include backups, so after you tell it to click, tell that click activity to continue on error, and after that you can have an “If” activity that checks to see if an image exists; the image of the button that was supposed to be clicked!! If it does exist, and your click failed it’s 1 job, then throw in another click, or even a parallel ‘click image’ with the click that has selectors to set UiPath in a race to click the image first. This may sound a bit like overkill BUT, RPA is about eliminating error, and if your RPA is experiencing errors, you’re doing it wrong so I commend you on not being satisfied with 80% and looking for better. You really do want 100%.

Remember that you can also use keystrokes, like Tabbing 20 times in a row to get where you want is definitely ok, but again, if someone adds a field and ruins that tab count, it will fail. So it is ok to use clicks, and you’ll learn as you use them what selectors are good, and ALWAYS use multiple angles and checks and re-checks when you are using clicks. There is no harm in checking to see if the button you wanted to click, got clicked, and if it didn’t, trying another angle.

Deep diving selectors, Anchors, If Image Exists with a Click image to follow and Parallel activities racing each other to that click are things that you have in your toolkit to make clicking a button in UiPath, reliable.

I hope this helps!!


Hi @CodeForgePro

Thank you for an in-depth post. It seems you love writing :slight_smile:

I thought you might be interested in our new Blog then, check it out here:

And here is an article about the way you can actually contribute :slight_smile:



Detailed thread on the best practice, Comprehensive and valuable for handing the UiAutomation in multiple aspects. :clap::clap::clap:. Thanks for sharing.


Thanks so much for the kudos, and the community is always welcome. I will definitely take a look at both the links and would be very interested in contributing! Thanks again!

@ranjith !! Ty!! and welcome!!