Have a few comments on this point. Sometimes less is more. Keep it simple and organized. Don’t create a Labyrinth of workflows, where you invoke a workflow and invoke a workflow in that one and so on, unless it is necessary.
Keep re-usability in mind. Many clients and company RPA infrastructures fail at this point. Typically and potentially, systems/applications will be performed in from multiple projects. In a perfectly groomed company RPA infrastructure, you would not actually need to develop any new components but rather just organize the process, nor should you have any issue releasing an update to those re-usable components when something changes with a system/application. - This can be challenging to get right though. I believe the move to Libraries will probably be a good answer.
Interacting with a system/application web or desktop should have a Login script and a workflow for each individual task that would be performed within the application, and the Login script should be developed in a way that can be invoked from each individual workflow task (ie logging in only if it needs to and attaching to the window). This allows you to simplify your logic by only invoking one workflow to perform the task and the sign on part is handled easily.
This ties in with last point, but create your workflows so no set up work is needed. Like you shouldn’t need to sign out or close out of systems and you shouldn’t need to close or move around files first for it to run. Less set up means you have to think less = better, lazier times EDIT: I wanted to clarify this point too. Like, if a system is already on a particular screen, it should attach to that screen and continue from there, instead of closing the window, opening it up again, and needing to log in, which I believe works but just doesn’t work as efficiently in the long run, compared to if it simply was able to attach to the existing window and skip many navigational steps.
Check for if a login was invalid, then throw a Business Rule Exception with a custom message. This is important, so you know why you received the failure, and a retry attempt will not be performed. Additionally, catch any invalid input data as Business Rule Exceptions, where a retry attempt will not resolve issue (like wrong column names for example if it requires a file from an end user) - this is not usually needed if the data is consistent or if the code can still read in the data given certain situations.
I have so much more to say, but I don’t want this to get too lengthy, haha.