Advice on gracefully handling Login to Web applications which may "auto login"

I am looking for advice on what strategy to use to handle Login Sequences for Web Applications that may auto log in or “remain logged in after the application is closed”.


  1. When I go to a web application, such as, and I expect to be in one of three states:
    a. A login screen
    b. The Dashboard, because I am still logged in from the last time I used the application.
    c. Some other screen that is neither login nor dashboard (Maybe a 404, or a site maintenance screen, or what ever!)

I would like my login sequence to ask, “are either of these two unique elements in the web page?” If one of them is on the page, tell me which element. If neither are on the page, wait timeout milliseconds for them to appear, and if after that amount of time, neither are on the page, timeout.

I can easily write a sequence that checks for the first element, then checks for the second element, and then performs my logic. BUT, the first element exists has a time out of 30 seconds, and the second element exists has a time out of 30 seconds making this process slow, slow, slow! Even if I get one of the expected screens/elements it would still take 30 seconds. That is really bad.

Any advice?

I can easily image taking the Element Exists code from the UiPath Element Exists activity and modifying it to take an array of elements (really thinking Selectors, but idea is the same) and doing exactly what I want while creating a new activity for everyone. But I don’t think the UiPath activity code is public :frowning:

You could use parallel activities to have it check both at the same time. No way to get around the timeout though. Perhaps you could lower the time it is checking for the element? If it isn’t there after ~5 seconds I’d imagine it wouldn’t ever be showing up


Great suggestion. Did not know about the Parallel Activity.

Couple of quick questions:

  1. There is no documentation in the activities guide. There are forum posts about it, but, nothing in the official documentation. What is the best source of documentation?

  2. When I find Parallel in the Activities pane of Studio, I can right click and select Help. This takes me to the Microsoft System.Activities.Statements.Parallel Class documentation on Looks like the right stuff (Has the same CompleteCondition member). The description tells me that the parallel branches are not run on separate threads, but rather, it sounds like a round-robin scheduler where the parallel activities need to either complete or go idle for the next activity to run. Is this namespace the underpinning of UiPath robots?

  3. In the UI Automation documentation on the UiPath Documentation site it specifically says:

Does that mean “Element Exists” activities are NOT going to work, or just might not work, or might work, but wonky and unpredictable?

I will test it tonight anyway. Who knows, it might work :slight_smile:

@mjdeale You are right that the documentation from microsoft is correct; information on activities in uipath isn’t always documented very well (or at all).

I wasn’t thinking about how it actually processes it. Anything in the parallel activity is processed left to right, so top left, then top right, then second-from-top left, etc. So it wouldn’t actually speed up the processes.

However, I think my other comment of reducing the Timeout time is still valid. No need to wait 30 seconds to check for an element in 99%+ of circumstances. You can likely reduce that to 2-5 seconds which would significantly speed it up


I perform this pretty much for all applications.

Essentially, you will need a selector that identifies the application is logged in already, meaning that it is on any page within the application. Then, you should have a Login script (.xaml or Library) which the first thing it does is check this selector with Element Exists.

But, there is more. You may also need to check if the login page is already opened so it doesn’t need to reopen the application. So, then, you would do a second check to see if it is on the Login page, then peform the login steps, followed by a check to see if it finds an Invalid password element (Throw a BusinessRuleException if so), followed by a check to see if it gets to the next page.

If it gets through all the checks, then Log a message saying “application is loaded”, but only if logging in. This way, the log message only appears when a log in attempt was made.

Basically, you want to make it so if the Login script is called and the page is already loaded, it does nothing and only takes half a sec.

I don’t believe you really need to use Parallel for this, cause you want to make sequential checks to see what state you are in. You could possibly use the Pick Branch though. But, for my stuff, I just do it in sequence:
—Check if any page on the application is open
—If not, Open Application, else check if it is on the Login page.
—Outside of that, if it is on Login page, perform login. If not on Login page, check again if it is on any page
—After login performed, check for invalid credentials or expired and throw exceptions accordingly. Check if main page is loaded. If not, Throw Application Exception
—Outside the login part at very end, If main page was already loaded, then just Attach to the Window to output a window argument (only if desired)

Hopefully that doesn’t sound confusing :laughing:


1 Like

@ClaytonM All that makes sense, believe it or not :wink:

@Dave I totally buy the 30 seconds -> 5 seconds change on the timeout. Interestingly, I have LastPass, in IE, on a windows 10 VM, running on my Macbook Pro. All that slows down the pages just enough that 2-3 seconds is touch and go on a timeout. I blame it on my latency from my Verizon internet connection.

I have even thought about the need to check to make sure that if we are already logged in, we are logged in as the right user.

Bottom line is there is no way to avoid paying the penalty of waiting on the Element Exists timeout on paths in after the main/most likely. If I design and order the element exists checks into the “most likely to occur” we can minimize the time cost. If we normally leave the application up, and logged in, we should check that condition first. If we normally logout and close the application, we should check that condition first.

Short Element Exists timeouts are ok (assuming they work 99% of the time), because we can always have the application retry the transaction using the automated Retry.

Clayton, I am going to shamelessly steal your login algorithm as my standard.

Thanks for the guidance.

– M

You can speed it up also by changing the Timeout to 0, when you are checking for something that should already be on the screen. For example, the first Element Exist should have a timeout of 0, cause you are checking if the page is already logged in.

Haha. I also forgot to say for the other scripts (.xamls) that interact with the application, you would need a similar approach to check if the page is in the correct state (since the login script only gets you to one place, but other interactions could land you in a different place). Then, navigate to the correct state/page if necessary before performing the actions for that particular task the .xaml is performing.

So ideally, you would have a .xaml that peforms a task, and in that task it calls the Login Library or .xaml first, which in turn should finish in half a sec if it has already logged in. Then, navigate you to correct page to start the task from there. This way, you can be as lazy as possible, and no set up steps are necessary to run your task.

You would still want to use your Login .xaml or Library though at some Init state so it can check the Login so it can exit the process. Otherwise, you could potentially attempt an invalid login multiple times in a row.

So, that’s kind of my thought process on that. :smiley:

1 Like