Running Multiple Instances of an RPA Bot Concurrently in ServiceNow on the Same VM

[nehaaress]

Hello Community,

I’m currently working on a requirement where I need to trigger an RPA bot through the Virtual Agent in SNOW, and then return the response back to the Virtual Agent. The challenge is that the Virtual Agent might be used by multiple users simultaneously, meaning the bot could be triggered by different users at the same time.

Here are my key requirements:

• Concurrent Execution: I need to run the same RPA bot multiple times in parallel on the same virtual machine.
• User-Specific Responses: Each user's request must be handled individually, ensuring that responses are accurately mapped to the requesting user without mixing up outputs.

Given these requirements, I’m concerned about potential conflicts or mismatches in the outputs.

Has anyone encountered a similar scenario? What solutions or add-ons would you recommend to manage this effectively?

Thank you in advance for your help!

[Jeremy Thomassi]

I can't think of a way you can run more than one bot on a single vm concurrently. Are you using robot pools? That could help with some of it. Does the Virtual agent create a work item or does it trigger a bot directly? 

[nehaaress]

Yes, I’m using a robot pool to manage multiple bots on a single VM. The RPA bot is triggered directly by the Virtual Agent (VA), without creating a work item.

To handle this, I'm planning to implement a session management approach. Specifically, I'll create a custom table to store session information whenever a bot is triggered. This table will help keep track of each session and ensure that outputs are correctly routed.

However, I’m encountering an issue where simultaneous bot triggers can lead to output mismatches—where Person A’s output might be returned to Person B and vice versa. I’m working on resolving this to ensure that each user receives the correct response.

Additionally, the concept of a robot pool is typically used for unattended bots. For attended bots, which interact directly with users and may not benefit from a robot pool setup, I’m exploring alternative approaches to manage concurrency and ensure reliable session handling. Any recommendations on handling attended bots in this context would be appreciated.

[Shreekanth2]

You can use RPA Queues to store the session information instead of separate table. RPA Queue provides locking capabilities i.e. once an item is picked (locked) by a robot no other robot can pick the same work item. Using this you can manage routing the correct output to correct person.

As you correctly mentioned, Robot pool is for Unattended Robots. Robots should be added in a Robot Pool, based on the the work load from Queues, it can help in starting/freeing the robots from the dedicated robots in a pool.

When you ask for handling Attended Robots in this context, are you looking for running the automation on the user machine itself?  

[nehaaress]

Thanks, Shrikant! I will look into it.

Actually, I performed a PoC in which I generated a session when the RPA bot is triggered. I mapped that session ID with the work item and am trying to return the correct response. I’m storing the values I want to retrieve from the bot in that session record, but it is not working. I'm currently working on that logic.

I will consider your solution.

Regarding the attended robot, I'm running it on the user’s machine; specifically, it’s an agent who performs this activity.