Glossary Intelligent Automation services

What Is Attended vs Unattended Architecture?

Attended automation runs on a user's desktop alongside the user, triggered by the user and assisting with specific tasks within a human-led process. Unattended automation runs independently on a virtual machine or server, triggered by a schedule or queue event,…

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.

← Back to glossary

Need help implementing Attended vs Unattended Architecture?

Our team works with enterprise organizations across Egypt and the GCC. Tell us about your situation.