Control Room and Scheduling
Sessions and resources
Control Room is the operational console. Know that a Resource (a digital worker machine) runs Sessions of a Process. Sessions can be started manually or by a Schedule. Understand session states and what it means to stop a session gracefully versus terminating it - graceful stop lets the process reach a safe point, termination does not.
Schedules and triggers
Schedules define when a process runs: start time, recurrence, and the resource it runs on. Triggers can be time-based or event-based (for example, a file appearing or a queue reaching a threshold). Know how to configure a schedule to run repeatedly through the day, and how the scheduler handles a resource that is already busy - the session typically waits or is skipped depending on configuration.
Queues in Control Room
Operators use Control Room to inspect queues, view exceptioned items, and re-queue or reset them. Know that you can view item detail and exception reasons, and that resolving an exception usually means fixing the cause then resetting the item to New so it is picked up again.
Environment and configuration
Environment variables are managed here and can differ per environment (development, test, production). This is how the same process runs against different systems without code changes.
Traps
Questions test the difference between stopping and terminating a session, and whether a schedule can run on a busy resource. Another common trap is confusing a schedule with a queue trigger. Also watch for answers that suggest editing a process to change an endpoint - that is an environment variable change.
Rule of thumb
Operational changes (when it runs, where it runs, what it points at) belong in Control Room; logic changes belong in the process. Never redeploy code to change configuration.
Governance, Security, Roles and Environment Management
Roles and permissions
Blue Prism security is role-based. Know the concept of user roles that grant permissions over folders, processes, objects, queues, and Control Room functions. A developer role can edit processes; an operator role can run and monitor sessions but not change logic. Least privilege is the principle: grant only what the role needs. Questions test whether a role should be able to edit production processes (generally no) and whether operators need design rights (no).
Environment separation
Understand the promotion path: development, test/UAT, and production, each with its own environment variables and credentials. Releases are packaged and promoted, not edited live in production. Change control means every production change is reviewed, tested, and traceable.
Audit and credential handling
Blue Prism maintains audit logs of changes and session activity. Credentials should be stored securely (credential manager) and referenced, never hard-coded in processes or notes. Know that environment variables can hold references to credentials rather than the secrets themselves.
Governance artefacts
Be familiar with the purpose of a design authority or review board, a solution design document, a release note, and an operational runbook. Governance is about who can change what, how changes are approved, and how the solution is operated and audited.
Traps
Questions often present a tempting shortcut - editing a process directly in production to fix an urgent bug, or giving an operator design rights to 'help out'. Both violate least privilege and change control. Another trap is storing passwords in a data item or a Note stage.
Rule of thumb
If a change touches production logic, it goes through the release process; if it touches configuration, it goes through the environment variable and change record. Nobody edits production directly.