# Configuring access for accounts
> As an administrator, you can configure fine-grained tenant or folder permissions for objects that already exist at the organization level (i.e. groups, users, robot accounts, external apps), via Orchestrator, by assigning them to tenants or folders in Orchestrator. An object gets the permissions required to perform particular operations in a tenant or folder through one or more roles.
As an administrator, you can configure fine-grained tenant or folder permissions for objects that already exist at the organization level (i.e. groups, users, robot accounts, external apps), via Orchestrator, by assigning them to tenants or folders in Orchestrator. An object gets the permissions required to perform particular operations in a tenant or folder through one or more roles.
You can use groups to simplify access control, as groups allow you to manage objects with similar needs together.
:::note
* When you rename a local group at the
organization level, it is also renamed in Orchestrator. If you rename it several times in a short timeframe, only the last change is captured in the Orchestrator audit logs. If you want to see all such changes, you can check the organization-level audit.
* Since the username of a robot account
is permanent, and cannot be changed after it is set, the **Username** column under **Manage Access** also remains unchanged. For example, if you rename the robot from `Test` to `Test1`, only the **Name** column updates with the new value, leaving the **Username** unchanged. For more information, refer to [Adding robot accounts](https://docs.uipath.com/automation-cloud/automation-cloud/latest/admin-guide/managing-accounts-and-groups#adding-robot-accounts).
:::
To make use of all available types of identities, groups, users, robot accounts, and external apps are split into separate pages for groups, users, robot accounts, and external apps. You can find these under dedicated tabs, on the **Manage Access** page.
As an overview of the tabs, the **All** tab includes all objects that have been assigned access at the tenant level. The **Groups**, **Users**, **Robot accounts**, and **External apps** tabs include the local and directory groups, local and directory users, robot accounts, and external apps that have been assigned access at the tenant level.
## Tenant-level access control
The **Manage access** page allows you to control access for all objects (i.e.groups, users, robot accounts, external apps). This means that you can:
* assign to a tenant any objects that already exist at the organization level
* configure permissions for objects in Orchestrator
* remove tenant access from the existing objects
Group configuration (roles, web login, robot settings) is passed on to any user that belongs to that group and is later added or auto-provisioned.
### Assigning groups to a tenant
In a tenant, when assigning groups and adding roles to it, note that these are inherited by all users and robot accounts that are part of that group.
Groups are created and maintained by organization administrators from the **Admin** > **Accounts and Groups** page.
:::note
By default, the **User Access Type** filter in the **All** and **Users** page is set to **Elevated**, displaying only users with directly assigned or elevated access. To view all users, including those inheriting access through groups, change the filter to **All**.
:::
1. In the search field, type an existing user group to which you want to prove tenant access.
Should a new group be required, click **Manage Accounts** to arrive at the organiation level, where all new objects are added.
2. Click the **Roles** field and select the checkbox for each role you want to assign to the selected group.
If needed, you can define a new role by clicking **New role**.
3. Under **Account Settings**, you can choose if the group members can to log in to the Orchestrator UI.
After the migration to union of privileges, UI access is determined by the combined permissions of all groups an account belongs to. This means that if at least one group grants UI access, the account will have access regardless of the settings at the individual account level.
4. If you want to also [create an attended robot for group members](https://docs.uipath.com/orchestrator/automation-cloud/latest/user-guide/configuring-automation-capabilities#configuring-automation-capabilities), click **Next**.
Otherwise, click **Skip and assign** to apply your settings.
### Assigning accounts to a tenant
We recommend that you manage user access by [assigning roles to groups](https://docs.uipath.com/orchestrator/automation-cloud/latest/user-guide/configuring-access-for-accounts#configuring-access-for-accounts) and then adequately assigning users to the right groups to grant them the necessary roles.
However, if you need to perform a one-time role assignment for a particular user, you can directly provide access to the user, as follows:
1. In the search field, type the user to whom you want to assign access to the tenant.
Should a new user be required, click **Manage Accounts** to arrive at the organiation level, where all new objects are added.
2. Click the **Roles** field and then select the check box for each role you want to assign to the selected user.
If needed, you can define a new role by clicking **New role**.
3. Under **Account Settings**, you can choose if the user can log in to the Orchestrator UI.
After the migration to union of privileges, UI access is determined by the combined permissions of all groups an account belongs to. This means that if at least one group grants UI access, the account will have access regardless of the settings at the individual account level.
4. (Optional) Under **Update policy settings**, choose the release level to which you want this user to be required to update UiPath applications on their workstation. If you select a policy, the user will not be able to use UiPath® Robot, Studio, or Assistant until they upgrade these applications to the version required by the policy. This setting can help you make sure that all your users are using the same versions.
5. If you want to also create an [attended](https://docs.uipath.com/orchestrator/automation-cloud/latest/user-guide/configuring-automation-capabilities#configuring-automation-capabilities) or [unattended](https://docs.uipath.com/orchestrator/automation-cloud/latest/user-guide/configuring-automation-capabilities#configuring-automation-capabilities) robot for this user, click **Next**.
Otherwise, click **Skip and assign** to apply your settings.
### Assigning robot accounts to a tenant
We recommend that you manage robot access by [assigning roles to groups](https://docs.uipath.com/orchestrator/automation-cloud/latest/user-guide/configuring-access-for-accounts#configuring-access-for-accounts) and then adequately assigning robot accounts to the right groups to grant them the necessary roles.
However, if you need to perform a one-time role assignment for a particular robot account, you can directly grant access to the robot, as follows:
1. In the search field, type the robot account to which you want to grant access to the tenant.
Should a new robot be required, click **Manage Accounts** to arrive at the organiation level, where all new objects are added.
2. Click the **Roles** field and then select the checkbox for each role you want to assign to the selected robot.
If needed, you can define a new role by clicking **New role**.
3. If you want to also [create an unattended robot](https://docs.uipath.com/orchestrator/automation-cloud/latest/user-guide/configuring-automation-capabilities#configuring-automation-capabilities) for this user, click **Next**.
Otherwise, click **Skip and assign** to apply your settings.
### Assigning external apps to a tenant
As an administrator, you can configure fine-grained tenant or folder permissions for **confidential** apps, by assigning them to folders or tenants in Orchestrator. An external app gets the permissions required to perform particular operations in a folder or tenant through one or more roles.
1. Go to **Tenant** > **Manage Access**. The **Manage Access** page is displayed.
2. Click **Assign roles** > **External app**. The **Assign roles to an external app** window is displayed.
Figure 1. Assigning roles to an external app
3. In the search field, type the name of the external app you want to add.
4. Under **Roles**, select the role(s) for this object.
5. Click **Assign**.
### Assigning multiple accounts
1. Go to **Tenant** > **Manage access** and click the **Roles** tab.
2. On the **Roles** page, select a role from the list and click **More Actions** > **Manage Users**.
The **Manage Users** window is displayed and all users, groups, and robots are listed. If a checkbox is selected, that means the objects have this role assigned to them.
3. Select or clear the checkboxes as needed so that only those who should have this role are selected.
Figure 2. Managing adminstrator users
4. Click **Update** to apply your changes.
Changes to roles apply immediately when a user logs in, or automatically within one hour.
### Checking assigned roles
You can see what roles are assigned to an object (user, group, robot account, external app) from the following tenant-level locations:
* **Manage access** > **Assign roles** tab > select the object from the list > **More Actions** > **Check roles & permissions**
* **Manage access** > **Assign roles** > three-dots icon > **Check roles & permissions**
* **Robots** > select the account from the list > **More Actions** > **Check roles & permissions**
* **Monitoring** > **User sessions** > select the account from the list > **Check roles & permissions**icon
These options display the **View permissions** window, which is split between the **Tenant access** and **Folder access** sections. In turn, each section is made up of:
* The roles pane - includes the name of the role and its type (i.e. explicitly assigned or inherited).
* The permissions pane - lists the permissions included in the selected roles.
#### Tenant access
This section displays the roles and permissions granted at the tenant level. You can choose between these options:
* **All roles in this tenant** - the permissions pane displays all permissions corresponding to all roles granted to the selected entity at the tenant level.
* **Specific role** - the permissions pane only displays permissions corresponding to the selected role, as granted to the selected entity at the tenant level.
Figure 3. Tenant access 
#### Folder access
This section displays the roles and permissions granted at the folder level.
You can use the selection box to choose the particular folder for which to display the roles and their permissions. The list only contains folders where the selected entity is assigned.
If the selected entity has more than one role for the chosen folder, you can choose between these options:
* **All roles in this tenant** - the permissions pane displays all permissions corresponding to all roles granted to the selected entity at the folder level.
* **Specific role** - the permissions pane only displays permissions corresponding to the selected role, as granted to the selected entity at the folder level.
Figure 4. Folder access 
### Removing a user or group
Removing a user or group from Orchestrator does not delete the account from your organization.
1. Go to **Tenant** > **Manage access** > **Assign roles** tab.
2. Select the user or group, click **More Actions** , and select **Remove**.
If the user whose role you want to delete has a robot that is currently busy, you are informed that any running jobs will be deleted, and are asked whether you want to proceed with the deletion or cancel the operation.
3. Confirm the operation.
The user or group is removed from Orchestrator and all roles are revoked.
Alternatively, select one or multiple users, and click the **Remove** button.
:::important
* You cannot remove a user having the **Administrator** role.
* You cannot remove or unassign users part of mappings that are employed in triggers from the folder the trigger resides in.
Make sure the user is not set as an execution target in a trigger so you can delete them.
* Removing a directory group does not remove the license of an associated directory user, even if the group removal unassigns
the user from any folder. The only way to release the license is to close UiPath Assistant.
:::
### Recommended role-to-group mapping
The right combination of group and role allows you to correctly separate permissions, and give granular control to the appropriate people. To achieve this, we recommend the following role-group pairing:
Group
Has access to the Orchestrator interface
Has access to all folders/personal workspace only
Has API access
Tenant role
Folder role
Automation Users
No
Personal workspace Important: If a user is assigned to other folders via API, they also have access to those in addition to the personal workspace.
Yes
Allow to be Automation User
Automation User
Automation Developers
Yes
All folders
Yes
Allow to be Automation Developer
Automation Developer
Administrators
Yes
All folders
Yes
Orchestrator Administrator
Folder Administrator
Automation Express
Yes
All folders
Yes
Allow to be Automation User
Automation User
### Troubleshooting
#### The Not Found error
If an account was removed from the organization, when attempting to edit, enable/disable, or remove the account from Orchestrator (**Tenant** > **Manage Access**), a `Not found (#1002)` error is displayed.
In this case, the account in fact no longer exists and no longer has access to the UiPath products.
## Folder-level access control
In the tenant, access can also be controlled at folder-level from the **Folders** tab, used for managing folders and objects, and from the folder context, in the sidebar menu.
### Assigning objects to a folder
Go to **Tenant** > **Folders** tab, choose the folder, and click **Accounts & Groups**. Next, click **Assign** and select the object to be added to the folder.
:::note
You can also filter objects by category (all, user, group, robot account, external app).
:::
In order to assign the object, you are required to add a role to it. Once this is done, click **Assign**, and the object becomes visible in the list.
Another method to assign objects to a folder is to go to the folder context from the sidebar menu and click **Users** > **Assign**. In the search field, type the name of the object you want to add to the folder, select the roles it needs, and click **Assign** to finish the configuration.
### Editing access
To give specific folder access to assigned objects (groups, users, robot accounts, external apps), open a folder from the sidebar menu and go to **Users**. Next to the object for which you want to edit the folder access, click **More Actions** > **Edit role in this folder**. This brings up the assign page, where you can add or remove any roles for the selected object.
The same steps can be applied when going to **Tenant** > **Folder** tab > **Accounts & Groups** > **More Actions** next to the object you want to modify > **Edit role in this folder**. Now you can add or remove any roles for the selected object.
### Removing folder access
Go to **Tenant** > **Folders** tab, choose the folder, and click **Accounts & Groups**. Next to the object you would like to remove, click **More Actions** > **Unassign**. Once this is performed, the object no longer has access to that folder.
:::important
Accounts part of [account-machine mappings](https://docs.uipath.com/orchestrator/automation-cloud/latest/user-guide/configuring-account-machine-mappings#configuring-account-machine-mappings) that are employed in triggers cannot be deleted or unassigned from the folder in which the trigger resides. Make sure the account is not set as an execution target in a trigger to be able to delete it.
:::
### Subfolder access
A folder hierarchy can be established with up to 7 levels. This structure includes the top-level folder and allows for 6 additional layers of subfolders beneath it. In terms of user access, it is inherited from the parent folders. This means if you are assigned access to a folder, you automatically gain access to all of its subfolders.
:::important
Performance degradation and possible errors occur when loading the **Folder** selection menu for an account assigned to more than 1,000 folders.
:::
### Personal Workspace access control
When configuring attended robots for a group or a single user, you also have the option to create a personal workspace for it.
To configure this option, go to **Tenant** > **Manage Access** > select a user or group > **More Actions** > **Edit**. Under **Settings** > **UI Profile**, choose one of the following options:
* **None**: the user does not have access to the Orchestrator user interface.
* **Personal Workspace**: the user has access only to functionality specific to Personal Workspace .
* **Standard**: the user has access to the standard Orchestrator interface, based on their assigned roles and permissions.
:::important
If **UI Profile** is set to **None**, the user may be unable to access Orchestrator or may encounter a `“No access”` error. Check this setting if a user unexpectedly cannot access the Orchestrator UI.
:::
#### Personal Workspaces permissions
Tenant-level permissions required to manage the workspaces of other users:
* **Settings - View** and **Settings - Edit** to allow the use of personal workspaces in the tenant from the **Tenant** > **Settings** page.
* **Users - View** and **Users - Edit** to enable a personal workspace for a user or group by editing it from the **Manage Access** page.
Folder-level permissions required to use a personal workspace:
* **Alerts - View** to see alerts generated for the personal workspace.
* **Actions - View**,**Actions - Edit**,**Actions - Create**, and **Actions - Delete** to enable long-running workflow execution in the personal workspace.
* **Action Catalogs - View**,**Action Catalogs - Edit**,**Action Catalogs - Create**,**Action Catalogs - Delete** to allow the user to manage action catalogs in the personal workspace.
### Checking assigned roles
You can see what roles are assigned to an object (user, group, robot account, external app) from the following tenant-level locations:
* **Manage access** > **Assign roles** tab > select the object from the list > **More Actions** > **Check roles & permissions**
* **Manage access** > **Assign roles** > three-dots icon > **Check roles & permissions**
* **Robots** > select the account from the list > **More Actions** > **Check roles & permissions**
* **Monitoring** > **User sessions** > select the account from the list > **Check roles & permissions**icon
These options display the **View permissions** window, which is split between the **Tenant access** and **Folder access** sections. In turn, each section is made up of:
* The roles pane - includes the name of the role and its type (i.e. explicitly assigned or inherited).
* The permissions pane - lists the permissions included in the selected roles.
#### Tenant access
This section displays the roles and permissions granted at the tenant level. You can choose between these options:
* **All roles in this tenant** - the permissions pane displays all permissions corresponding to all roles granted to the selected entity at the tenant level.
* **Specific role** - the permissions pane only displays permissions corresponding to the selected role, as granted to the selected entity at the tenant level.
Figure 5. Tenant access 
#### Folder access
This section displays the roles and permissions granted at the folder level.
You can use the selection box to choose the particular folder for which to display the roles and their permissions. The list only contains folders where the selected entity is assigned.
If the selected entity has more than one role for the chosen folder, you can choose between these options:
* **All roles in this tenant** - the permissions pane displays all permissions corresponding to all roles granted to the selected entity at the folder level.
* **Specific role** - the permissions pane only displays permissions corresponding to the selected role, as granted to the selected entity at the folder level.
Figure 6. Folder access 
#### Recommended role-to-group mapping
The right combination of group and role allows you to correctly separate permissions, and give granular control to the appropriate people. To achieve this, we recommend the following role-group pairing:
Group
Has access to the Orchestrator interface
Has access to all folders/personal workspace only
Has API access
Tenant role
Folder role
Automation Users
No
Personal workspace Important: If a user is assigned to other folders via API, they also have access to those in addition to the personal workspace.
Yes
Allow to be Automation User
Automation User
Automation Developers
Yes
All folders
Yes
Allow to be Automation Developer
Automation Developer
Administrators
Yes
All folders
Yes
Orchestrator Administrator
Folder Administrator
Automation Express
Yes
All folders
Yes
Allow to be Automation User
Automation User