Standard Vs Floating Bots

robot
general-inquiry
#1

Hi

Can someone share more insights on Floating and standard bots please, with examples? Planning for a migration from 2016 to 2018 version, Please let me know if there will be any reduction on overall cost w.r.to floating bots.

#2

Taken from the following article

Types of Robots

According to the Robot/Machine Interaction

  • Standard Robot - works on a single Standard Machine only, namely the one defined when creating it. This is ideal for the scenario in which a user always works on the same machine.
  • Floating Robot - works on any machine defined in Orchestrator, be it Standard or Template, as the machine name is not relevant when creating it. Only Attended and Development Robots can be floating, and as such, they become licensed automatically when you open the Robot tray. These types of Robots only work with Active Directory users and are useful if the machine you want to add a Robot to has a different name each time it is spawned, such as for Non-Persistent VDIs. Same goes for hotseat environments, where different people are working in shifts on the same computer.

Example:
Let’s say you have an environment with 8 users working on non-persistent virtual desktops. Machine allocation is done randomly, so one user can be allocated any of the available machines in the VDI.

  • In the standard scenario, you would have to define a Robot for each user/machine combination. For a VDI with 8 machines that means 64 Robots.
  • In the floating scenario, you only need to define one machine template and 8 Floating Robots (one for each user). The template persists across your entire VDI such that each of the users can connect to their Robots using one key, the Machine Template key.
1 Like
#3

Hi There - any chance we can get a definition for floating vs standard in layman (business) language. This would be extremely helpful. I have read the information at the link that is provided in all of these responses, but quite frankly when I try to derive a “coles notes” of what 's there, I doubt myself.

#4

Essentially it’s a Floating licensing which is oftenused when you have a large pool of users, but they are not all working at the same time, so instead you opt for a floating license in order to minimize the number that you need to support the number of users that could potentially be online concurrently (at any given time).

Maybe you could offer what your current understanding of floating robots vs standard is and the community could help clear some things up?

#5

Thank you! So, this is what I’m thinking… as it relates to our implementation.

Context: For every production robot (VM) we have, we have a development. So if we have 5 production robots (A, B, C, D, E) , we also have 5 development robots (A2, B2, C2, D2, E2). Each “robot pair” (i.e. A and A2) support (in our case) a particular business area, and so the configuration of such is set up to support that business area specifically.

Without Floating Robots: If two developers wanted to work on an automation related “A” simultaneously, only one of the two developers could use “A2” at a time. Today, if there is a priority automation that requires additional resources, we scramble to see if we can “loan” development robot (i.e. “B”) from another team, to that priority work. So, essentially we need to configure that “B2” with whatever is needed to support development for “A”, and when they are done “borrowing” “B2” – we give back to team “B”.

With Floating Robots: All of the Robots, whether production or development (i.e. “A” or “A2”) can be utilized by anyone in the ecosystem as long as they are configured appropriately (to support the processing being run). The need to “loan” goes away, and users of the system simply use what is available.

So, to clarify, even with production robots (A, B, C…) – if one (A) robot is “busy” running a process then the system will automatically seek (B, C, ….) to see if there is an available floating robot to do the work.

Am I thinking of this correctly? PLEASE let me know if I am not.