# Configuring automation capabilities

> Automation capability options for enabling attended and unattended automation for users and groups in an organization.

Configuring automation capabilities involves allowing specific users or groups within an organization to automate various tasks, processes, or workflows. Whether the jobs should run attended or unattended, you can choose from the following options to suit your automation scenarios:

* enabling users to run personal automations
* running automations on unattended infrastructure via unattended robots
* configuring robot accounts to run unattended automations

## Enabling personal automations

Personal automations are automations that can run under a user's identity either locally on the user's machine, or remotely (personal remote automations) on server-side resources to which the user has no direct access to. User accounts and their association with roles allows for a certain level of access to resources in Orchestrator.

This article describes how to enable your users to:

* Run automation on their local machine via the UiPath® Assistant;
* Run background personal remote automations in folders where the user has the necessary permissions and in their personal workspaces;
* Run and debug in UiPath Studio, both desktop and web;
* Manage automations in their personal workspace.

For developers and business users, check how to [manually run a job or configure a trigger to launch jobs as yourself](https://docs.uipath.com/orchestrator/automation-cloud/latest/user-guide/running-personal-remote-automation#running-personal-remote-automations).

### Enabling users to run personal automations

To enable personal automation capabilities, select either the group or user scope as described below.

#### For user groups

Groups simplify administration for accounts with similar needs that are managed together.

1. Under **Manage Access** - **Access Rules**, select **Groups**.
2. Select **Assign group** to assign a new group and add roles, or edit an existing group.
3. On the **Assign access rules page**, under **Personal automation setup**, select one of the following options:
   * **Enable user to run automations** — allows users in that group to run automation on their local machine via UiPath Assistant, run background personal remote automations in folders where they have permissions, and run and debug in UiPath Studio (desktop and web)
   * **Enable user to run automations + Personal Workspace** — allows users to manage automations in their personal workspace and run background personal remote automations in their personal workspaces
4. Select **Update**.

#### For individual users

Enable personal automation capabilities for individual user accounts only when group members require additional capabilities beyond those granted by group membership.

1. Under **Manage Access** - **Access Rules**, select **Users**.
2. Select **Assign user** to assign a new user and add roles, or edit an existing user.
3. On the **Assign access rules page**, under **Personal automation setup**, select one of the following options:
   * **Enable user to run automations** — allows the user to run automation on their local machine via UiPath Assistant, run background personal remote automations in folders where they have permissions, and run and debug in UiPath Studio (desktop and web)
   * **Enable user to run automations + Personal Workspace** — allows the user to manage automations in their personal workspace and run background personal remote automations in their personal workspaces
4. Select **Update**.

:::note
Deselecting the **Enable user to run automations** option triggers a warning message indicating that any running automations will be affected and your Studio Web experience could be downgraded.
:::

## Enabling unattended automations

UiPath® accounts represent identities authorized to access Orchestrator resources:
* **User accounts** — represent human users
* **Robot accounts** — represent non-human users (equivalent to Windows service accounts)

An administrator can enable an unattended robot to impersonate a user account, allowing the robot to run automations with the same privileges as the user it impersonates.

### Use cases for unattended automation

**On user accounts:** Typically done by developers debugging automation projects and business users running automations under their own identity on server-side resources.

**On robot accounts:** The standard approach for unattended automation execution. Robot accounts have unattended capabilities enabled by default; administrators only configure infrastructure settings.

**Via personal remote automation:** An alternative that's easier to set up because it doesn't require an unattended robot enabled for the user account. See [enabling personal automations](https://docs.uipath.com/orchestrator/automation-cloud/latest/user-guide/configuring-automation-capabilities#enabling-personal-automations).

### Personal remote automation vs. unattended automation

| Aspect | Personal Remote Automation | Unattended Automation on User Account |
|---|---|---|
| **Process type** | Background processes only | Background and interactive processes |
| **Identity scope** | Single process execution (granular control) | All processes across accessible folders |
| **Setup complexity** | Simpler (no unattended robot required) | Requires unattended robot configuration |

### What you can enable

Administrators can enable developers and business users to:
* Run background processes on unattended infrastructure via unattended robot impersonation
* Run processes that require user interaction on unattended infrastructure via unattended robot impersonation

### Running automations in a folder

Users can debug and run processes from all folders they have access to. They can use unattended infrastructure for execution, provided that an administrator has allocated to that folder the physical resources to run unattended automation, that is they assigned to that folder a machine template object with at least one runtime. Typically, for debugging, a NonProduction runtime is used.

Developers and business users can launch a process either by launching a job manually or via triggers in that folder.

Figure 1. Running automations in a folder

![Screenshot of the Automations interface](https://dev-assets.cms.uipath.com/assets/images/orchestrator/orchestrator-screenshot-of-the-automations-interface-233238-93e7bb34-feaaf012.webp)

If the user does not see any runtimes available when starting a job from Orchestrator, then the admin should make sure that:

* they assigned both the user account and a machine template to the folder that contains the process to be executed.
* they assigned runtimes to the machine template. This is not necessary in personal workspaces.

### Debugging in a personal workspace

A personal workspace is the personal folder of a user and it acts as a separate and segregated storage space from the official Orchestrator feed. In a personal workspace, Orchestrator takes over several operations an admin would have to perform in a folder, allowing publishing, running and debugging automation projects without the admin intervention:

* Orchestrator automatically creates a process from each package published from Studio to the personal workspace feed of that user;
* Orchestrator automatically manages machine templates on the behalf of the administrator for [personal workspace](https://docs.uipath.com/orchestrator/automation-cloud/latest/user-guide/personal-workspaces#personal-workspaces) owners and a machine template with a Development runtime is automatically created and assigned to each new personal workspace.

Users can debug or run a process either by launching a job manually or via triggers in that workspace.

Figure 2. Debugging in a personal workspace

![Screenshot of the Automations interface](https://dev-assets.cms.uipath.com/assets/images/orchestrator/orchestrator-screenshot-of-the-automations-interface-227207-de194fb1-728e08c4.webp)

### Enabling users to debug from Orchestrator

For a user to run processes on unattended infrastructure, an administrator must enable both personal automation capabilities and impersonation by an unattended robot. The latter enables the robot on a physical host machine to run under the identity of that user.

Required licenses:

* A user license.
* An unattended runtime.
* Robot units for cloud robots.

For users to debug processes on unattended infrastructure, perform the following when you reference or edit the user account in Orchestrator:

1. Under **Personal automation setup**, select the **Enable user to run automations** option.

If the user is member of a group with personal automation capabilities, they inherit the capabilities from that group. Therefore, you can skip this step.

The option allows users in that group to:
   * Run automation on their local machine via the UiPath Assistant.
   * Run background personal remote automations in folders where the user has the necessary permissions.
   * Run and debug in UiPath Studio, both desktop and web.
2. Alternatively, still under **Personal automation setup,** select the **Enable user to run automations + Personal Workspace** option.

The option allows users in that group to:
   * Manage automations in their personal workspace.
   * Run background personal remote automations in their personal workspaces.
3. Under **Unattended setup**, configure the infrastructure to execute unattended foreground processes.

Choose one of the following options:
   * **Use the VMs preconfigured Windows user account** (Automation Cloud robots only) — delegates Automation Cloud robots to execute processes that require user interaction using a preconfigured Windows account
   * **Use a specific Windows user account** — execute processes on a specific Windows machine by filling in the **Domain\Username** and **Password** fields with the correct host machine credentials
4.

If using a specific Windows user account, configure the credential settings per the following reference table.

To configure the credential settings when you use specific Windows accounts, check the following:

 <colgroup>
  <col/>
  <col/>
 </colgroup>
 
  
     Field  
     Description  
  
 
 
  
    Domain\Username 
     The account under which the robot runs. 
      
         For domain-joined accounts, use the <code>domain\username</code> syntax.

For example <code>deskover\localUser1</code> . 
         For local Windows accounts, use the <code>host_machine_name\username</code> syntax, with the name of the host machine, instead of the domain. For example, <code>LAPTOP1935\localUser2</code> . 
         For local Windows accounts that reside on multiple host machines, that you want to use regardless of machine, use the <code>.\username</code> syntax with a dot, instead of the host machine name.

For example <code>.\localUser3</code> . 
         For Azure AD joined machines, use the <code>azuread\username@domain.com</code> syntax. 
      

  
  
    Credential store 
     The credential store used for your password.

For more details, check  Credential stores  .  
  
  
    Password 
     The password used to log into the machine where UiPath Robot is installed.  
  
  
    Credential type 
     Specifies the type of password credential.  
  
 

5. Enable the **Run only one job at a time** option to restrict the user to simultaneously execute multiple jobs. This helps when you automate applications that do not allow you to use a credential more than once at a time (e.g., SAP).
6. Select **Update**.

### Enabling users without Orchestrator access to debug on the host machine

When interactive authentication is enforced, in UiPath Assistant, a user can only see the processes to which they have access and only after signing in to their account. A user license is also required. Therefore, unattended processes which do not run under a user account are not available in UiPath Assistant for troubleshooting, making it impossible for a user to debug an unattended process by logging into that host machine.

To overcome this, an administrator can temporarily enable a troubleshooting session on their machine. Doing this lets the user see and run the unattended process locally, without requiring a user license. The troubleshooting session is temporary and the above only applies while troubleshooting is active.

You can also use Studio for its [remote debugging](https://docs.uipath.com/studio/docs/remote-debugging) capabilities. It allows running and debugging attended and unattended processes on remote machines, including on Linux robots that can run cross-platform projects.

#### Step 1. Enable a troubleshooting session
1. Go to **Tenant** &gt; **Monitoring**.
2. Select **Unattended sessions** from the **Section** dropdown menu.
3. Identify the machine where the error occurred, Select **More Actions** at the end of the machine row and select **Configure troubleshooting session**.

The option is only available if interactive authentication is enforced.

You can find out on which machine a process ran by selecting the [Processes](https://docs.uipath.com/orchestrator/automation-cloud/latest/user-guide/monitoring-processes#processes) section.

The **Configure troubleshooting session** dialog opens:

Figure 3. Configuring troubleshooting session

   ![Screenshot of the Configure troubleshooting session](https://dev-assets.cms.uipath.com/assets/images/orchestrator/orchestrator-screenshot-of-the-configure-troubleshooting-session-225774-6066f895-f53c6fec.webp)

4. Under **Troubleshooting session**, Select the toggle to switch it to **Enabled**.
5. In the **Session timeout (minutes)** box, edit the value to change the number of minutes the troubleshooting session should be active.

After the specified number of minutes passes, the troubleshooting session is automatically disabled and no further connections are accepted. However, any existing connections remain active until disconnected.

6. Select **Save**.

#### Step 2. Connect to UiPath Assistant

Follow these instructions to connect to the machine and run the unattended processes from UiPath Assistant with your account.

1. In Orchestrator, go to **Tenant** &gt; **Machines** and Select **Copy Client ID / Machine key**![docs image](https://dev-assets.cms.uipath.com/assets/images/orchestrator/orchestrator-docs-image-CopyMachineKey_Icon-c5cf179c-b006f7c4.png) at the end of the machine row to copy the machine key to your clipboard.
2. In UiPath Assistant, Select the user icon in the title bar and select **Preferences**.
3. Select the **Orchestrator Settings** tab and Select **Disconnect** or **Sign out** if needed so that you can edit the connection settings.
4. Configure the connection as follows:
   1. **Connection Type** - Select **Machine Key**.
   2. **Orchestrator URL** - Add the URL to the Orchestrator instance, which should include the tenant and organization.
   3. **Machine Key** - Paste the copied machine key from your clipboard.
5. Select **Connect** and then close the **Preferences** window.
6. If you do not see the unattended processes in Assistant, then go to **Preferences** &gt; **Sign In** and log in with your credentials.

Now you can run unattended processes from UiPath Assistant to troubleshoot them.

#### Step 3. Extend or disable the troubleshooting session

When you have finished debugging, you can disable the troubleshooting session for the machine so that it won't allow attended connections anymore. Or, if you need to, you can extend the amount of time that the session is active.

1. Go to **Tenant** &gt; **Monitoring**.
2. Select **Unattended sessions** from the **Section** dropdown menu.
3. Select **More Actions** at the end of the machine row and select **Configure troubleshooting session**.
4. In the **Configure troubleshooting session** dialog:
   * **Close the session**: switch the toggle under Troubleshooting session to **Disabled**. When disabled, no further connections are accepted. However, any existing connections remain active until disconnected.
   * **Extend the session**: Edit the value in the **Session timeout (minutes)** box with a greater value to extend the session to the specified duration.
5. Select **Save**.
6. Disconnect UiPath Assistant to close the connection.

### Configuring robot accounts to run unattended automations

Unattended automation typically runs on robot accounts, the UiPath® equivalent of Windows service accounts. Robot accounts can be thought of as non-human identities that need to be authorized to access Orchestrator resources. Their association with roles allows for a certain level of access to resources in Orchestrator.

Robot accounts have their unattended capabilities enabled by default, administrators only have to configure several infrastructure related settings.

#### Enabling unattended automation on a robot account

Configure unattended execution settings under a robot account and on a specific infrastructure as follows:

1. Under **Manage Access** - **Access Rules**, select **Robot accounts**.
2. Then, either select **Assign robot account**, to assign a new robot account and add roles, or edit an existing robot account.
3. On the **Assign access rules page**, under **Unattended setup**, select the infrastructure to execute unattended foreground processes under that robot account:
   1. Select the **Unattended robot using predefined VM credentials** (for runs on UiPath Automation Cloud robots only) option to delegate Automation Cloud robots to execute processes that require user interaction. The robots use a preconfigured Windows account when they execute processes.
   2. Select the **Unattended robot using custom Windows credentials**. To execute processes on a specific Windows machine, fill in the **Domain\Username** and **Password** fields. You must specify the correct credentials for the host machine, so the robot can log into it successfully. This allows the robot to run processes that require user interaction under that specific Windows account.

To configure the credential settings when you use specific Windows accounts, check the following:

 <colgroup>
  <col/>
  <col/>
 </colgroup>
 
  
     Field  
     Description  
  
 
 
  
    Domain\Username 
     The account under which the robot runs. 
      
         For domain-joined accounts, use the <code>domain\username</code> syntax.

For example <code>deskover\localUser1</code> . 
         For local Windows accounts, use the <code>host_machine_name\username</code> syntax, with the name of the host machine, instead of the domain. For example, <code>LAPTOP1935\localUser2</code> . 
         For local Windows accounts that reside on multiple host machines, that you want to use regardless of machine, use the <code>.\username</code> syntax with a dot, instead of the host machine name.

For example <code>.\localUser3</code> . 
         For Azure AD joined machines, use the <code>azuread\username@domain.com</code> syntax. 
      

  
  
    Credential store 
     The credential store used for your password.

For more details, check  Credential stores  .  
  
  
    Password 
     The password used to log into the machine where UiPath Robot is installed.  
  
  
    Credential type 
     Specifies the type of password credential.  
  
 

   :::note
   Unattended robots can run background jobs on any infrastructure. It is, however, recommended to specialize your host machines to execute particular types of processes in order to maximize efficiency and cut costs. Learn more about [optimizing unattended infrastructure using machine templates](https://docs.uipath.com/orchestrator/automation-cloud/latest/user-guide/optimizing-unattended-infrastructure-using-machine-templates#optimizing-unattended-infrastructure-using-machine-templates).
   :::

4. Enable the **Run only one job at a time** option to restrict the account to simultaneously execute multiple jobs. This helps when you automate applications that do not allow you to use a credential more than once at a time (e.g., SAP).
5. Under **Advanced robot options**, configure execution settings for the unattended robot. Learn about [robot settings](https://docs.uipath.com/orchestrator/automation-cloud/latest/user-guide/robot-settings#robot-settings).
6. Select **Update**.
