What are the changes happen when the Mode is changed like Automation running in Attended and Automation running in unattended Mode .
PS:- I want to understand challenges from unattended to attended… not difference
@Rehan_Ali1 The main difference is how the process runs.
In Attended mode, the user is logged in and usually starts the automation from UiPath Assistant. The user can also interact with the process while it is running.
In Unattended mode, the process can run automatically without user involvement, usually through Orchestrator using a trigger or schedule.
So if you are changing from Unattended to Attended, the workflow itself may not need any changes. Mainly check user/machine configuration, and how you are starting the process
Hi @Rehan_Ali1,
If you have a separate support team, I would recommend checking with them as well. Every RPA CoE may follow different best practices based on its requirements and setup.
A few things you can check when changing an automation from Attended to Unattended mode:
- Config file path: Make sure the config file is available on a shared location accessible by the VM, or bundle it with the package.
- No user interaction: The automation should not expect any input from the user, such as credentials, file selection, confirmations, Message Boxes, etc.
- No hard-coded values: Check for any hard-coded paths, URLs, credentials, or other values that may cause issues in the unattended environment.
- File and folder access: Make sure the Robot has access to all required files, folders, applications, and network locations.
- Input/Output folders: Make sure the input and output folder locations are accessible from the VM and are properly configured.
- Logging: Ensure proper logging is implemented so that you can identify the status of the automation and troubleshoot issues.
- Exception handling: Make sure unhandled exceptions are properly captured and logged, so failures can be identified and investigated.
Thanks!
Attended
- Runs in user session
- VDI or machine needs to be open.
- User needs to start the automation cannot schedule it
Unattended
- Runs in its own session
- VDI or machine needs to be available and the bot would log into it
- Automations can be scheduled and no manual intervention is needed
cheers
Hi @Rehan_Ali1,
Attended Mode
- Triggered manually by the user from UiPath Assistant.
- Runs in the logged-in user’s session.
- Supports user interaction (Input Dialog, Message Box, Forms).
- Uses the user’s desktop, applications, and permissions.
- Best for tasks that need human involvement.
Unattended Mode
- Triggered automatically by Orchestrator (schedule, queue, API, trigger).
- Runs without user intervention in a robot session.
- Should not use UI prompts or dialogs requiring user input.
- Opens applications and logs in automatically using robot credentials/assets.
- Best for fully automated, end-to-end business processes.
Hi @Rehan_Ali1,
Here are the things that change when switching between Attended and Unattended mode.
- Trigger: Attended runs manually by the user; Unattended is triggered by Orchestrator (schedule, queue, API).
- Machine: Attended runs on the user’s own machine; Unattended runs on an Orchestrator-managed VM.
- Session: Attended needs the user logged in; Unattended needs no human present.
- Human role: Attended is human-in-the-loop; Unattended runs fully autonomous.
- License: Attended license vs. pooled Unattended license.
- Control: Unattended gives full Orchestrator control (logs, retries, scheduling); Attended has limited visibility.
- Use case: Attended fits front-office co-pilot tasks; Unattended fits high-volume back-office batch jobs.
Hope this helps.
Cheers!
Hi @Rehan_Ali1 ,
Attended automation works with a human present, while unattended automation runs fully on its own. Most issues occur because the unattended robot runs in a different session and needs all dependencies, permissions, and configurations to be available automatically.
Thanks
Hi @Rehan_Ali1 ,
Welcome to UiPath Community
When an automation changes from Attended to Unattended mode, the workflow/XAML itself does not necessarily need to change. The main difference is how and where the automation is executed.
Attended Automation:
-
Usually started by the user through UiPath Assistant, or UiPath Studio.
-
Runs in the logged-in user’s Windows session.
-
Can depend on user interaction, such as Input Dialogs or file selection.
-
Suitable for tasks where the robot assists the user.
Unattended Automation:
-
Usually triggered through Orchestrator using schedules, queues, APIs, etc.
-
Runs without the user being present.
-
The execution session and credentials need to be properly configured.
-
The workflow should avoid depending on manual user input.
-
Inputs should preferably come from arguments, assets, queues, configuration files, or APIs.
When moving from Attended to Unattended, some important things to check are credentials, permissions, user-specific paths, browser/application profiles, mapped drives, screen resolution, application state, and interactive dialogs.
So, in most cases, the business logic remains the same, but the workflow may need adjustments to remove dependencies on the logged-in user and make the process fully independent.
Also, Attended vs Unattended should not be confused with Foreground vs Background execution—they are different concepts in UiPath.
Attended vs Unattended
Attended mode
Runs on your own computer, while you’re logged in.
You have to start it yourself can’t be scheduled.
You can watch it and interact with it while it runs.
Unattended mode
Runs on its own, without needing anyone to be logged in.
Controlled by Orchestrator it can run on a schedule or automatically.
No person needs to click start or watch it.
What to check if you switch a bot from one mode to the other
You usually don’t need to rewrite the whole automation just check these things:
- No popups or questions for a person – The bot shouldn’t ask for things like passwords, file choices, or click ok to continue, since no one will be there to answer.
- No fixed/hardcoded paths or links – Things like file locations or URLs typed directly into the bot might not work on a different machine.
- Config file is reachable – Any settings file the bot needs should be saved somewhere the new machine can also access like a shared folder, or included with the bot.
- Bot has proper access Make sure the robot account has permission to open all the files, folders, and apps it needs.
- Machine/session setup:
Attended = needs a real person logged in and clicking run.
Unattended = needs a VM that the robot can log into by itself, and it can be scheduled to run automatically.
If the same application access, permissions, credentials, and machine/application setup remain unchanged, the automation should generally work fine when moving from Unattended to Attended.
Hi @Rehan_Ali1
The main challenges when moving from Unattended to Attended are:
-
The user must be logged in and the machine should be available.
-
UI actions may depend on the user’s screen/session.
-
Pop-ups or user interactions may stop the automation.
-
Screen lock, RDP disconnect, or user activity can affect execution.
-
Credentials and application access may behave differently in the user’s session.
So, an automation that runs fine in Unattended may need some changes to work reliably in Attended mode.
@Rehan_Ali1
The biggest challenge when moving from unattended to attended is that the robot now shares the user’s desktop and session. Focus changes, mouse or keyboard activity, popups and user-specific permissions can affect the run. I’d mainly review the UI input methods, credentials and paths tied to the service account, then add a clean Assistant entry point and user-friendly error messages.