Security and Credential Handling
Credentials
Never hard-code credentials in processes or objects. Use Credentials stored in the Blue Prism database (encrypted) or an external vault via the hub or a credential provider. Credentials are referenced by name and retrieved at runtime, and access can be restricted by role.
Roles and permissions
Blue Prism uses role-based access control. Roles grant permissions on folders, processes, objects, queues, and system settings. Understand the difference between user roles (what a person can do in the client) and resource roles (what a runtime resource can execute).
Traps
A common trap is assuming encryption at rest removes the need for access control; both are needed. Another is storing secrets in environment variables or notes, which are not secure vaults. Questions may test audit logging: who changed what and when. Also know that runtime resources should run under least-privilege service accounts, not interactive administrator accounts.
Data protection
Apply data minimisation, mask sensitive values in logs, and avoid writing personal data to shared file locations. Understand encryption of queue data and of the database connection.
Rule of thumb
If a secret appears anywhere in a process, object, note, or log, it is a finding.
Worked example
A process needs a database password. Store it as a named credential in the vault, grant the resource role access to that credential only, and retrieve it at runtime. Never write it to a data item that is logged.
Exception Handling, Resilience and Recovery
Exception types
Distinguish business exceptions (the data or business rule prevents completion, e.g. invalid invoice) from system exceptions (technical failure, e.g. application unavailable). Business exceptions usually should not be retried; system exceptions often should, within limits.
Stages and patterns
Use Exception to raise, Recover to handle within a block, and Resume to continue after a recoverable point. Design retry with a bounded count and backoff. Use deferrals on queue items for transient failures so they are retried later without blocking the queue.
Traps
A frequent trap is catching all exceptions in one place, which hides the distinction between business and system failures. Another is infinite retry loops. Questions may test what happens to a queue item when an unhandled exception occurs: it is marked as an exception with the reason. Also know that a crashed worker's locked item returns after the lock timeout.
Resilience patterns
Design for idempotency, checkpointing, and graceful shutdown. Log enough context to diagnose without exposing sensitive data. Monitor exception rates and alert on spikes.
Rule of thumb
Retry system exceptions a bounded number of times with backoff; never retry business exceptions.
Worked example
A payment posting fails because the target system times out. The block recovers, defers the item for 10 minutes with a retry count, and after three deferrals marks it as an exception for manual review.
Deployment, Release Management and Environment Promotion
Releases and packages
Blue Prism groups changes into releases that can be exported as packages and imported into another environment. A release contains processes, objects, and related artefacts. Understand the promotion path: development, test, UAT, production.
Change control
Every promotion should be traceable to an approved change, with version numbers and release notes. Use compare features to review differences between environments. Never develop directly in production.
Traps
A common trap is assuming a package import also brings credentials or environment-specific configuration; those must be configured per environment. Another is promoting without checking dependencies: a process may depend on an object or queue that does not exist in the target. Questions may test rollback: keep the previous release available so you can redeploy it.
Testing
Promotion should follow testing gates: unit, system integration, UAT, and non-functional testing. Regression testing is needed when shared objects change.
Rule of thumb
If it is not in the release package and documented, it does not exist in the target environment.
Worked example
A process change also modifies a shared object used by three other processes. The release includes the object and all affected processes, and regression tests cover all four consumers before promotion to production.
Performance, Scalability and Capacity Planning
Measuring performance
Identify the metrics that matter: transactions per hour, average and peak handling time, queue depth, exception rate, and resource utilisation. Measure at the process, object action, and infrastructure level to find bottlenecks.
Scaling
Scale horizontally by adding runtime resources, and vertically by giving resources more CPU or memory. Horizontal scaling is usually preferred but is limited by database throughput, licence cost, and application concurrency limits on target systems.
Traps
A frequent trap is assuming more workers always means more throughput; if the database or target application is the bottleneck, adding workers makes things worse. Another is ignoring think time and application response times in estimates. Questions may test queue polling load and lock contention.
Capacity planning
Estimate from average handling time, volume, and peak factor. Add headroom for retries and failures. Model target application limits, such as maximum concurrent sessions.
Rule of thumb
Workers needed = (peak volume per hour x average handling time in hours) / target utilisation, then add headroom.
Worked example
Peak volume is 600 items per hour, average handling time is 2 minutes (0.033 hours), and target utilisation is 80 percent. Workers = (600 x 0.033) / 0.8 = 25. Add 20 percent headroom for about 30 workers, subject to database and application limits.