Attended vs Unattanded and orchestrator

Help Studio
1

I want to understand these things from project perspective not just an chagpt general answer

  1. What is the difference between Attended and Unattended Robots?
  2. Can an Unattended process be executed in Attended mode? If yes, under what conditions?
  3. Can an Attended process be executed in Unattended mode? If yes, what changes are required?
  4. Which types of processes can run in both Attended and Unattended modes?
  5. Which processes are suitable only for Attended Robots and why?
  6. Which processes are suitable only for Unattended Robots and why?
  7. What are the limitations of running an Unattended process in Attended mode?
  8. What role does Orchestrator play in both execution modes?
  9. What are the licensing and infrastructure requirements for each mode?
  10. What are the recommended best practices while designing automations that may need to run in both modes?
2

Hi @Rehan_Ali1 ,
Check these answers:

1. Difference between Attended and Unattended Robots

Attended Robot

  • Triggered by a user.
  • Runs on the user’s machine.
  • Human is present during execution.
  • Used when decisions, approvals, or user interactions are required.

Example: Employee clicks a button to process an invoice from Outlook.

Unattended Robot

  • Triggered by Orchestrator, schedule, API, queue, event, etc.
  • Runs without human intervention.
  • Uses service accounts/robot accounts.
  • Usually runs on VMs or dedicated machines.

Example: Nightly SAP reconciliation process running at 2 AM.

2. Can Unattended Process run in Attended Mode?

Yes

Conditions:

  • Process should not depend on Orchestrator assets/credentials unavailable to the user.
  • User must have application access.
  • No machine-level restrictions.
  • Required input parameters must be supplied manually.

Project Example: Invoice process designed for nightly execution can be tested by a developer manually from Studio Assistant.

3. Can Attended Process run in Unattended Mode?

Yes, but redesign may be required

Need to remove:

  • Message Boxes
  • Input Dialogs
  • Human interventions
  • Manual file selections
  • User confirmations

Replace with:

  • Queue items
  • Input arguments
  • Orchestrator Assets
  • Action Center (for approvals)

4. Processes that can run in both modes

Good candidates:

  • Invoice Processing
  • Report Generation
  • Data Validation
  • Email Processing
  • SAP Data Extraction
  • OCR based document processing

Condition:

  • Human interaction should be optional.

5. Suitable only for Attended Robots

Examples:

  • Employee onboarding forms
  • Service desk assistant
  • Desktop helper bots
  • Chatbot-triggered tasks
  • Processes requiring frequent user decisions

Reason:

  • Human input required in real time.

6. Suitable only for Unattended Robots

Examples:

  • Night batch jobs
  • Payroll processing
  • ERP reconciliation
  • Database sync
  • Scheduled reports
  • Queue processing

Reason:

  • Runs 24x7 without human involvement.

7. Limitations of running Unattended Process in Attended Mode

Issues commonly faced:

  • User may not have required permissions.
  • Orchestrator credentials may not be accessible.
  • Process expects queue items.
  • Schedule-based logic may fail.
  • Different user profile/settings.
  • Performance differs from production VM.

Real-world example: SAP process works as unattended using robot account but fails for business user because SAP roles differ.

8. Orchestrator Role

Attended

  • Package deployment
  • Asset management
  • Queue access
  • Monitoring
  • Logging

Unattended

  • Scheduling
  • Credential management
  • Queue processing
  • High availability
  • Monitoring and execution control

Without Orchestrator: Attended can still run locally.

For Unattended: Orchestrator is practically mandatory.

9. Licensing & Infrastructure

Attended

  • Attended User License
  • User laptop/desktop
  • UiPath Assistant

Unattended

  • Unattended Robot License
  • VM/Server
  • Orchestrator
  • Service Account
  • Machine Template

10. Best Practices for Dual Mode Design (Very Important)

When designing a process that may run in both Attended and Unattended:

Use Config file

Use Arguments instead of Input Dialog

Store credentials in Orchestrator Assets

Avoid Message Boxes

Implement proper Exception Handling

Use logging extensively

Keep business logic separated from UI logic

Parameterize file paths

Avoid dependency on local user profile

Follow REFramework for enterprise processes

Thanks

4

Hi @Rehan_Ali1,

I think these are great set of questions and one-liner/one-paragraph answers may not help you understand completely. Most of them come down to three things like who starts the job, whose session it runs in, and what license it uses. I would recommend you go through the official docs which cover these topics well:

I hope this helps you.

Cheers!

5

Is this your homework assignment?

6

The distinction between attended and unattended automation is important when deciding how UiPath workflows should be deployed and managed through Orchestrator. It would be helpful to clarify how licensing, triggers, user interaction, and robot management differ between the two approaches in a typical setup.

7

hiiii @Rehan_Ali1

From a project perspective, I would look at it this way:

Attended automation is user-driven — the user starts/interacts with the automation on their machine. Unattended automation is designed to run without user involvement, typically triggered/scheduled and managed through Orchestrator.

The same workflow can often be designed to support both modes, provided it does not depend on an active user’s interaction. For example, processes involving APIs, files, databases, queues, and web applications can generally be designed with both execution models in mind.

The main limitations appear when the process depends on:

  • User input or decisions

  • Interactive desktop applications

  • An already logged-in user’s session

  • Local resources that are only available in the user’s session

For unattended execution, you also need to consider the Robot/Automation Cloud or Orchestrator configuration, machine infrastructure, credentials, and the appropriate licensing.

A good design approach is to keep the business logic independent from the execution mode. For example, put user-dependent activities behind a clear input/approval step and keep the main processing logic reusable. Then the same process can be adapted for attended execution or scheduled/unattended execution with minimal changes.

Last point: I would not decide Attended vs Unattended only based on the workflow itself. Check the trigger, user interaction, application/session requirements, infrastructure, and licensing before selecting the execution model.