- Release notes
- Installation and upgrade
- Before you begin
- Getting started
- Activities- Designing long-running workflows
- Start Job And Get Reference
- Wait For Job And Resume
- Add Queue Item And Get Reference
- Wait For Queue Item And Resume
- Create Form Task
- Wait For Form Task And Resume
- Resume After Delay
- Assign Tasks
- Create External Task
- Wait For External Task And Resume
- Complete Task
- Forward Task
- Get Form Tasks
- Get Task Data
- Add Task Comment
- Update Task Labels
 
 
- Actions
- Processes
- Audit

Action Center
- Single node deployments - single node Action Center connected to a single node Orchestrator instance
- Multi-node deployments - we recommend the following multi-node deployments:
                     - In a multi-node deployment scenario, the Orchestrator is set up behind a load balancer, while a single instance of Action Center is installed on a separate server. Action Center is configured to point to the URL of the Orchestrator's Load Balancer.
- Another type of multi-node deployment involves setting up the Orchestrator behind a load balancer with multiple nodes. In this configuration, Action Center is installed on each Orchestrator node, and each instance of Action Center points to the Orchestrator's Load Balancer URL.
 
Single-node hardware requirements
| Max. Concurrent Users | CPU Cores (min 2GHz) | RAM (GB) | 
|---|---|---|
| 4,000 | 2 | 4 | 
| 12,000 | 4 | 4 | 
Test Setup and Sample Data
To test the performance for a single node Action Center connected to a single node Orchestrator instance, the below setup and sample data was used:
- 3 hours of test time
- Form Data payload having a size of 5000 bytes
- 28,000 actions created
- 17 different API endpoints executions
- Simulated concurrent users
Multi-node hardware requirements
Based on our performance tests, we recommend the maximum numbers below:
- 150,000 attended robots connected to Orchestrator and running jobs
- 10,000 Action Center users processing actions
- 3,000 unattended robots running jobs (creating actions and resuming after the actions completion)
Environment Configuration
To ensure seamless performance for the above scenario, we recommend setting the environment below.| Instance | No. of Deployment Nodes | Azure VM | vCPU Cores | Frequency (GHz) | RAM (GB) | 
|---|---|---|---|---|---|
| Action Center | 3 | B2s | 2 | 2.0 | 4 | 
| Orchestrator | 10 | F16 | 16 | 2.0 | 32 | 
| SQL Server | 1 | F32 | 32 | 2.0 | 64 | 
Drive Storage
Allocate a drive for each of the following content:
| Stored Content | Drive Capacity | 
|---|---|
| Database | 1TB | 
| Temporary database | 1TB | 
| Transactional logs | 1TB | 
Database Setup
| Product | Configuration | 
|---|---|
| Redis Enterprise HA | CentOS 8 CPU Cores 2.0 GHz minimum frequency 16GB RAM | 
| Bucket storage VM | Standard L32s_v2 Ultra Disc 4TB 900MB/s throughput | 
Test Setup and Sample Data
We generated the hardware requirements, along with additional setups and configurations, by conducting performance tests that simulate a large load on Action Center and Orchestrator. The tests were performed using the following sample data:
- 10,000 concurrent Action Center users
- 240,000 actions
                        - 60% document validation actions
- 40% form actions
 
- Payload per one form action:
                        - Form layout—5KB
- Form data—5KB
- 10 storage files x 100KB
 
- Payload per one document validation action:
                        - One PDF file x 150KB