- 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
- Configuring automation capabilities
- Solutions
- Audit
- Settings
- Cloud robots
- Folders Context
- Automations
- Processes
- Jobs
- Apps
- Triggers
- Logs
- Monitoring
- Queues
- Assets
- Business Rules
- Storage Buckets
- Indexes
- Orchestrator testing
- Resource Catalog Service
- Integrations
- Troubleshooting
Orchestrator user guide
Unified Pricing licensing
The following table provides details on what licensing plans allow you to use cloud robots:
|
Feature |
Community |
Basic Trial |
Basic |
Standard Trial |
Standard |
Enterprise | Application Test Standard | Application Test Enterprise |
|---|---|---|---|---|---|---|---|---|
|
Automation Cloud™ Robots - VM |
|
|
|
|
|
|
|
|
|
Automation Cloud™ Robots - Serverless |
|
|
|
|
|
|
|
|
|
Elastic Robot Orchestration |
|
|
|
|
|
|
|
|
When defining the automatic machine template, make sure you have enough platform units on your machines.
If you do not have enough platform units, the following consumption restrictions apply:
-
If your platform units do not match to the maximum number of VMs defined in the pool, we delete all machines in the pool and stop creating new ones until you allocate enough platform units to support the maximum number of machines.
Note: Instead of adding more platform units, we recommend reducing the maximum number of VMs in the pool. - A job running on a machine that does not have enough platform units generates the following alert "No VMs in <Pool_name> due to insufficient platform units."
- As soon as enough platform units become available, they are automatically consumed.
- If you have multiple pools in an overconsumption state, we allocate any available platform units to the last created pool subsets.
Example: You have five pools, each having a maximum of three machines, totaling 15 machines. Your platform can support two machines, meaning all five pools are now in an overconsumption state, so you cannot use them.
- You add the required platform to support five more machines. Now, you can use a total of seven machines.
- Two pools become available and they consume platform units for six machines (two pools of three machines each).
- Three pools remain in the overconsumption state, and the available platform units serve one machine. Therefore, the two pools are created last.
Once automatic pools are created, the allocated platform units are consumed based on their monthly distribution. Automatic renewal applies if platform units are available.
When a VM is deleted from a manual pool, or when an automatic pool is deleted, the corresponding platform units are released in the following 24 hours.
-
For the remaining of the current contract month, you can reuse the released platform units in the same tenant.
-
For the following months, remaining platform units can be used across tenants.
For example, you aquired a bundle of 10,000 platform units for one-year contract, which starts on January 1st and ends on December 31st. The following timeline enfolds:
-
January 1st - you create VM1 in tenant T1, which consumes the negociated amount, say 1,200 platform units.
-
January 15th - you delete VM1 from tenant T1.
-
January 16th - the 1,200 platform units are released and you can reuse them to create VM2 in the same tenant T1.
-
February 1st - you keep the same VM2 running in tenant T1, and this consumes another 1,200 platform units from your bundle, based on the monthly distribution. You are left with 7,600 platform units (10,000 minus 1,200 for January and 1,200 for February).
-
February 15th - you keep the same VM2 in tenant T1, but you create two more VMs in two different tenants, T2 and T3. This consumes 2,400 platform units from the remaining 7,600: one for the VM in tenant T2, and one for the VM in tenant T3. You are left now with 5,200 platform units.
