Hi bsikes

When the fallback is raised (window or object not found or window blocked, etc), you would see such a message when running it in debug mode in the studio. 

You can also write the fallback failure to the log by using the AC “log an action” to the console - but you’d have to insert the error variable there.

In my training sessions we speak about various fallback options, such as “go to step” in case there’s a popup or something the robot needs to deal with.

You’d have to record those popups and set them as fallbacks. 

How are you using fallbacks? Have you tried debugging in Studio and added the “view variable” list to see the exact error?

Hope this helps a bit.

Hi @gobitz 

My expectation was that if the fallback option was set to “Raise error”, that when an object would fail to be detected, it would pop up with the window that shows what it was trying to find. I believe it also usually allows you to retry the step, or go to a different step manually. 

The issues that we’re seeing, aren’t ones that come up when running in Studio or developing the wizard originally. So that box is helpful to see the problem so that we know what to fix, but also to get the wizard back on track without needing to restart it. 

We’ve got a lot of different fallback options used throughout our Wizards, I just assumed that the behavior of “Raise Error” was different then it seems to be. Or at least, “Raise Error” behaves differently between launching it via the “Do it” option and through the API, which I didn’t expect. 

Have you tried using the automation template?

I don’t believe so - We’re making all of our Wizards from scratch, or copying from existing Wizards that we’ve made from scratch. 

If you would like, I can share the template with you / set up a session so you can understand how to work with it and see all error handling in a csv file (automatically created). 

@gobitz So… I knew this sounded familiar, and I found an older forum post about this topic here: 

I attempted to import the Kryon_Library_Base_Templates_21.10_and_later.dwiz template, and it imported with no issues!… however, I’m now unable to expand the library I attempted to import them into, meaning a lot of our wizards, including the ones I just imported, are not accessible.  I presume that if I delete the wizards i just imported, we’ll be able to access the library again. Unfortunately, I don’t know how to delete the wizards, since I can’t access the library. Any suggestions?

I’m making a support case regarding this, as I can’t find a way to access our wizards in the library we imported the template into. 

@gobitz  Hoping to verify something - If RPA can’t determine which window to use, because there’s multiple windows that meet the criteria, is there any fallback that can be used for this?  

In my situation, a web browser is being utilized. My hope was to have a fallback that would simply close all Microsoft Edge sessions, then go back to the step that would get to the correct page. However, it doesn’t seem that this fall back is being triggered - the workflow just fails without any reason in the debug trace. 

I assume steps could be put in place before the action to look for the window and take action if multiple are present, but that would be a bit tedious to do for every action that targets a window. 

Thanks!

Hi @bsikes 

You are right: fallbacks need a window (url) or screen + object (in case there’s a visual recorded click). So if your window data is very generic (contains instead of “equals”) then the fallback mechanism won’t help. 
 

run your wizard in debug mode in studio to see if the fallback works.

Maybe one option is to duplicate steps and then be stricter in your window data settings. The fallback can then be set as “go to step”. 
 

another option could be to use embedded wizards and when window and/or object aren’t found, end the embedded wizard. 
 

Btw: you can use powershell (run script) to kill the browser in the advanced command for a successful fallback. 
 

Hope this helps. 
 

@gobitz The powershell command is what I’m already doing to kill the browser - it just doesn’t trigger since it doesn’t actually count as a fall back. Unfortunately, being more specific won’t help, because the windows truly are duplicates of each other. 

I did test it with two windows being open - While running from Studio or a bot in “Do It” mode, it will ask which window is being targeted. Unfortunately if running via the Console or the API, the Wizard just fails, and I don’t think I have an ideal way around that scenario, since none of the fallbacks apply.