Infrastructure Planning and Prerequisites
Sizing the platform before you touch a server
Blue Prism installations are only as stable as the planning behind them. A candidate must understand the split between the interactive client tier, the application server tier, and the database tier, and how each scales differently. Interactive clients are installed on the machines where developers and the control room operate; they are latency-sensitive and should sit close to the application server on the network. Application servers run the automation services and communicate with both clients and the database, so bandwidth and round-trip time matter more than raw CPU. The database server carries the heaviest sustained load.
Prerequisites that questions love to probe: supported Windows Server versions for the application server, matching .NET Framework requirements, local administrator rights during installation, service account creation ahead of time, firewall rules for the ports used between tiers, and antivirus exclusions for Blue Prism directories and the database files. A classic trap is assuming the interactive client can be installed on the same host as the application server without consequence - it can be done in small environments but is discouraged for production because a user session can destabilise the services.
Another trap: confusing the hardware guidance for a proof of concept with production guidance. A pilot with a handful of processes tolerates modest specifications; a production estate with many concurrent digital workers and large work queues does not.
Rule of thumb: size the database for peak concurrent sessions plus headroom, not for the number of licensed robots alone, because idle robots still hold connections and scheduled processes create bursts.
Worked example: a design with 40 robots, 10 developers and 2 control room operators should be planned around 52 potential concurrent sessions at peak, with the database provisioned for that concurrency and storage growth from queue and log retention.