Overview
latest
false
  • Introduction
    • About this guide
    • UiPath Glossary
  • Product lifecycle
  • Licensing
  • Delivery options
  • UiPath Platform
  • UiPath documentation
  • Troubleshooting
Banner background image
Overview
Last updated Apr 19, 2024

License management options

User license management

Note:

User license management is enabled by default for all organizations created after March 1, 2021.

You can enable or disable this option from organization settings.

Only enable user license management if:

Enabling user license management automatically sets the Enforce user authentication, disable robot key authentication security setting in Orchestrator. Any users who use robot key authentication can no longer connect their robots to Orchestrator until they switch to interactive authentication. This setting is incompatible with classic folders.

Important:

  • User license management is not available for standalone Orchestrator.

  • If you are now switching to secure authentication, this requires recompiling the workflows that use Orchestrator activities or make direct HTTP calls to the Orchestrator API utilizing 2020.10 activity packages or later.

User-based licensing gives a coherent representation between UiPath's commercial model (purchased SKUs) and the licenses available for distribution in an organization. User licenses are managed separately from service/unattended robot licenses and are not tied to a specific tenant - a user is licensed across multiple tenants in the organization.

This model helps you allocate licenses in the organization by providing licenses to a single user or to a group. Using groups lets the administrator allocate a number of licenses to all the members of the group on a first-come-first-served basis, instead of having to assign the licenses one-by-one.

Allocating user licenses

Group allocation

Group-based licensing is the recommended route for enterprises because license allocation is performed automatically through group allocation rules. Assigning licenses at the individual user level can make large-scale administration challenging.

To address those challenges, group-based licensing allows you to allocate one or more licenses to a group. The pool of licenses assigned to the group becomes available to all members of the group. Any new members added to the group can make use of those licenses.

Similarly, upon being removed from the group, a user loses the possibility to use such a license.

This eliminates the need for license management on a per-user basis.

Group allocation rules are configured by an administrator. Unlike explicit per-user license assignment, group allocation does not consume licenses but makes the pool of licenses available to the group members. Users consume licenses on a first-come-first-served principle within the limits of the number of licenses available for the group.

Direct assignment

Important: Direct assignment is not compatible with group allocation. If you use direct assignment, the user no longer benefits from any licenses inherited through group allocation.

Direct license assignment is recommended in the following cases:

  • to gain full control over a limited set of licenses or
  • to achieve licensing granularity while keeping access control easy using groups.

A: Say I want to keep access administration easy by providing predefined permissions for typical scenarios in my company while assigning particular licenses to a select few members.

Example

Mary is a member of the Automation Developers group. There is an allocation rule in place for this group allocating 10 RPA Developer licenses to it. As a member of the Automation Developers group, Mary would inherit one RPA Developer license. However, as an administrator, I want Mary assigned one of the RPA Developer Pro licenses available in the organization. To keep Mary's access-rights intact while giving them a more powerful license, I will leave her in the Automation Developers group and directly assign an RPA Developer Pro license.

B: Say I want to control what users in a group get assigned a particular license when I have a limited license pool and a much larger number of group members competing for them.

Example

There are 5 Test Developer Pro licenses allocated to the Automation Developers group consisting of roughly 100 members. To avoid relying on the first-come-first-served assignment principle and ensure the right license-user pairing, I will manually assign the license to the 5 users I want.

User license consumption

Named User

Multiuser

Direct assignment

  • A license is consumed as soon as it is assigned to the user.
  • A license is released if the administrator unassigns it from the user or the user is removed from the organization.

Users consume licenses on a first come, first served principle.

  • A license relevant to a desktop product like Studio or Assistant is consumed when the desktop application is started.
  • A license relevant to a web product is consumed at the first operation performed in the product that requires a license. This varies with each product.
  • A license is released if the user does not use any product/capability that may require a license. You must log out and close the application or browser for the license to be released and become available for the next user.

If a group allocation rule is removed or changed, the change applies to all users that belong to the group.

Group allocation

Users consume licenses on a first come, first served principle, within the limits of the number of licenses available to the group:

  • A license relevant to a desktop product is consumed when the desktop application is first started. (e.g., Studio, Assistant).
  • A license relevant to a web product is consumed at the first operation performed in the product that requires a license. This varies with each product.
  • A license is released if the user is removed from the group or organization.

If a group allocation rule is removed or changed, the change applies to all users that belong to the group.

Users consume licenses on a first come - first served principle.

  • A license relevant to a desktop product is consumed when the desktop application is started. (e.g., Studio, Assistant)
  • A license relevant to a web product is consumed at the first operation performed in the product that requires a license. This varies with each product.
  • A license is released if the user does not use any product/capability that may require a license. You must log out and close the application or browser for the license to be released and become available for the next user.

If a group allocation rule is removed or changed, the change applies to all users that belong to the group.

Multiple licenses per user

There can be scenarios in which one user inherits multiple licenses by group memberships. In this case, the user will consume only one of the licenses: the most powerful one. If that license type is not available, the user consumes the second most powerful.

Note: License power

The power of licenses is as follows, from most powerful to least powerful:

Automation Developer > RPA Developer > Citizen Developer > Attended > Action Center

Example: John Smith inherits an Automation Developer and Action Center license by group membership. John consumes the Automation Developer license, which is more powerful than the Action Center license.

Note:

If a user inherits licenses by group membership and gets one explicitly assigned, the explicitly assigned license takes precedence and overwrites the group license.

If an organization administrator explicitly assigns multiple licenses to a user, the user consumes all of them.

External or partner licenses

Partners that use the same license across multiple customer organizations may request enabling the External License functionality on the customer Organization. This way, partners are able to bring their own license and connect to the customer's Orchestrator services without utilizing from the Customer license pool.

This is only possible for developer SKUs and requires Studio to be activated with a standalone license key. Please reach out to our support team or your UiPath contact for more details on how to enable this functionality.

Legacy license management

This model is not recommended and all new organizations created after 1 March 2021 use the user licensing model by default.

If you disable the user license management model from the organization settings, the legacy license management model is used.

As opposed to user license management, the legacy license management model provides no clear separation between user and robot/service licenses in terms of management. User licenses and robot/service licenses are assigned on a per-tenant basis from the organization setting, and are further managed in Orchestrator. This brings a couple of limitations:

  • User licenses are tied to specific tenants, license reassignment between tenants only being possible through manual intervention from an administrator.
  • You cannot manage user licenses centrally.
  • User license management
  • Allocating user licenses
  • Multiple licenses per user
  • External or partner licenses
  • Legacy license management

Was this page helpful?

Get The Help You Need
Learning RPA - Automation Courses
UiPath Community Forum
Uipath Logo White
Trust and Security
© 2005-2024 UiPath. All rights reserved.