To access your UiPath cloud environment, an Automation Cloud organization administrator must add your employees as users in the Cloud Portal. Then organization administrators can grant them the required permissions to access Automation Cloud services by adding them to user groups or, if needed, by explicitly assigning individual roles.
You can add users easily by sending an invitation link to their email address and having them sign up for a user-owned UiPath account. Or, if you have a Microsoft Azure or Office 365 subscription, you can also integrate Azure with Automation Cloud to use your Azure Active Directory.
Your organization can use one of the following models to create users in the Cloud Portal:
- The invitation-based model requires that you send an email invitation to users and they in turn create a UiPath account to accept the invite and sign in to Automation Cloud.
- The Azure Active Directory model lets you use your existing directory of users and also lets you benefit from the user management capabilities of Azure.
More about cloud identity and authentication
The identity of your users is verified in Automation Cloud, more precisely by the Cloud Portal, based on your organization directory. From here, based on user permissions assigned through roles and groups, they can access all your UiPath cloud services with only one set of credentials.
The below diagram describes the two identity models, how they work with the various user identities, and how federation can be achieved.
In the invitation-based model, identity management is performed on a user reference in the organization directory, while users remain in control of their accounts. But if integrated with Azure Active Directory (Azure AD), it's as simple as looking at the contents of your tenant directory in Azure AD, depicted below with an orange arrow. You can read more about each model in the following sections.
Organization administrators can chose the model to use for your organization by going to Admin > Users and Groups > Authentication Settings:
The invitation-based model (selected in the image above) is set by default for any new organization.
The invitation-based model allows you to enforce sign in with a chosen provider. For more information about this model, see Invitation-based Model with Enforced Sign In Option.
To switch to this model, go to Admin > Users and Groups > Authentication Settings, select one of the Enforce Sign In with... options, and then click Save.
After saving, users can only see the sign in option for the provider you selected. If they are already signed in using a different provider, they are asked to sign out and sign back in using the chosen provider.
If you have authorized external applications for your organization, tokens generated while using other providers remain valid, but any new tokens follow the enforced sign in policy.
To switch to the Azure AD model, see Setting Up the Azure AD Integration for instructions.
The API Access option (Admin > Tenants) is not available when using the Azure AD model.
If you have processes in place that use the information from the API Access window to authenticate API calls to UiPath services, you must register external applications to switch to using OAuth for authorization, in which case the information from API Access is no longer required.
To switch from the Azure AD model back to the invitation-based model...
- Log in as an organization administrator using a UiPath account. The options are not active otherwise.
- If you removed UiPath user accounts when you moved to the Azure AD model, invite all users to the organization so that users are created again for their UiPath accounts.
- Assign users to groups and, if needed, assign individual roles.
- Go to **Admin** > **Users and Groups** > **Authentication Settings** and select one of the other options.
- Click **Save**.
After saving, users must sign in with the UiPath account (new or existing) that they used to accept the invitation.
Depending on the model you are using, you create and remove users differently:
- invitation-based model: To add users to your organization, you invite users. You can manage their details and group memberships from the Cloud Portal, and remove them, if needed.
- Azure AD model: If integrated, Automation Cloud and your other cloud services can use the existing users and groups from Azure AD. But creating and deleting these users and groups should be done in Azure AD by your Azure administrator, not from the Cloud Portal.
User and group icons shown in Automation Cloud and in other services can help you figure out the type so you know how to manage a particular user or group.
Whichever model you choose, you can still manage user permissions for your UiPath cloud platform from the Cloud Portal and the UiPath services.
The process for creating a user is as follows:
Organization administrators must obtain the email addresses of users and use them to invite each user to join their organization. They can do this in bulk.
Each invited employee accepts the invitation by navigating to the link provided in the invitation email and creates a UiPath user account. They can:
- Use the invited email as a username and create a password.
- Use an existing account they have with Microsoft (personal, Azure AD-linked account, or Office 365 account), Google (personal or Google Workspace account), or their personal LinkedIn account to sign in to (or federate in to) their UiPath user account.
The ability to use one of the providers mentioned above is convenient for users who do not have to remember additional passwords. And using organization-owned accounts in Azure AD or Google Workspace lets you enforce organization sign-in policies.
- Organization administrators can now add users to groups and grant roles as needed so that users have the required access.
In this model you create users in the same way as in the invitation-based model: you issue an invitation to their email address and your users must create a UiPath account. The difference is that you can choose to enforce sign in using either Google or Microsoft.
So instead of seeing all sign in options, your users see only the one you selected. For example, here's what your users would see if you chose to enforce sign in with Microsoft:
They still use their UiPath account to sign in because the email address must match the one where the invitation was sent.
The integration with Azure Active Directory (Azure AD) can offer scalable user and access management for your organization, allowing for compliance across all the internal applications used by your employees. If your organization is using Azure AD or Office 365, you can connect your Automation Cloud organization directly to your Azure AD tenant to obtain the following benefits:
Automatic user onboarding with seamless migration
All users and groups from Azure AD are readily available for any Automation Cloud service to assign permissions, without the need to invite and manage Azure AD users in the Automation Cloud organization directory.
You can provide Single Sign-On for users whose corporate username differs from their email address, which is not possible with the invitation-based model.
All existing users with UiPath user accounts have their permissions automatically migrated to their connected Azure AD account.
Simplified sign-in experience
Users do not have to accept an invitation or create a UiPath user account to access the Automation Cloud organization. They sign in with their Azure AD account by selecting the Enterprise SSO option or using their organization-specific URL.
If the user is already signed in to Azure AD or Office 365, they are automatically signed in.
UiPath Assistant and Studio versions 20.10.3 and higher can be preconfigured to use a custom Orchestrator URL, which leads to the same seamless connection experience.
Scalable governance and access management with existing Azure AD groups
Azure AD security groups or Office 365 groups, also known as directory groups, allow you to leverage your existing organizational structure to manage permissions at scale. You no longer need to configure permissions in Automation Cloud services for each user.
You can combine multiple directory groups into one Automation Cloud group if you need to manage them together.
Auditing Automation Cloud access is simple. After you've configured permissions in all Automation Cloud services using Azure AD groups, you utilize your existing validation processes associated with Azure AD group membership.
While on the Azure AD model, you can continue to use all the features of the invitation-based model. But to maximize the benefits, we recommend relying exclusively on centralized account management from Azure.
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 includes 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 includes 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.
If you are using the Azure AD model, user and group icons are available in the Automation Cloud and Orchestrator pages where you manage users, groups, or roles to help you recognize the type of user account and the type of group.
- user tied to a UiPath account who signed in using basic authentication
- user tied to a UiPath account who signed in using SSO; also applies to users who have both a UiPath user account and an Azure AD account.
- user tied to an enterprise account who signed in using Enterprise SSO using the organization-specific URL.
- the group was created from Automation Cloud
- the group originates in Azure AD.
Updated 14 days ago