Account Types

The UiPath Identity Server stores local accounts and the roles assigned to them, but also validates any directory accounts used in Orchestrator.

Local User

An account that was created and can be managed from Identity Server, through the Management portal, is considered to be local to the UiPath ecosystem. For local accounts, all account attributes like name and email address are stored in Identity Server.

Directory User

User accounts that originate from a directory outside of the UiPath ecosystem (for example, from Azure Active Directory) are directory users. These accounts can access Orchestrator and can receive roles if you integrate with the directory.

For directory users, only role assignments and Orchestrator-specific settings are managed within the UiPath ecosystem, in Identity Server and Orchestrator, while the external directory admin manages account-specific attributes (name, email, directory group membership).

There are two ways to grant a directory user access to Orchestrator:

1. By assigning roles in Orchestrator to the directory user - we refer to it as an individually-added user.
2. By logging in with an account that belongs to a directory group which was previously added to Orchestrator - we refer to this as an auto-provisioned user. See About Users for more information.

Regardless of their type, directory users always inherit roles from the groups to which they belong, if they exist in Orchestrator.

Local Group

Local groups are entities originating in Identity Server which represent a collection of user and robot accounts. You can assign roles and licenses to groups as opposed to assigning them to individual users. Anything assigned to the group is automatically assigned to all group members.

Directory Group

An entity created by referencing a group from a linked directory in your Orchestrator instance. All members of the group are potential users of Orchestrator. All roles assigned to a group are inherited by the users that belong to that group, auto-provisioned or individually-added.

• A user who belongs to multiple groups inherits roles from all of them.
• A user who belongs to multiple groups, and has also been granted roles explicitly, has the union of all the roles inherited and explicitly assigned.

Using directory groups enables automatic access with the group permissions, based on users being added or removed from the directory group (when switching departments, for example) with no need to manage user permissions individually.

Example

Directory Groups	Inherited Rights	Explicit Rights
Added group X with X set of access rights and group Y with Y set of access rights.	John Smith belongs to both Group X and Y. He logs in to Orchestrator. His user is auto-provisioned with the following rights: X, Y.	In addition to the X and Y sets, John is also granted the Z set explicitly. John now has the following rights: X, Y, Z. Deleting groups X and Y leaves John with Z.

• 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 Directory Group. If the directory is deleted, so are inherited access-rights.
• Explicitly-set access rights are independent of the Directory Group. They persist between sessions, regardless of the group's state.

Robot

Robot Accounts

Robot accounts are helpful for when you need to run back-office unattended processes that should not be the responsibility of any particular user. These are our RPA-specific equivalent of service accounts. Similar to the accounts that Windows services run as application identities in the OAuth model, they are a non-user identity to be used to run unattended processes.

Working with robot accounts

Robot accounts behave like user accounts in terms of permissions. In UiPath Orchestrator, you can add robot accounts and configure permissions for them in the same way as for any other account.

The only differences compared to user accounts are:

• robot accounts are not allowed any interactive-related process configuration
• no email address is required to create a robot account.

You can find and work with robot accounts in broadly the same way as you work with user accounts:

• Administrators can create and manage robot accounts from the Admin > Accounts & Groups page - except not from the Users tab, but from the dedicated Robot accounts tab.

  Robot accounts can also be included in groups and managed as part of the group.

• When assigning roles in Orchestrator, searching for accounts shows users, groups, and also robot accounts for selection.

Robot Entity (deprecated)

Note: This only applies for classic folders.

For classic folders, when you manually deploy a robot to Orchestrator, a robot entity is automatically created, viewable on the Robots tab.

Robot users have the Robot role assigned to them by default.

Service Account

A service account is a non-human account used to provide a security context for running workloads which don't involve the existence of a human account, such as server-to-server authentications. In these cases, Orchestrator assumes the identity of the service account.

Only one service account is created per Orchestrator instance it is not visible in the user interface, and can only be identified in database tables.

There is no authentication information attached to this type of account, and, as such, it cannot log in interactively via browsers or cookies.

We recommend not to disable or delete the service account, as this will have a direct impact on running workloads.