Note: You are looking at a static snapshot of documentation related to Robot Framework automations. The most recent documentation is at https://robocorp.com/docs

Working with Control Room

Control Room is Robocorp's solution to the problem of automation orchestration. This article introduces the main concepts to give you an overview of what is possible with the tool, helping you decide where to use it and how to configure it for your specific use cases.

What are robots?

In the Robocorp stack, a robot is a Python-based self-contained automation package, a directory tree that contains all the code and dependencies needed for its execution in a target environment. In practice, the only required file is the robot.yaml[/setup/robot-yaml-format] file. All other directories and files are optional.

For distribution, the robot directory tree is archived into a single file using the popular ZIP file format.

The easiest and most convenient way to create robots is by using Robocorp's developer tools:
๐Ÿ‘‰ VS Code extensions provides an extensive developer experience
๐Ÿ‘‰ RCC is a command-line tool for robot development to leverage with the tools or in CI/CD.

Are you creating your first robot? If so, we recommend following our Beginners' course to learn with a fun use case from start to finish. Completing the course will grant you the Robocorp Level I certificate!

What can you use Control Room for?

Once you or your developers have created a working robot, you need to decide where and when to run it so that it can accomplish its tasks.

You will most likely need to find answers to these questions:

  • Where will the robot run?
    Do you plan to have a physical or virtual machine that will execute the robot task? Or maybe you should use containers?
  • When will the robot run? How will it be triggered?
    Does your process need to run on a schedule that repeats itself? Or does it need to be triggered when something happens in another system?
  • Are the robots completely autonomous, or is a human needed as well to complete the process? A typical use case is to have some parts of a process still requiring confirmation or decision making from a human operator. How will you achieve this?
  • How will different robots communicate with each other?
    Do you need to pass information between different processes?
  • How do you make sure that the right people have access to the code and to the robot itself? Typically, only some specific people should be allowed to interact with the robot. Or, your work might span over different organization departments, or even completely different organizations. How will you manage access control?
  • How will you monitor the robots once they are running?
    If the process encounters any errors or anomalies, who should be alerted? Where can your users access logs and files resulting from the automation?

The orchestration features of Control Room provide answers to all these questions.

Control Room can be used to store your robot code - integrating with version control systems, trigger automation workflows in a variety of ways, provide access control inside your organization, run your robots completely on the cloud via containers, or remote-control a fleet of machines using the Robocorp Workforce Agent, provide accurate reports and logs of all your automation workflows, and more.

How do you upload your robots to Control Room and keep them in sync?

Before you can run your automation code in Control Room, you need to upload or sync it. You can do this in several different ways depending on your requirements.

File-type robots

In this case, the bundle zip file is uploaded to the cloud directly. Each time a change is needed, a new version of the robot is uploaded.

The upload can be done manually via the Control Room UI, or, more conveniently, using the dev tools: RCC, the VS Code extensions support uploading code into Control Room this way.

This type of workflow has the advantage of being simple and requiring only minimum setup, but it is recommended only when version control is not available.

Learn why and how to set up version control for your automation projects with our Software robot project workflow free course!

Robots hosted in a public Git repository

If your robot code is available in a public Git repository, you can associate a robot in Control Room with the repository with a single link. All commits to the chosen branch in the repository will be reflected in the cloud-hosted robot.

This approach is useful when sharing examples - you can run all the robots on our Portal Site this way, for example - or when you want to share your code publicly.

Robots hosted in a private GitHub repository

If you host your code in a private repository in GitHub, you can associate and sync the cloud robot with your repository by granting Control Room access to it. Just follow the instructions in Control Room.

This is the easiest way to share your code securely with Control Room and set up a simple automated workflow: the code will be updated each time you merge into the main branch.

Suppose you need to set up a more complex workflow as part of your CI strategy. In that case, you can take advantage of our GitHub Actions integration capabilities.

Running your robots in Control Room

Once you have uploaded your automation code to Control Room, you can run it in two different ways: as part of a Unattended Process, or as an Assistant.

A Unattended Process:

  • Can be triggered manually using the Cloud UI interface or via API calls, or it can be run on a fixed schedule.
  • Contains one or more steps that have access to the same data pipeline
  • Can span over multiple target systems (for example a desktop application and a web application)
  • Can run completely in the cloud using Robocorp-Hosted Cloud Workers, or on a physical or virtual machine running the Robocorp Worker.

An Assistant:

  • Is configured in Control Room.
  • Is triggered by a human operator using the Robocorp Assistant.
  • Allows the human operator to interact with the Robot (attended automation).
  • Will report back to Control Room the status of the operation, and any artifacts produced during its execution.
Last edit: December 9, 2021