- Getting started
- Best practices
- Tenant
- About the Tenant Context
- Searching for Resources in a Tenant
- Managing Robots
- Connecting Robots to Orchestrator
- Storing Robot Credentials in CyberArk
- Storing Unattended Robot Passwords in Azure Key Vault (read only)
- Storing Unattended Robot Credentials in HashiCorp Vault (read only)
- Storing Unattended Robot Credentials in AWS Secrets Manager (read only)
- Deleting Disconnected and Unresponsive Unattended Sessions
- Robot Authentication
- Robot Authentication With Client Credentials
- SmartCard Authentication
- Configuring automation capabilities
- Audit
- Settings - Tenant Level
- Resource Catalog Service
- Folders Context
- Automations
- Processes
- Jobs
- Triggers
- Logs
- Monitoring
- Queues
- Assets
- Storage Buckets
- Test Suite - Orchestrator
- Other Configurations
- Integrations
- Host administration
- Organization administration
- Troubleshooting
About licensing
Orchestrator is typically licensed through either a host license or an organization-level license, by a system administrator.
However, there are certain functions in Orchestrator that require that administrators or users of Orchestrator understand and work with other types of licenses, which allow the use of various features. These are called service licenses and, of these, of particular interest is the runtime.
This page covers strictly the licensing aspects of interest to Orchestrator administrators and users for using Orchestrator.
To learn more about the various types of licenses, see:
Several permissions are available to allow a user to perform the various license-related actions described on this page:
- License - Edit or License - Create - enables you to activate or update licenses
- License - View - enables the See More buttons on the License page, which allow you to see details about the licensed Robots in their corresponding page. The View Robots button is also available on these pages if you also have the Robots - View permission.
- License - Delete - enables you to remove licenses.
A licensing process most commonly starts with activating your Orchestrator license, as explained here. If you want to manage your licenses at host level, activate your Orchestrator license and allocate them as explained here.
Afterward, all you need to do to activate a Robot license is to connect the Robot to Orchestrator.
For Studio, there are two possibilities:
- You can activate its license directly from Orchestrator . This is the recommended method.
- You can activate it locally and then connect Studio to Orchestrator through its Robot. Remember to select the Stand-alone license checkbox when creating your Robot, to prevent Orchestrator from allocating Studio a license from its pool of licenses.
There are several ways to monitor license usage from Orchestrator:
-
If you want to assess whether there's room for maximizing licensing efficiency, you have the possibility to monitor historical licensing data on the Tenant > Monitoring page, by selecting License from the Section list.
-
In the License page, the total number of runtimes available on all online machines is displayed. Remember that a machine consumes the licenses as soon as the Robot Service starts.
To instantly release a license, disable the machine from the corresponding License page. Please note that you cannot use Studio or the Robot on a disabled machine.
A disabled machine appears crossed out on the Robots page:
Although license management is typically performed from the administration interfaces, in Orchestrator you do work with a particular type of license: the runtime, which is a service license for robot use.
Runtimes are the licenses you need to run unattended automations. You allocate runtimes when you create a machine object in Orchestrator. There are two aspects to know when allocating runtimes:
-
Number of runtimes: You can assign a custom number of runtimes to a machine template, which determine the number of processes that can run at the same time on a machine.
The number required runtimes is given by the number of jobs you want to allow to be executed at the same time on this machine; it is not impacted by the number of robots on the machine.
Let's say you have a machine template with 10 Production (Unattended) runtimes allocated to it. For each workstation that is connected using the machine key of that template, 10 Production (Unattended) runtimes are reserved from the available licenses at the tenant level, allowing for executing 10 jobs at the same time. From these reserved runtimes, a runtime is only in use during job execution. So if you connect 4 machines to Orchestrator using that template, you need and reserve 40 runtimes at the tenant level. With, for example, 25 jobs running, 25 out of the 40 reserved runtimes are in use, leaving 15 runtimes that are reserved, but unused.
- Types of runtimes: The types of runtimes that are assigned to a machine object determine the types of processes that can run on that machine.
By default, you are notified 180, 90, 30, 14, 7, and 1 day before the license expiry date. You can configure these values using the SystemJobs.LicenseExpirationAlert.DaysBefore app setting.
At host level, for single licenses distributed across multiple tenants, only the system administrator receives these email alerts. At tenant level, all active users with License - View permission receive them. The emails are localized per user.
Grace period
Your license might include a grace period. If it does, you are notified about it at logon, and can renew the license without experiencing any service disruptions. If it does not, your robots stop working upon expiry.
