Workflow not working on different machine

Hey Community,

I have a very strange issue. I have developed the bot for a desktop application. The bot is working perfectly fine on the machine on which it was developed.

I have copied the same project and deployed it on another machine. That machine has the same version of that desktop application. On that machine, some workflows are working, and some are throwing errors.

Any suggestions?

Hi,

Can you share what error occurs?

Basically, it’s better to have same OS settings such as resolution and scale etc. b/w development and production.

Regards,

Without seeing any errors only vague guesses can be suggested.

@Muhammad_Anas_Baloch

More questions, is it unattended or attended? What are the errors you are getting?

Hi @Muhammad_Anas_Baloch

This can happen even when the desktop application version is the same. I would check the following on the second machine:

  • Verify the same UiPath Studio/Robot version and required activity package versions.
  • Make sure all required dependencies/packages are restored correctly.
  • Check whether the application is running with the same user account and permissions.
  • Compare the application window/title, resolution, display scaling, and Windows settings between both machines.
  • If you’re using UI Automation, try Repair/Refresh the UI selectors and check whether the elements are being detected correctly on the second machine.
  • Also check whether any required files, folders, environment variables, certificates, drivers, or configuration values are machine-specific.

Since some workflows work and others fail, the error message from one of the failing workflows would be very useful. Could you share the exact error/stack trace and, if possible, a screenshot of the failing activity?

If you share those details, we can narrow down the root cause.

I ran into exactly this a while back and it almost always comes down to the second machine not being truly identical to the dev machine. Double-check that Studio/Robot and the activity package versions match on both, and that all dependencies restored cleanly after the copy. Display settings are another classic culprit — even a small difference in resolution or scaling can break UI selectors while the app version looks the same. If you just copied the project folder, also make sure nothing machine-specific (config files, environment variables, certificates) got left behind. And like the others said, posting the actual error from one of the failing workflows would help a lot.

Hey, it is a development machine. The errors are same, they are couldn’t find the element. After going to Edit target → no element found. When I reindicate and change from strict selector to fuzzy it starts working.

Hey, The errors are same, they are couldn’t find the element. After going to Edit target → no element found. When I reindicate and change from strict selector to fuzzy it starts working.

It’s an attended bot.

Hey, I have verified the application and studio both have the same version. There are no machine specific configs. The only problem I am facing is bot cannot find some selectors. it throws runtime exception that element couldn’t be found or no such element found.

Hiii @Muhammad_Anas_Baloch

Since the application and Studio versions are already the same, I would focus on the selector and UI environment rather than the project itself.

For an attended bot, please check:

  • Display resolution and Windows scaling are identical on both machines (100% vs 125% can sometimes affect UI interaction).
  • Re-indicate one of the failing elements and compare the generated selector attributes between the two machines.
  • If the selector contains dynamic attributes such as id, idx, aaname, or changing window titles, try removing or stabilizing those attributes.
  • Check whether the application is running with the same privilege level as UiPath (both normal or both Administrator).
  • Make sure the required UiPath extension/driver is installed and enabled if the application relies on browser/web components.
  • Try Use Application/Browser → Check App State or Element Exists to verify whether UiPath can detect the element before performing the action.
  • Since fuzzy matching works, you can compare the strict and fuzzy target properties to identify which selector attribute is changing.

Also, please share the exact activity/runtime error and, if possible, the selector from a failing activity (with any sensitive information removed). That would help narrow down the root cause.

Hi @Muhammad_Anas_Baloch ,

Same desktop application, ok.

Are you talking about applications or Studio + Orchestrator versions?

Can you share some screenshots related to the issues. Tobe able to help we will need to see somehting.

Thank you

@Muhammad_Anas_Baloch since re-indicating on the second machine works, the element itself is detectable there. The strict selector captured on the dev machine just contains an attribute whose value is different on that machine.

Open one of the failing targets in UI Explorer on the second machine and compare it attribute by attribute with the original selector. For desktop apps the usual suspects are:

  • cls on WinForms apps, e.g. WindowsForms10.EDIT.app.0.141b42a_r9_ad1. The part after app. can change between machines/.NET runtimes, so use cls='WindowsForms10.EDIT.app*'
  • the window title, if it includes a user name, environment or version
  • idx

Wildcard or parameterize that attribute and keep the strict selector, instead of relying only on fuzzy.

Its worth deducing the difference in selectors.

Use the Ui Explorer to investigate the element, then compare the attributes you use in the strict selector on one machine to the other.
There is most likely some difference, find that difference and you have your answer to knowing how to standardize it.
The fuzzy selector working shows they are similar but different.