# Access control

> In Orchestrator, you use roles to control the level of access for users, groups, robot accounts, and external apps. On this page, we go over the notions you need to understand to effectively plan and implement your access control strategy:

In Orchestrator, you use roles to control the level of access for users, groups, robot accounts, and external apps. On this page, we go over the notions you need to understand to effectively plan and implement your access control strategy:

* **accounts and apps** (i.e. user accounts, robot accounts, external apps) which represent the identity used to access Orchestrator resources
* **roles**, which are assigned to accounts in order to grant them explicit permissions within the UiPath ecosystem
* **groups**, which are used to simplify account administration by granting the same access to multiple user accounts

Accounts are not created and managed in Orchestrator, only their Orchestrator roles and assignments are. Accounts are created by organization administrators and, once created, they can be assigned to a folder or tenant in Orchestrator.

## About permissions

Orchestrator uses an access-control mechanism based on roles and permissions. Roles are collections of permissions meaning that the permissions needed to use certain Orchestrator entities are assigned to roles.

Role-permissions and user-roles relationships allow for a certain level of access to Orchestrator. A user gets the permissions required to perform particular operations through one or multiple roles. Since users are not assigned permissions directly, but only acquire them through roles, permission management involves assigning appropriate roles to the user.

### Permission and role types

There are two types of permissions, as follows:

* Tenant permissions define a user's access to resources at the tenant level.
* Folder permissions define the user's access and ability within each folder to which they are assigned.

Two primary permission sets govern operations within folders:

* Folder permissions (tenant scoped):
  + allow a user to create, edit, or delete all folders within the entire tenant.
  + are typically granted to admins, or users responsible for managing the organization.
* Subfolder permissions (folder scoped):
  + allow a user to create, edit, or delete a particular folder they are assigned to, along with any subfolders under it.
  + offer more granular control, enabling users to manage specific folders without having control over the other folders in the tenant.

Based on the permissions they include, there are three types of roles:

* Tenant roles, which include tenant permissions, and are required for working at the tenant level.
* Folder roles, which include permissions to work within a folder.
* Mixed roles, which include both types of permissions. With mixed roles, for a global operation, only the user's tenant permissions are taken into consideration. For a folder-specific operation, if a custom role is defined, folder permissions are applied in favor of any tenant permissions present.
  :::note
  Mixed roles are no longer supported, and you cannot create new ones. If you have mixed roles, we recommend replacing them with a combination of tenant and folder roles to grant the required permissions.
  :::

The following resources are available to users, depending on the type of roles they have:

 <colgroup>
  <col/>
  <col/>
 </colgroup>
 
  
     Tenant resources  
     Folder resources  
  
 
 
  
   
      
         Alerts 
         Audit 
         Background tasks 
         Libraries 
         License 
         Machines 
         ML Logs 
         ML Packages 
         ML Skills 
         Packages 
         Robots 
         Roles 
         Settings 
         Folders 
         Users 
         Webhooks 
      

   
      
         Apps 
         Assets 
         Storage Files 
         Storage Buckets 
         Connections 
         Environments 
         Execution Media 
         Folder Packages 
         Jobs 
         Logs 
         Live streaming and remote control 
         Monitoring 
         Processes 
         Queues 
         Resource overwrites 
         Triggers 
         Subfolders 
         Action Assignment 
         Action Catalogs 
         Actions 
         Test Case Execution Artifacts 
         Test Data Queue Items 
         Test Data Queues 
         Test Set Executions 
         Test Sets 
         Test Set Schedules 
         Transactions 
      

  
 

### Permissions without effect

Typically, you can select all available permissions (**View**, **Edit**, **Create**, or **Delete**) for any permission, except for the following, which have no effect for the listed permissions, and, therefore, **you cannot edit them**:

 <colgroup>
  <col/>
  <col/>
  <col/>
 </colgroup>
 
  
     Permission type  
     Permissions  
     Unavailable permissions  
  
 
 
  
     Tenant  
    Alerts 
   
      
         Delete 
      

  
  
    &nbsp; 
    Audit 
   
      
         Edit 
         Create 
         Delete 
      

  
  
     Folder  
    Execution Media 
   
      
         Edit 
      

  
  
    &nbsp; 
    Logs 
   
      
         Edit 
         Delete 
      

  
  
    &nbsp; 
    Monitoring 
   
      
         Create 
         Delete 
      

  
 

This is because, for example, it is not possible to edit system-generated logs.

### Deciding which permissions to include

Each role is a combination of permissions which control the program areas and actions that accounts with the role can access.

**Example**: A role called **Infra**, which is intended for the person managing the VMs you use for automation, may include permissions such as **Machines - View**, **Machines - Edit**, **Machines - Create**, and **Machines - Delete**, as well as other permissions that are relevant for their job.

When creating or editing a role, you must review the list of available permissions and decide which ones to include or not. Here are some approaches that you can try:

* **Start from our default roles**: Orchestrator comes with default roles for the most common automation user types, such as the **Administrator** role, **Automation User**, and more. You can either use these roles, or duplicate the one that is closest to what you need, and then customize it.
* **Create a custom role**: When creating a role, you are presented with a list of all available permissions for the tenant or folder level, depending on the role type, and you must decide which ones to include or not.

#### Viewing permission information

While creating or editing a role, you can hover over the checkbox of a permission to see to which Orchestrator pages the permission allows access. The information can help you broadly decide if to include the permission or not.

Important:

* The functions of permissions can be more complex than only access to and abilities within the context of a page. When in doubt about what permissions are necessary for a task, check the documentation for that task for detailed permission requirements.For advanced users, you can also check the Orchestrator API Swagger, which includes information about the required permissions for each operation. For instructions see [Accessing the Swagger file](https://docs.uipath.com/orchestrator/v0/reference/api-references#accessing-the-swagger-file).
* The information that is displayed for each permission only covers Orchestrator pages. It does not cover pages or actions in other UiPath services. For example, you may see that no pages are blocked by the **ML Skills** permissions, meaning that the permission has no effect in terms of access to Orchestrator pages. But granting permissions for **ML Skills** is necessary for using UiPath AI Center<sup>TM</sup>. In this case, you must check the [AI Center documentation](https://docs.uipath.com/ai-fabric/v0/docs/ai-center-access-control) for more information about the **ML Skills** permissions.