Subscribe

UiPath Orchestrator

The UiPath Orchestrator Guide

Overview


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

Adding users is managed in Cloud Portal for each organization. Once a user has been successfully added to the organization, there are two ways of granting them access-rights to Orchestrator services: through user groups that pass on their access-rights to any member, or by explicitly granting each user access-rights at the service level. The two are not mutually exclusive as you can use both for efficient, granular control over the access in your organization.

📘

Note

You cannot add users to an Automation Cloud organization directly from Orchestrator. Users must be added to Cloud Portal first such that you are able to configure their permissions in Orchestrator.

See here details on how to add users in the portal.

  1. Adding a group creates a user group entity in Orchestrator for which you configure access rights as desired. This entry serves as a reference to the group as found in Automation Cloud.
  2. When logging in, Orchestrator checks your group membership in Automation Cloud. If confirmed, it automatically provisions your user, and then associates it to the access rights inherited from the group. Inherited rights are only kept for the duration of the user session.
  3. Auto-provisioning takes place the first time you log in. An auto-provisioned user doesn't get deleted at log out as you might need the entry for audit purposes.
  4. Changes made to group membership 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 once every hour or the next time you log in.
  5. The only way for you to configure access rights which persist between sessions, regardless of how group membership changes, is to set them up explicitly per user in Orchestrator. We refer to them as explicit access-rights.

  • The GetOrganizationUnits(Id) and GetRoles(Id) requests only return folders and roles explicitly set for an auto-provisioned user.
  • Same goes for the user interface, where only explicitly-set folders and roles are displayed on the Users page, while inherited ones have a new dedicated location, the User Permissions window (Users > More Actions > Check Permissions).
  • Auto-provisioned users do not inherit alert subscription settings from the parent group, nor do they receive any alerts by default. In order to have access to alerts you are required to explicitly grant the corresponding permissions to the user.
  • Removing a user from a group does not remove the license of an associated user, even if the removal unassigns the user from any folder. The only way to release the license is to close the Robot tray.

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 in Cloud Portal.
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 4 default user groups in Cloud Portal: Administrators, Automation Users, Automation Developers, Everyone. All groups come with the 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 levels provided by UiPath, you can create and tailor custom user groups. Unlike default user 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.

Click here for details about user groups in Cloud Portal.

Access rights of a group are passed on to any users that belong to that group, auto-provisioned or individually-added. We refer to them as "inherited access rights" as opposed to "explicit access rights" which can only be set individually per user.

📘

Remember

A user that belongs to multiple groups inherits access rights from all of them.
A user which belongs to multiple groups, and has been granted access rights explicitly as well, has the union of all the rights as inherited from parent groups, and explicitly-set.
You don't need an explicit user entry to log in to Orchestrator if you belong to a group that has been added to Orchestrator.
Inherited access rights are dependent on the associated user group. If the group is deleted from the service, so are inherited access rights of that user.
Explicitly-set access rights are independent of the user group. They persist regardless of the group's 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
  • Granted John explicit access rights in both services as well.

John has the union of inherited and explicit rights per each service. See below an example.

Service/Roles

User Groups

Inherited Roles

Explicit Roles

Overall

Finance

Automation 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

HR

Administrators

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 them in Orchestrator, users 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 users inherit group access rights if they belong to a group that's been added to that Orchestrator service as well.

Auto Provisioned Users

Users that have been added to a group in Cloud Portal 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 User

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

The Robot role grants your Robots access to multiple pages, making it able to perform various actions. See here the exact permissions of the Robot role.

Disabling Concurrent Execution

Optimizing resource consumption and maximizing execution capacity in modern folders involves little to no control over how users are allocated to jobs. For scenarios where a credential cannot be used more than once at a time (e.g., SAP), we've introduced the possibility to limit concurrent unattended execution. This helps modulate the job allocation algorithm by restricting a user from simultaneously executing multiple jobs.

Audit Considerations


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

Admin Users


Users added to the Administrators group in Cloud Portal receive the Administrator role in Orchestrator, meaning that any user added to the group becomes an administrator of all Orchestrator services. Users with the Administrator role can activate, deactivate, and remove other users as well as edit information, including the password.

You cannot delete users having the Administrator role.
You can not deactivate nor delete the user you are currently logged in with.

Users Permissions


In order to be able to perform various operations on the Users and Profile pages, you need to be granted the corresponding permissions:

  • View on Users - Displaying the Users and Profile pages.
  • Edit on Users - Editing user details and settings on the Profile page, and activating/deactivating users on the Users page. Configuring the Alerts section on the Profile page requires the corresponding View permissions per alert category. Details here.
  • View on Users, View on Roles - Displaying user permissions on the User Permissions window.
  • Edit on Users, View on Roles - Editing user details and settings on the Users page.
  • Create on Users, View on Roles - Creating a user.
  • View on Users, Edit on Roles - Managing user roles on the Manage Users window, in the Roles page.
  • Delete on Users - Removing a user.

Read more about roles.

Updated 3 months ago



Users


Suggested Edits are limited on API Reference Pages

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