- Introduction
- Product lifecycle
- Customer data usage with cloud products
- Use of customer data with AI Center
- Use of customer data with AI Computer Vision
- Use of customer data with Apps
- Use of customer data with Assistant
- Use of customer data with Automation Ops
- Use of customer data with Autopilot for Everyone
- Use of customer data with cloud robots
- Use of customer data with Communications Mining
- Use of customer data with Data Service
- Use of customer data with Document Understanding™
- Use of customer data with Insights
- Use of customer data with Integration Service
- Use of customer data with IT Automation
- Use of customer data with Orchestrator
- Use of customer data with Process Mining
- Use of customer data with Robot
- Use of customer data with Studio and StudioX
- Use of customer data with Studio Web
- Licensing
- Delivery options
- UiPath Platform
- Product download
- Platform guidelines for partners
- Localization support
- Compatibility matrix
- Attended vs. Unattended automation
- Activities overview
- UiPath documentation
- Troubleshooting

Overview
Attended vs. Unattended automation
The first decision to be made when planning your automations is whether the solution is to be executed in an Attended or Unattended context. You may have heard this concept referred to previously as front-office automation versus back-office automation.
While both types are intended to automate tasks a user would otherwise perform manually on their computer, the specific use cases are different between them.
Attended Automations are automations that run under human supervision and, because of this, are best suited for use with smaller, more fragmented tasks. For example, the submission of an expense report is a task that lends itself to attended automation. The user provides the credentials to log in to the system and the automation then fills in the requisite information, attaches any needed items, and submits the report on the user's behalf.
As there is always a human user present, attended automations must not be created with or granted permissions to perform tasks the user themselves could not. Any credentials required during the execution of an attended process should always be credentials that the user triggering the automation knows and provides themselves.
This is because there is no way to ensure security isolation between a running automation and the machine user. If the automation itself performs actions the user does not have access to, it would thereby allow that user access that they are not otherwise granted. Taking the expense report example from above, if bundled in that automation is also the process of approving expense reports, the user could simply pause or stop the automation after it has logged in to the approval system and then approve any report in any amount, an action they could not perform with their own credentials.
Unattended Automations are automations that are intended for more complex and highly repetitive tasks, usually needing to be performed in batches, that can be decided based upon a predefined rule. Additionally, unattended automations are suited to processes that perform privileged operations, requiring elevated permissions and credentials.
From the example above, the approval of expense reports would be such a task. The automation, with no human user present, would log in to the necessary system, and then process any submitted expense reports and, if they match a defined rule (e.g. under a specified amount), automatically approve them.
In this example, the unattended process is provided the access to approve the expense reports through credential assets that are configured by the Administrator. This provides security isolation as the automation developers only reference credentials to be provided. Besides, it guarantees a clear audit chain as records of who obtains and manages the credentials used by the automation are always logged.