The UiPath cloud identity system is modeled around a user-controlled UiPath user account. In this model, administrators are required to invite users to join their organization. To create an invitation, administrators must specify an email address. To accept an invitation, a user must navigate to the invitation link provided in their email and sign up for a UiPath user account.
The UiPath user account can be created by directly using the invited email as a username and creating a password. Alternatively, a user can decide to use an existing account they have with Microsoft (personal or Azure AD/Office365), Google (personal or GSuite), and LinkedIn to sign in (or federate) into their UiPath user account. The ability to use one of the providers mentioned above is convenient as users do not have to remember additional passwords. Additionally, organization owned accounts in Azure AD or GSuite ensures organization sign-in policies are enforced.
While users control their UiPath user account, administrators control their organization by managing its user references. When an administrator invites a user, an organization-specific user reference is created in their Automation Cloud organization’s directory. After a user accepts an invitation, they can use their UiPath user account to sign in (or federate) into the organization’s user reference. The user will then have access to resources that have been assigned to their user reference in the specified organization. Administrators can use these user references to control which users are allowed in their organization and what permissions they are granted.
Organization level roles enable you to control user access within the Cloud Portal. Based on their roles, users can or cannot perform actions or view information within the portal.
All invited users have access to all the services within an organization. However, the level of access for each user is determined by their roles within each specific service. See Service Level Roles for more information.
The following 2 roles are available for the users at organization level:
This role grants access to every organization or service level feature. A user with this role can perform all administrative actions at organization level, like creating or updating tenants, managing users, viewing audit logs, and so on. There can be multiple users with this role. All users within the Administrator group are granted this role. Click here for information about user groups.
It has the following permissions, which cannot be changed.
Usage Charts & Graphs
This is the default role assigned to people invited to join the organization. This role grants read-only access to some Cloud Portal functionalities, such as Resource Center, Licenses, Users or Tenants. All users in the Automation Users, Automation Developers and Everyone groups are granted this role. Click here for information about user groups.
The role has the following permissions which cannot be changed.
Usage Charts & Graphs
Service level roles control access rights within each service. The permissions for each service are managed within the service itself, and not in Cloud Portal. You can explicitly assign a role for every user or you can use user groups.
User groups are used to simplify access administration. Access rights assigned to a group are automatically inherited by all users in that group. A user gets the union of all permissions assigned to the groups they are a member of.
The group membership of a user is managed in Cloud Portal. User group permissions are configured in each individual service. For example, learn about users and user groups in Orchestrator services.
Adding users to a group grants them access to all services which reference that group. The level of access to a service/folder is determined by the roles assigned to that group in the service.
- When a user tries to access certain services, the system makes an access-permit decision depending on the user's membership.
- When a user tries to access or use certain resources in a service, the system makes an access-permit decision based on the roles of the user, which can be either inherited from the group or granted explicitly.
Tenant Level Roles
Folder Level Roles
Orchestrator > Tenant Context > Users Page
Orchestrator > Tenant Context > Folders Page
Default groups reduce the need to specify explicit access rights by providing predefined permissions for typical scenarios.
UiPath provides 4 default user groups that come with a default set of roles each at the service level: Administrators, Automation Users, Automation Developers, Everyone. These groups are automatically referenced in newly created Automation Cloud services, and they are configured with a set of default permissions. Note that, for services created before the user groups feature was launched, the permissions are not changed. Service administrators can configure permissions for these groups as they desire.
If you need more than the 4 access levels provided by default by UiPath, you can create and tailor your own user groups. Unlike default user groups, custom groups need to be added manually in the service to ensure the correct mapping between the group membership of a user and the corresponding role in the service.
User roles can be changed at the service level by users with corresponding permissions.
For example, users with the Orchestrator Administrator role can create additional roles or modify existing ones if needed.
Read more about Orchestrator roles here. The following table has the mapping between group memberships, organization level roles, and Orchestrator service level roles:
Organization Level Role
Orchestrator Service Role
No default role.
No default role.
1 Note that the roles are assigned at Shared modern folder level if it exists.
If you want to granularly control the access a user has in a certain service, say without adding the entire group to the service, you can add them explicitly.
Read here how to add a user in an Orchestrator service.
If you don't want to work with user groups and preserve past behavior, assign your users to the Everyone group. This way, they are granted User role within Cloud Portal, and no role whatsoever within each of your services. To grant them service level roles, assign them explicitly the desired roles within each service.
Updated 13 days ago