Hi,
I’ve been debugging an issue we’ve run into where an automation stopped working because the URL(s) of the targeting system changed.
It seems to me that the Use Application activity will try finding its target using the activity’s URL value before the selector.
In our case, we’ve used wildcard ‘*’ to match the URL partially - each URL contains a unique id followed by the actions. The supplier has changed some of the sites such that same same URL-prefix now appears across different tabs and now some of our automations has broke.
Our selectors are setup to match on title name and not the URL address. I’m a bit confused about this behaviour and the docs don’t seem to clarify it. I would expect the selector to be used in all cases and the url only used, in case the activity has to open the browser. Has anyone had the same issue?
If the application is not already open, UiPath uses the URL to launch it.
If the application is open, UiPath first tries to match the URL of an existing tab/window before applying the selector. I think this is why your wildcard URL (*) is influencing which tab gets picked. If multiple tabs match the wildcard, UiPath may attach to the wrong one even if your selector is correct.
Your wildcard URL matches more than one tab because of that bot attaches to the first match, ignoring the selector because the URL match happens earlier in the attach logic.
So to clear the confusion, URL is used first to find the application instance (tab/window), then selector is applied within that context
I think use application prioritizes url over selector, causing tab conflicts when URLs share prefixes. Try this might be your issue will resolve…
Try to avoid wildcards in urL, rely on stable selectors like title or element attributes. use attach browser with strict selectors for better tab targeting. ensure each tab has a unique identifier in the selector to prevent mismatches.
Do you also find this behaviour to be confusing? I would have gussed that UiPath only relied on the selector to select the application/website to work with, falling back to opening the url if the website is not available.
It could feel confusing but this is the way because until and unless bot get the object of the browser instance (by using Use Application/Browser activity), bot cannot check the selectors or interact with it.
new application / initial start: Open it using the URL value.
As soon as you automation has an existing browser, regardless of content, use the selector (strict preferably). Leave the url parameter of the scope empty, and set ‘open’ to ‘Never’. The URL parameter is then redundant and no longer mandatory.
Now the selector is the only target used. Inside the selector you of course have the diffentent properties you can choose to target, so if you want title match on title, and not url in the selector, though the latter is still possible.
A better way is to open it using the URL, and output the object to a UI variable. Then in subsequent Use App activities, set the input object with the variable.
Agree. The only downside I have with the object method, is that local testing and validating selectors becomes rather annoying. I you automate anything where selectors can become complex it’s a reason for me to not use it.
I was thinking the same thing. Its often useful to run the automation mid-way, which isn’t possible when relying on the object method. I’m not sure whether I like leaving the url empty. It provides a sort of documentation for where on the website the automation is taking place.
For now, I’ve opted for a middle ground: I replace the GUID in the URL with a ‘-’ (could be any token that won’t appear naturally but I think a dash is fitting). Its easy to setup, the url is still shown and it won’t ever match an open tab.
I still wish the URL-first matching behaviour was better documented, as I personally find it a bit unintuative.
If URL visibility on the activity is a desire, you can of course also put it in an annotation, so to be sure it does not interfere with functionalities.