How are you deploying the package to the Productions.?
Are you copying the ‘.nugpk’ file of your project that you published in local to your production environment.? If yes then i believe you are moving those to ‘ProgramData/UiPath/Packages’ from where your System Tray UiRobot comes to know that there is a package available to run (Only if not connected to orchestrator).
In this case, You have to click on the Download Icon available next to the Project Name under UiRobot popop(for every new version published for your project). Once You download, Your project is actually downloaded under the path where UiPath is Installed ‘…\UiPath\Projects’. If you open the folder of your project there, you find your project files under ‘…\lib\net45’. Your config.xlsx file should be available here as well from where you can change your password. After changing your password in config.xlsx from here and then running the workflow from the system tray again, it will always take the updated password from the config.xlsx file.
However i believe this won’t be a feasible way to deal with a process in production. Few problems that i see here,
- In future if you have a new ‘.nugpk’ published version of your project copied to the production, UiRobot will request for download from system tray and will create a new folder under ‘UiPath\Projects’. Your previous folder under which you made changes to config.xlsx file will never be consider, although it would still be present.
- In my opinion every change in the production should be tracked. By making changes directly to the config.xlsx file in production, you would just miss the tracking and changes you are making to your project.
The best way to deal with this is by using orchestrator and storing your passwords under assets. If you don’t have orchestrator then until then i believe it should be better to publish your project everytime instead of making changes directly. Again it depends on how frequent the password of the application changes & how frequent job runs. Since it looks like a Front Office Bot, Check for the possibility if its feasible to request for the password from the agent running the workflow using an input dialog or something else.
That’s my opinion and it may differ based on experiences from other people who may have more experience in dealing with production bots Again, the behavior i mentioned is all related to Community Edition, not sure if the behavior would differ much for enterprise solutions.