Hi Alan,
Think of the RDS VBO as an equivalent of Login Agent for RDS environments, so the process to initiate the RDS connection, and the business process, are independent of each other and will be executed on different machines.
You will use the "Start RDP Session" action to log on a new user to the RDSH server, just as if you were using Login Agent to log in a virtual machine. The process which you used to execute that action can then finish while you wait for the user's sign in to complete (again, just like Login Agent). Once the user has signed in (and automate.exe has been started in their Windows session, using a script or Task Scheduler and the /resourcepc switch) then the new Windows session will show up as a runtime resource in the Control Room, just as if you had logged in a virtual machine, and it will then be available for you to kick off one or more business processes on it like usual. You can treat it just like any other digital worker, using processes and objects in the normal way that you would with them, you are not confined to the RDS VBO.
All that said, the "Launch with PID" action which you have called out is an exception to this. That action is meant to be used in business processes under very specific circumstances. It is intended to use where the normal Launch and Attach actions in an object cannot be used to correctly identify and attach to a target application for some reason (like, for example, you are running in an RDS environment, with lots of copies of an application running across different users, and you are unable to disambiguate them using the normal methods). In this situation, Launch with PID will start an application but also return the process ID of the started application - you can then use this process ID to attach reliably using the normal Attach stage of an object which has been designed to work with that target application.
"Launch with PID" should not be required under normal circumstances, and it is only included in the VBO in case it is handy for anyone. Under normal circumstances it should be possible to Launch and Attach as usual, the only possible tweak being to include the current user's user name in the parameters for the Attach stage to ensure that the object is attaching to the current user's version of the process and not any other user's. But other than that everything can be used exactly the same in an RDS digital worker as in a traditional VM-based digital worker.
I hope that answers your question?
