The attended versus unattended distinction is the foundational architecture decision in RPA deployment design — determining whether an automation runs on a user’s active desktop under human supervision (attended) or independently on a dedicated virtual machine without a human present during execution (unattended). The distinction is not simply about whether a human is watching; it affects the automation’s trigger mechanism, its licensing model, its governance requirements, its security profile, and the types of processes it is appropriate for. Choosing the wrong model for a process — deploying an unattended automation for a process that genuinely requires human judgment at critical steps, or deploying attended automation for a high-volume overnight process that should run independently — produces either operational failure or significant unnecessary licensing cost.
How It Works
| Dimension | Attended | Unattended |
|---|---|---|
| Trigger | User action (keyboard shortcut, assistant interface, manual start) | Schedule, orchestrator queue item, API call, webhook event |
| Human presence | User is present; can intervene, provide input, and monitor progress | No human present; bot executes fully autonomously |
| Runtime environment | User’s active desktop — same machine, same logged-in session | Dedicated virtual machine or physical machine, logged in as a service account |
| Volume profile | Low-to-medium volume; one process instance per user session | High volume; multiple concurrent bots processing parallel queue items |
| Exception handling | Can pause and ask user for input on exception | Must handle all exceptions autonomously or mark item for later review |
| Credential handling | Can use user’s interactive session credentials | Must use service account credentials managed through orchestrator vault |
Design Considerations
Unattended automation in finance contexts carries governance implications that attended automation does not. An unattended bot that posts journal entries, triggers payment runs, or submits regulatory filings does so without a human reviewing each action in real time. The internal control framework must account for this: the bot’s actions must be logged in an audit trail that a human can review after the fact, the scope of the bot’s system access must be restricted to the minimum required for the process (principle of least privilege), and the business process owner must accept accountability for the bot’s output as they would for a human operator’s output.
What Breaks in Production
The specific failure that most frequently produces credential-related unattended bot failures is a service account password expiry that was not incorporated into the orchestrator credential management process. Unattended bots authenticate to target systems using service account credentials stored in the orchestrator’s credential vault. When the Active Directory password policy expires the service account password — and the password change is not propagated to the orchestrator credential store — the bot attempts to authenticate with an expired password, receives an authentication failure, and either crashes or marks every queue item as failed. In environments where password expiry is managed by IT without automation operations visibility, this failure occurs on a predictable calendar — typically 90 days after the credential was last updated — and is entirely preventable through a credential expiry monitoring process.
How Loop Wise Solutions Designs for This
In unattended automation deployments, we document credential management as an operational procedure — specifying the service accounts used by each bot, their password expiry policy, the process for propagating credential updates to the orchestrator vault, and the monitoring alert that is triggered when a bot’s authentication fails. We recommend service accounts with non-expiring passwords for automation use (where Active Directory policy permits and security review approves) or automated credential rotation that updates the orchestrator vault as part of the password change process.
Answers before you ask.
Attended automation runs on a user's desktop alongside the user, triggered by them and assisting with tasks within a human-led process. Unattended automation runs independently on a virtual machine or server, triggered by a schedule or queue event, with no human present. The difference is where it runs and what triggers it — desktop-with-user versus server-autonomous.
Attended bots deploy to user desktops and are typically licensed per attended user; unattended bots run on servers or VMs, often licensed per runtime, and need orchestration infrastructure. The models differ in where software is installed, how it is triggered, and how it is licensed. These practical differences follow directly from the attended-versus-unattended architecture.
Unattended automation, running without a human present, needs stronger governance — orchestration, credential management, monitoring, and exception handling to substitute for the missing human oversight. Attended automation has a supervising user in the loop. The architecture therefore shapes the governance model, with unattended requiring more infrastructure to run safely without a person watching.
By the process: if it needs human judgment during execution, attended fits; if it is high-volume, scheduled, or time-critical and can run autonomously, unattended fits. The use cases differ, and many programmes use both. The choice is a design decision driven by whether a person must be in the flow, not a matter of one being superior.