Is it possible to add a password to the robot please?

Is it possible to add a password to the robot please and and let the password during a time i defined?


Could you please tell more details for better understanding.

1 Like

for example if i want to give a robot to someone but just for 2 days; i will give him a password.
But after 2 days the robot will stop runing

1 Like

Hi @Soudios

You mean your publish process that you want to give a restriction if you run it to another machine ?

cheers :smiley:

Happy learning :smiley:


It can be an example yes


If you mean that you want to install & run a robot in a different machine, and then provision a license for that robot but only for two days. Then I think you can simply provision the robot that will be used via Orchestrator and then disable it via Orchestrator as well after 2 days.

Things to keep in mind though:

  • Robot is installed in the new machine
  • Having available/enough robot licenses

Now, if you’re pertaining to a package/.nupkg file. Then I don’t think that you’ll be able to put some sort of time restriction on this. You can of course create a schedule via Orchestrator on when and how long it will operate, but even after the schedule, the downloaded package will still be in the other machine.
You can perhaps create a different automation which will delete the package after 2 days.

If I misunderstood anything, please tell me, so that I may be able to provide further suggestions.

1 Like

No just if i create a robot and send the xaml file to another person, did i need a licence ?

Did the other person needs a licence ?

If the other person install the robot on its orchestrator, did it needs a licence ?

If i don’t need a licence for all of this, how can i create a different automation which will delete the package after 2 days plz ? :slight_smile:

thank you

Hello @Soudios.

Just to be clear, a robot always needs a license.

Now, let’s say you’re using community edition, so by default you will have 3 Production robot licenses (2 attended and 1 Unattended) and 2 Dev (Studio - Named user).
So you will be able to assign to the new robot the licenses provided that they’re still available (no other robot is using them).
If you need help on how to do this, feel free to ask, and we’ll help you out.

Basically here’s how it will go:

  • You will install a robot software in the new machine
  • You will also provision a robot & machine in the Orchestrator in order to connect that machine and newly installed robot to the Orchestrator.
  • After provisioning the robot you can then assign an available license to it so that it will be able to work and execute automations (keep in mind the different license types and how they differ in method of executions).
  • Once the 2 days are over you can then disable/remove that robot via Orchestrator, effectively freeing up the license and disabling the robot.

You can of course send the .xaml file to the other person or you can just publish the project via Studio to the Orchestrator, and assign the published process to the newly created Robot via Orchestrator as well.
After assigning the published process to the robot, the robot will then be able to download the package/.nupkg file (which will also contain the .xaml) in order to execute

With regards to creating the automation, you will of course need at least 1 Studio.
The logic for the workflow will basically just go like this, the process will look for the file inside the folder which if I’m not mistaken is in "C:\Users\username.nuget\packages"

1 Like

Thank you for those clarification,

Yes, let’s say i am using community edition,
if i understand i can create all the robot i want but i can run it just one by one on orchestrator ?

How can i publish something on my orchestrator and it will run in an other computer to let me disable the robot after 2 days for example ? @BenMar

1 Like

Technically, if user had your package, they can extract it to xaml code, then do everything - anytime they want.
If he’s not a technical guy, you can release package with encrypt file that define expired date
In first step, robot will decrypt that file and compare today with expired date to decide running or not.

1 Like

So i need to publish the the process on his orchestrator ?
@Doanh @BenMar

1 Like

Hello @Soudios. No, you will only need one instance of Orchestrator in this case.
Basically here’s how it will go:

  • Install the new robot software to the different machine.
  • Log in to the Orchestrator and create the following via Management funtionalities:
    • Machine
    • Robot (You will also give the robot the necessary available license during creation)
    • Environment (Optional)
  • Connect the newly installed robot software to the Orchestrator by going to the robot tray settings and adding the necessary details.

Here are the necessary documentations:

You can just stick with standard Machines & Robots for now.

Have a great day! Happy learning :vulcan_salute:

1 Like

First, thank you for responding me :slight_smile: @BenMar

I know how to do that for my robots on my computer. i already run robots from orchestrator

Sorry if i am not understanding everything.

But this is what i think / know :

  1. I can connect my orchestrator only with my computer because i need the computer’s name
  2. If i send my robot to an other person, the other person has to connect his computer to his orchestrator otherwise he will not be able to run the robot from orchestrator.

My question is : How can i be able to manage a robot i sent from my orchestrator plz

@BenMar @Doanh

1 Like

Hello @Soudios,
You’re very welcome, glad to be of help.

  1. Yes, you are correct with this one.
  2. Nope, you can also connect the other person’s computer to your Orchestrator.
    That’s basically one of the main functions of the Orchestrator, easy management of all the robots, jobs, and machines. It wouldn’t do if users needed one instance of Orchestrator per machine.

So, here’s how it will go. You will basically do the same process you did in order to connect your machine & robot to the OC.

  • Create a new Standard machine instance via Orchestrator, use the name of that computer as the name of the Machine.
  • Allocate the necessary number of licenses to that Machine (this will be the licenses that can be used by the robot that is provisioned in that Machine).
  • Create a new Robot and select the newly created Machine where it’s gonna be used (the other person’s computer)
  • Give the robot the necessary license.
    • Note: That only Unattended licenses / type of robots can now be executed via Orchestrator
  • Give that robot the necessary credentials to access the other person’s computer
    • domain\username
    • password
    • Again, I think these will only be necessary for unattended type of robots since they’re the only ones that can run via Orchestrator.
  • Save that robot.
  • After creating both the Machine and Robot proceed to the other person’s computer.
  • Access the robot settings of the other person’s newly installed robot.
  • Add the Machine name (as the one you recently created)
  • Add the Orchestrator URL (your platform URL)
    sample:[AccountLogicalName]/[ServiceName]/. <- This part is important for the latest Orchestrator version. Don’t just use the, but also include the accountname and service name of your Orchestrator.
  • Add the Machine key of the newly created Machine.
  • Save the settings and restart the robot service.
  • And you’re done, that person’s robot is now connected to your Orchestrator.
1 Like

Oh thank you ! It’s clear now

But can i do that with free licence ? (have my robot and manage other robots?)

New questions :slight_smile:

  1. The other person can also lunch the same robot on its orchestator ?
  2. If i update/publish a robot, it will appear on the person’s orchestrator ? (if i change the Url path)

Thank you

Hey @Soudios,

Yup, you can do those (i.e. create & manage other robots) with free/community license IF all those robots are provisioned & connected to your Orchestrator.

New Questions:

  1. The other person would only be able to launch the same robot application/software using a different Orchestrator after they cut the current connection between your Orchestrator and the robot. After they disconnect their robot from your Orchestrator, they would then need to do the the previous steps we talked about using their own Orchestrator (i.e provision a machine & robot, allocate licenses, connect their robot to their own Orchestrator).

    • So, in short they will need to disconnect their robot software/application from your Orchestrator first before being able to use it in their own Orchestrator.
  2. The other person would not be able see anything directly related to your Orchestrator using their own Orchestrator, regardless if their robot is still connected to your OC.

    • Published processes/workflows will not appear in their own Orchestrator unless they download it from your Orchestrator and then publish it to their own.
  • Here are some other things the other person can do with their robot in their computer:
    • They can launch/run the robot application on their own computer.
    • They can download & execute published processes from the Orchestrator via Robot tray, provided that the robot is connected to the Orchestrator.
    • They can execute/run locally published/saved .nupkg files via Robot tray, if the robot is not connected to the Orchestrator.
    • But they won’t be see or access anything directly related to the Orchestrator webserver itself IF they don’t have access or know the Orchestrator account credentials - email & password.

Hope I was able to answer your questions. Happy learning! :vulcan_salute: