What are attended and unattended automation?
Attended automation executes alongside a person at their desk, where it is triggered by them and visible to them. Unattended automation executes on its own against a schedule or an event, on infrastructure nobody is watching. The distinction governs where credentials live and who learns that something has gone wrong.
Why the attended and unattended split decides who is accountable
Operations teams inherited this pair of words from the robotic process automation era, and they remain the fastest way to establish what a deployment actually involves. Attended work borrows a person's session and a person's attention, so a failure is noticed within seconds. Unattended work has neither of those, which is why it needs a service identity and a destination for the work it could not finish. Most disappointing deployments were scoped as one mode and delivered as the other.
- Attended automation inherits the permissions of whoever is at the desk.
- Unattended automation needs an identity of its own, and an owner for that identity.
- A failure in attended work is visible immediately to the person it interrupted.
- Scheduled work fails quietly at night unless somebody engineered the alert.
How attended and unattended automation work
- The trigger is established first as either a person's action or a schedule.
- Attended tasks are packaged to launch from the desktop the person already uses.
- Unattended tasks are assigned a service identity with its own scoped permissions.
- Secrets for unattended work are retrieved from a vault at execution time.
- Monitoring and alerting are attached to every schedule before release.
- Capacity is reserved so scheduled work does not contend with interactive sessions.
How attended and unattended automation are evaluated
Each mode is assessed against the failure it is likely to produce. Examine the following separately for attended and for unattended work:
- share of tasks executing under a service identity rather than a personal one
- time between an unattended failure and a person learning of it
- completion rate by hour of day for scheduled work
- number of attended tasks requiring a person to remain present throughout
- permission scope granted against the scope actually exercised
Limitations, risks and common failure modes
- Unattended work is deployed under a developer's personal credential and then forgotten.
- A person's departure disables every schedule that borrowed their account.
- Attended automation is sold on hours saved while a person watches it throughout.
- Scheduled work overlaps the nightly batch and contends for the same records.