Managing access

Roles

Roles are a collection of permissions and represent a more granular layer for managing user access, following the broader option of maintaining access through groups. You can add roles to either groups so that all member accounts inherit them, or to individual accounts.

Roles can include several permissions at either the organization level, or at the service level, so there are:

• organization-level roles: these roles control the permissions that accounts have on organization-wide options; they are available in the Automation Cloud™ portal by default and you cannot change them, nor can you add new ones;
• service-level roles: these roles control the access rights and actions that accounts can perform in each UiPath® service you own; they are managed from within each service and can include default roles which you cannot change, as well as custom roles that you create and manage in the service.

Accounts and groups typically have an organization-level role and one or more service-level roles.

Groups and roles

In the following table you can see the roles that are assigned to accounts when they are added to a group. For example, adding an account to the Administrators default group grants them the Organization Administrator role for the organization and the Administrator role within your services. So this user can manage both organization-level roles from Admin > Accounts and Groups, as well as service-level roles.

Group Membership	Organization-level Role	Service-level Roles for Orchestrator
Administrators	Organization Administrator	Administrator
Automation Users	User	Automation User at folder level 1 Allow to be Automation User at tenant level
Automation Developers	User	Automation User at folder level 1 Folder Administrator at folder level 1 Allow to be Automation User at tenant level Allow to be Folder Administrator at tenant level
Everyone	User	No roles.
Automation Express	User	Allow to be Automation User at tenant level
[Custom group]	User	No roles by default, but you can add roles to the group as needed.

¹ The roles are assigned for the Shared modern folder, if it exists.

Note: For information about roles across UiPath services, see Role management .

Organization-level roles

Accounts can have only one organization-level role. This role controls the access that the account has to options within the portal area, such as the tabs they can see on the Admin page or the options available to them on the Home and Admin pages.

At organization level, the roles Organization Administrator and User are available.

You cannot change these roles or add new roles at the organization level.

Organization administrator

This role grants access to every organization- and service-level feature within the organization. An account with this role can perform all administrative actions for the organization, such as creating or updating tenants, managing accounts, viewing organization audit logs, and so on. There can be multiple accounts with this role.

Note: This is the only role that allows access to the Admin section.

The first organization administrator for any given organization is appointed when the organization is created.

To grant this role to others, the organization administrator can add user accounts to the Administrators group, which is one of the default groups .

The organization administrator role includes the following organization-level permissions, which cannot be changed:

	View	Edit	Create	Delete
Usage charts and graphs
Tenants
Accounts and groups
Security settings
External applications
Licenses
API keys
Resource center (Help)
Audit logs
Organization settings

User

This is the basic level of access within the UiPath ecosystem. Local user accounts automatically become members of the Everyone group , which grants them the User role.

This role is granted to all accounts that are in the default groups Everyone,Automation Users, or Automation Developers.

This role provides read-only access to pages, such as the Home page, Resource Center (if available).

They can see and access the provisioned services for their current tenant. However, the content they can see and the actions they can perform within each service depends on the service-level roles assigned to their account.

[Preview] Tenant-level roles

About tenant-level roles

Tenant-level roles control the access rights of accounts within the tenant settings and configuration area. They also define the permitted actions within each of the UiPath services in a given tenant.

Most of the tenant-level roles in the platform are cross-service roles as they grant permissions across multiple services within a particular tenant.

Currently, Tenant Administrator is the only role available at the tenant level.

Tenant Administrator role

The Tenant Administrator role allows you to effectively delegate responsibilities. The role grants access to manage all resources in the tenant, allowing operations such as role assignment, licensing management, and service provisioning.

The Tenant Administrator role can be assigned to multiple accounts.

Known limitations

Tenant-level roles are currently affected by the following known limitations:

• Only the following services support the Tenant Administrator role: Orchestrator (includes Actions, Processes, Integration Service), Data Service, Document Understanding, Task Mining, Test Manager. The rest of the tenant-level services are currently not supported, and users with only the Tenant Administrator role cannot access these services.

• The Tenant Administrator cannot access organization-level menus from the interface.

• On the Admin > Tenants > Services screen, the Tenant Administrator can view enabled services, but cannot add or remove services.

• On the Admin > Tenants > Manage access screen, the Tenant Administrator can view tenants they do not administer. However, if they access these tenants, they cannot perform any actions.

Service-level roles

Service-level roles control access rights and permitted actions within each of your UiPath services, such as the Orchestrator service, or Data Service. The permissions for each service are managed within the service itself, not from the organization Admin page.

To grant permissions for a service to accounts, you can do the following:

• Assign service-level roles to a group to grant those roles to all member accounts - you do this in the service;
• Add accounts to a group that already has the required service-level roles - you do this from Admin > Accounts and Groups;
• Assign roles to an account - you do this in the service.

Role management

You can manage and assign service-level roles from within each service and you need the appropriate permissions in the service.

For example, users with the Administrator role in Orchestrator can create and edit roles, and assign roles to existing accounts.

There are two ways to assign roles to an account:

• Direct provisioning implies manually assigning roles to an existing account. You can do this by adding the account to a group, by assigning service-level roles to the account directly, or a combination of both.
• Auto-provisioning is only applicable if your UiPath organization is integrated with a third-party identity provider (IdP), such as Azure AD). In this case, to fully hand off identity and access management to the external provider, you can set up the UiPath platform so that any directory account can receive the appropriate roles without the need for any actions in the UiPath platform. The IdP administrator then has control over a user's access and rights in the UiPath organization by creating and configuring the account in the external provider alone.

Direct provisioning

Assigning organization-level roles

Organization-level roles are predefined and cannot be changed.

Organization administrators can assign organization-level roles to individual accounts from Admin > Accounts and Groups by adding accounts to a default or custom group.

Note:

If you have linked your UiPath organization to a directory, such as Azure Active Directory (Azure AD), then it is possible to also assign organization-level roles to directory groups by adding them to groups, same as with accounts. This is not possible with local groups.

[Preview] Assigning tenant-level roles

Tenant-level roles can be set at tenant level and can have granted permissions up to the service level.

Organization Administrators or other Tenant Administrators can use the Manage Access screen to assign tenant-level roles. Note that while Organization Administrators can access Manage access in any tenant, Tenant Administrators can access it only in the tenant they manage.

To view the tenant-level role definition and the permissions granted at tenant and individual service level, go to Manage Access, then in the Roles tab select the View button next to the role.

You can assign a tenant-level role to a user, group, robot account, or external application. To assign the role, go to Manage access, then in the Role Assignments tab search for the account you want to assign the role to, choose the appropriate role, then select Assign.

[Preview] Tenant Administrator role visibility at service level

The Tenant Administrator role assignment is visible both at tenant and individual service level. At the service level, the Tenant Administrator role has the following properties:

• It is shown with a platform role label.

• It is immutable, implying that you cannot remove the assignment at the service level.

• In some services, such as Orchestrator, there is a link next to the role that redirects you to the Manage access page at platform level, where you can change the tenant-level role assignments.

Managing service-level roles

You manage and assign service-level roles from within the services. You can assign roles to groups (recommended), or to accounts that have already been added.

For information and instructions, see the applicable documentation:

Service	Details
Orchestrator	Managed from Orchestrator. Learn more about roles.
Actions	Managed from Orchestrator. For the list of permissions required, see Roles and permissions . For instructions on assigning roles, see Assigning roles.
Processes	Managed from Orchestrator. For the list of permissions required, see Roles and permissions in the Action Center documentation. For instructions on assigning roles, see Assigning roles.
Automation Hub	Managed from Automation Hub. For more information about which roles are required and instructions for assigning them, see Role description and matrix .
Automation Store	Managed from Automation Hub. For more information about which roles are required and instructions for assigning them, see Role description and matrix .
AI Center	Managed from Orchestrator. For information about the roles required to use AI Center, see AI Center access control.
Data Service	Managed from Data Service. For more information and instructions, see User management . For instructions on assigning roles, see Managing access .
Document Understanding™	Managed from Document Understanding. For more information about which roles are required and instructions for assigning them, see Role-based access control .
Task Mining	Managed using Automation Cloud organization-level roles. For information about the rights that organization-level roles grant in Task Mining, see Managing access and roles in the Task Mining documentation.
Test Manager	Managed from Test Manager. For information and instructions, see User and group access management.

Assigning roles to an account

If you want to granularly control the access a certain account has in a service, but you don't want to add new roles to an entire group, you can explicitly add the account to the service and assign one or more service-level roles to it directly.

For information about the available roles and instructions, see the documentation for the target service, as described above.

Auto-provisioning

Through auto-provisioning, any directory account can be set up with access and rights for using the UiPath platform directly from the external identity provider (IdP).

Auto-provisioning requires a one-time setup after you enable an integration with a third-party IdP: Azure AD or other IdPs that are connected used SAML integration.