Mike:
I agree with the dedicated account/system supported by IT to run these solutions as opposed to under end user accounts. We are working through building out this framework for IT-supportable solutions right now.
It does seem clear that one unattended add-on is required "per bot" per environment. I'd take that to mean if you want two concurrent processes running within an environment, you'd require two unattended add-ons.
What is less clear is what the architecture is for concurrent RPA processes. A couple options come to mind but are not discussed anywhere in documentation:
1. Two separate machines to run concurrent processes under the same shared account. The "gateway" supports the configuration of a cluster and, it seems, the Unattended RPA machine needs to be the same machine as the gateway machine(s). Does this mean that RPA unattended flow will automatically and dynamically use one of the RPA gateway machines that is not currently running something with that user account? If not, can we "target" a particular machine and just have to manage the scheduling of runs not to conflict/collide on each other? Ultimately, a cluster/pool of machines would be a scalable approach.
2. Do we instead have multiple shared accounts (which would mean additional PA and RPA attended licensing as it's "per user") and, then, a single RPA machine (running Server OS) could handle two concurrent logons/sessions. Again, with two processes running on a single server, we'd still need two unattended add-ons for the environment.
Note: This type of architecture information seems to be absent on Microsoft's site. If it exists, please point me to it.
