- Getting started
- Best practices
- Tenant
- About the Tenant Context
- Searching for Resources in a Tenant
- Managing Robots
- Connecting Robots to Orchestrator
- Storing Robot Credentials in CyberArk
- Storing Unattended Robot Passwords in Azure Key Vault (read only)
- Storing Unattended Robot Credentials in HashiCorp Vault (read only)
- Storing Unattended Robot Credentials in AWS Secrets Manager (read only)
- Deleting Disconnected and Unresponsive Unattended Sessions
- Robot Authentication
- Robot Authentication With Client Credentials
- SmartCard Authentication
- Audit
- Settings - Tenant Level
- Resource Catalog Service
- Folders Context
- Automations
- Processes
- Jobs
- Triggers
- Logs
- Monitoring
- Queues
- Assets
- Storage Buckets
- Test Suite - Orchestrator
- Other Configurations
- Integrations
- Classic Robots
- Host administration
- Organization administration
- Troubleshooting
Managing access
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.
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 | |
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. |
1 The roles are assigned for the Shared modern folder, if it exists.
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.
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.
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.
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.
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.
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 in the Orchestrator guide. |
Actions |
Managed from Orchestrator.
|
Processes |
Managed from Orchestrator.
|
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 example, you can add an account to the Orchestrator service .
For information about the available roles and instructions, see the documentation for the target service, as described above.
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.