Subscribe

UiPath Orchestrator

The UiPath Orchestrator Guide

Managing access and automation capabilities

On the Manage Access page you can define and assign roles as well as configure the automation capabilities of your accounts. In Orchestrator, you use roles to control the level of access a user should have.
On this page we go over the notions you need to understand to effectively plan and implement your access control strategy.

The level of access and the actions that your users can perform is controlled using two elements:

  • accounts, which establish the identity of a user and are used to log in to your UiPath applications
  • roles, which are assigned to accounts in order to grant them certain permissions within the UiPath ecosystem.

Accounts are not created or managed in Orchestrator, only roles and their assignments are.

About accounts


A user account is an entity with access-dependent capabilities whose view and control of Orchestrator rely on the assigned roles.

Users accounts for each organization are created and managed from the portal on the Admin > Users & Groups page, not from Orchestrator.

After a user account has been successfully added to the organization, you can grant them access-rights to Orchestrator services in two ways:

  • by adding them to groups so that they inherit the roles assigned to the group
  • by explicitly granting each user account access-rights at the service level.

The two are not mutually exclusive: you can use both to obtain efficient, granular control over the access in your organization.

For more information about managing accounts, see About accounts.

📘

: In modern folders, robot management is performed at the user level. See Managing accounts for details.

AD integration

An active directory (AD) referenced in Orchestrator makes its members potential Orchestrator users. The level of access for a directory account is configured in Orchestrator, either at the group level (directory group) or at the user level (directory user).

You can integrate with:

📘

Using an AD integration together with attended robots auto-provisioning and hierarchical folders allow for effortlessly setting up large deployments. See Managing large deployments for details.

Behavior

  • Adding a directory group creates a user group entity in Orchestrator for which you configure access rights as desired. This entry in Orchestrator serves as a reference to the group as found in AD.
  • When logging in, Orchestrator checks your group memberships. If confirmed, it automatically provisions your user account, and then associates it to the access rights inherited from the group. Inherited rights are only kept for the duration of the user session.
  • Auto-provisioning takes place the first time you log in. An auto-provisioned user account doesn't get deleted at log out as you might need the entry for audit purposes.
  • Changes made to group membership in the directory are synced with Orchestrator at every log in, or once every hour for active user sessions. If your system administrator changes your group membership from, say, the Administrators group to the Automation Developers group while you have an active session, the changes are interrogated by Orchestrator the next time you log in or, if already logged in, within the hour.
  • Groups in AD sync with Orchestrator, but changes made in Orchestrator do not affect user configuration in AD.
  • AD users whose inherited access-rights (from group memberships) cannot be determined behave like local users, meaning they rely solely on roles assigned to the user account.
  • The only way for you to configure access rights which persist between sessions, regardless of how group membership changes, is to directly assign the role to the user account in Orchestrator, as opposed to using groups to assign roles.

Known issues

  • The GetOrganizationUnits(Id) and GetRoles(Id) requests only return folders and roles explicitly set for an auto-provisioned user. The ones inherited from the group configuration can be retrieved through the /api/DirectoryService/GetDirectoryPermissions?userId={userId} endpoint.
  • Same goes for the user interface, where only explicitly-set folders and roles are displayed on the Users page. In contrast, inherited ones have a new dedicated location, the User Permissions window (Users > More Actions > Check Permissions).
  • Users do not inherit alert subscription settings from the parent group, nor do they receive any alerts by default. To have access to alerts, you are required to grant the corresponding permissions to the user explicitly.
  • 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 the Robot tray.
  • On certain browsers, logging in to Orchestrator using your AD credentials only requires your username. There is no need to also specify the domain. Hence, if the domain\username syntax does not work, try filling in the username only.

Audit considerations

  • User membership: User [username] was assigned to the following Directory Groups [Directory Groups the user inherits access rights from in the current session].
  • Auto-Provisioning: User [username] was automatically provisioned from the following Directory groups [Directory Groups the user inherits access rights from in the current session].

User types

Group

An entity that serves as a reference to the user group in Automation Cloud. A user group referenced in Orchestrator makes all group members potential Orchestrator users.
The membership of a user is set from Admin > Users & Groups.
User groups enable automatic access with the group permissions, based on users being added or removed from the group with no need to manage user permissions individually.
There are 5 default local groups: Administrators, Automation Users, Automation Developers, Automation Express, Everyone. All groups come with a default set of permissions in each new service you create. The out-of-the-box roles can be customized later on for each Orchestrator service.
If you need more than the 4 default groups provided by UiPath, you can create custom local groups. Unlike default local groups, custom groups need to be added manually in Orchestrator to ensure the correct mapping between the group membership of a user and the corresponding role in Orchestrator.

More about local groups.

A group's roles are passed on to any users that belong to the group, both auto-provisioned or manually-added. We refer to them as "inherited roles" as opposed to "directly-assigned roles" which can only be set per account.

📘

Remember

A user that belongs to multiple groups inherits access rights from all of them.
A user who belongs to multiple groups, and has been assigned roles directly as well, has the union of all the roles inherited from groups and directly assigned.
You don't need an explicit user account to log in to Orchestrator if you belong to a group that has been added to Orchestrator.
Inherited roles are dependent on the associated user group. If the group is deleted from the service, so are the inherited roles of that account.
Directly-assigned roles are not influenced by groups that the account is in. They persist regardless of the group state.

Example

Say I added John Smith to the Automation Users and Administrators user groups in my Automation Cloud organization.

  • The Automation User group exists in the Finance Orchestrator service
  • The Administrator group exists in the HR Orchestrator service
  • Directly assigned roles to John's account in both services as well.

John has the union of inherited and explicit rights for each service:

Service/RolesUser GroupsInherited RolesExplicit RolesOverall
### FinanceAutomation User
Tenant Level Roles Allow to be Automation User Allow to be Automation User Allow to be Folder Administrator Allow to be Automation User
Allow to be Folder Administrator
Folder Level Roles Automation User on Folder A
Automation User on Folder B
Automation User on Folder A
Automation User on Folder B
Folder Administrator on Folder A Automation User on Folder A
Automation User on Folder B
Folder Administrator on Folder A
### HRAdministrators
Tenant Level Roles Allow to be Folder Administrator Allow to be Folder Administrator Allow to be Folder Administrator
Folder Level Roles Folder Administrator on Folder D
Folder Administrator on Folder E
Folder Administrator on Folder D
Folder Administrator on Folder E
Folder Administrator on Folder F Folder Administrator on Folder D
Folder Administrator on Folder E
Folder Administrator on Folder F

User

According to the mechanism used for adding user accounts in Orchestrator, they can be classified into two categories:

Manually-added users

Users that have been manually added in Orchestrator and have been granted permissions explicitly either at the tenant level or at the folder level. Manually-added user accounts inherit group access rights if they belong to a group that has been added to that Orchestrator service as well.

Auto-provisioned users

Users that have been added to a local group and log in to Orchestrator. They can access Orchestrator based on the permissions inherited from the group. Once they log in to Orchestrator for the first time, they are automatically provisioned.

On the Users page, in the Roles column, you can see explicitly assigned roles for a user, be it manually added or auto-provisioned. Inherited roles are not displayed in this column.
You can check the entire permission set of a user, inherited ones included, by navigating to More Actions > Check Permissions > User Permissions window for that specific user.

Manually Added UserAuto-provisioned User
Inherits access rights
Can have explicit access rights
Cloud Portal is the central hub for user information
SSO

Robot

The Robot robotrobot user is automatically created when you manually deploy a Robot to Orchestrator. Robot users have the Robot role by default. This role grants your Robot access to multiple pages, making it able to perform various actions.

Permissions for managing users


To be able to perform various operations on the Users and Roles pages, you need to be granted the corresponding permissions:

  • Users - View - Displaying the Users and Profile pages.
  • Users - Edit - Editing user details and settings on the Profile page, and activating/deactivating users on the Users page.
  • Users - View and Roles - View - Displaying user permissions in the User Permissions window.
  • Users - Edit and Roles - View - Editing role assignments on the Manage Access > Assign Roles page.
  • Users - Create and Roles - View - Creating a user.
  • Users - View and Roles - Edit - Managing roles in the Manage Users window, opened from the Manage Access > Roles page.
  • Users - Delete - Removing a user from Orchestrator.

About roles


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, management of access rights involves assigning appropriate roles to the user. See Modifying the Roles of a User.

10811081

Permission types and role types


There are two categories of permissions:

  • 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.

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 for working 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:

Tenant ResourcesFolder Resources
Alerts
Audit
Background tasks
Libraries
License
Machines
ML Logs
ML Packages
ML Skills
Packages
Robots
Roles
Settings
Folders
Users
Webhooks
Assets
Storage Files
Storage Buckets
Connections
Environments
Execution Media
Folder Packages
Jobs
Logs
Monitoring
Processes
Queues
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

Assigning the different types of roles

The type of role is important because you assign roles differently based on their type:

  • If Activate Classic Folders is cleared under Tenant > Settings > General:
    You assign Tenant roles and Mixed roles from the Users page or from the Roles page.
    You assign Folder roles and Mixed roles from the Folders page or from the folder's Settings page.
  • If Activate Classic Folders is selected under Tenant > Settings > General:
    You assign any of the three types of roles from the Users page or from the Roles page.
    You assign Folder roles and Mixed roles from the Folders page or from the folder's Settings page.

Permissions without effect

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

Permission typePermissionUnavailable rights
TenantAlerts Delete
Audit Edit
Create
Delete
License Edit
Create
Delete
FolderExecution Media Edit
Logs Edit
Delete
Monitoring Create
Delete

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

Disabling concurrent execution

When a credential cannot be used more than once at a time (e.g., SAP), an administrator can restrict an account from simultaneously executing multiple jobs. Enabling the Run only one job at a time option at the account level restricts the account from simultaneously executing multiple jobs.

Updated 19 days ago


Managing access and automation capabilities


On the Manage Access page you can define and assign roles as well as configure the automation capabilities of your accounts. In Orchestrator, you use roles to control the level of access a user should have.
On this page we go over the notions you need to understand to effectively plan and implement your access control strategy.

Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.