Asynchronous Activity - Handle Unexpected Popup Messages

Hi Team,

I am working on a RPA Automation with a windows application in which we get some error popup messages. Those popup messages are unexpected and it may appears in any of the process steps (unexpected). We just need to close when appears and proceed further activities as per the process. Please help us on this.

We tried with Parallel Process, however that is not closing when popup appears. Example, Bot tries to type a text in Type into activity but popup appears before the type into. But bot types the text before closing the popup and then it tries to close the popup. This is happening random basis. Sometimes it is closing the popup and typing the text and sometimes it is typing the text first and closing the popup.

Kindly help me on this.

Hi @baskarn
This is a tricky problem to solve. My initial suggestion would be to work with the owner of the application to understand more about when these pop ups do appear and see if there is anything that can be done to remove these or get a clear answer as to where and why they appear. This will give you a better basis for building your automation in the most effective way, without having unnecessary waits in your robot.
If they really are random, you could implement a component that could be invoked each time there is a system application to check if this pop up has occured, and if so, close it and go back to the failed activity to try again. Or implementing frequent “Element Exists” to check for the pop up, with a short timeout so as not to impact your automation too much.

I am happy to be corrected but I do not believe there is a perfect solution for this, and I would always discuss with the application owner to understand more about the pop ups before building in a number of workarounds into your robot.

I hope that helps!

Hi @baskarn ,

In most of the case parallel activity works, can you share the screenshot of that portion where you have handled this?

Hi Katharine, thank you for inputs. But this cant be resolved within the windows application, as the ERP Application is for across many regions. So those random popups are to be handled from RPA Bot End.

I agree for introducing Element Exist activity before and after each action, but the Business Process steps and logics are very huge in my project. Hence I could not implement this suggestion in my project.

Please guide if any other way we can handle it. This is become a show stopper in my project.

Hi @ermanoj3101 , Tried implementing parallel activity with Pick Branch activity. This is working some times working good and some times not. Since there are more than random popup to be handled and all containing different selectors. In Pega Robotic Studio, we have something called Asynchronous action which will handle any random popup asynchronously (i.e. automation will execute a particular popup module before and after each process step.). If we have anything similar activity in @UiPathMaster @uipath that would resolve our problem.

The whole problem, even when correctly implementing combinations of parallel, pick branch and things like ‘on element appear’ is that the different parallel workflows can’t communicate easily.

So your main workflow won’t ‘pause’ the typing into, it’s an activty once started to be considered fire and forget. The appeared popup might block the rest of the type into, due to the focus shift in the UI and/or fail the followup activity. Sometimes it might work, sometimes it won’t, due to unfortunate timing.

I’ve coincidently been puzzling with the same question just this week, and ‘during’ a good nights sleep (I often dream about these things, I’m a nerd, can’t help it :wink: ) I thought of a possible workaround like below:

If the popup appearance really is that unpredictable, you could try using a global error handler.

  • you build your regular ‘happy-flow’ not considering popups.
  • the appearance of the popup will cause a system exception, captured by the GEH
  • The GEH handles the popup, then uses the ‘result = ErrorAction.Retry’ or ‘ErrorActionContinue’ output to continue where it was, retrying the activity, or continuing the next, whichever is relevant for you. (This might differ for type into vs click activities for example, use what you need or differentiate based on the error source element if you want to micromanage the behaviour)

I haven’t built a prototype of it yet, so not sure if it’ll actually work. You could be my test-subject if you want!

You can also achieve the above with smaller try catch or retry activities per step. This will get very annoying to build around each step if retries need to be done specifically per step. But if a GEH is no option, that ‘might’ be a way out. (For example if you want to use this in a library solution, a library workflow does not support the GEH)

1 Like