- Release notes
February 2022
You can now choose from a wider selection of plugins to store your Orchestrator credentials. BeyondTrust, a new credential store, is now integrated with Orchestrator. For configuration instructions, see Beyond Trust integration.
In this release, we ship a new robot authentication mechanism that uses the OAuth 2.0 framework as the basis for its authentication protocol, meaning unattended robots can connect to Orchestrator using a client ID - client secret pair generated via machine template objects. The client ID - client secret pair generates a token that authorizes the connection and provides the robot with access to Orchestrator resources.
Client credentials allow the UiPath Robot to access resources by using its own credentials, instead of impersonating a user. When the robot requests resources from Orchestrator, Orchestrator enforces that the robot itself has authorization to perform an action since there is no user involved in the authentication.
Client credentials require the UiPath Robot 2022.2 or higher.
As an exception to our typical release cadence, client credentials do not become available to Enterprise users one week after the Community release date. Instead, the feature will be shipped to Enterprise users alongside the 2022.4 enterprise release of the UiPath Robot.
We provide several default roles in Orchestrator to make access assignment for the main use cases easy and to serve as a functioning base for any new customer that is just starting with the environment. After getting familiar with the ecosystem and understanding your particular use cases for automation, you could edit these roles, or create new ones to suit your needs.
But the basics never go out of style. So we want to make sure that these roles remain available to you as they were intended - a standard.
For this reason, we have made several improvements to roles and permissions particularly in relation to the default roles for modern folders.
Default roles are available... by default
You no longer need to add the default roles to your tenant from the Orchestrator settings. Now they are available by default to any new tenants, or tenants who did not manually add them up to now.
The options for adding these roles from the tenant-level Settings page (General tab) have been removed.
Default roles are now read-only
You can no longer edit the default roles. You can view the permissions that they include, but you can no longer change the permissions.
If you need a custom version, you must create a new role with the required permissions.
Customized versions of default roles are renamed with "Custom"
If you have customized any of the default roles by changing the permissions, do not worry, they're safe. We have renamed all your customized roles as Role name - Custom so that you know which are the default ones and which are your customized ones.
For example, if you customized the permissions of the Automation User default role, now you have the following roles:
|
Role |
Origin |
Can edit? |
Can assign? |
Permissions |
|---|---|---|---|---|
|
Automation User |
System |
N |
Y |
Standard |
|
Automation User - Custom |
User-defined |
Y |
Y |
Custom |
Duplicate and customize roles
We have added a new option for roles that allows you to copy and customize one of your existing roles. This option is available for both default roles and customized roles, but not for mixed roles.
With default roles becoming read-only, this is the new way in which you can customize them if you like a default role, but want to make a few tweaks.
To use this option, go to Tenant > Manage Access > Roles, click 
(more options) at the right of a row, and select Duplicate & customize.
Role export and import
You can now export any of your existing roles to CSV format and, in that format, import them back to Orchestrator. This lets you reuse your carefully-crafted set of roles across organizations and across tenants.
You can now choose from a wider selection of plugins to store your Orchestrator credentials. HashiCorp Vault, a new credential store, is now integrated with Orchestrator. For configuration instructions, see HashiCorp Vault.
- Prevent queue items data tracing by deleting the value of the
SpecificContentkey via API. Use thePUT /odata/QueueItem({Id})endpoint with the type of payload described in our documentation.
After some recent back and forth in the area of queue triggers, we are readdressing the way queue triggers launch jobs with - what we hope to be the final and best - implementation of them all.
Problem statement: Whenever your queues contained fewer new items than items in progress, no jobs were launched despite robots being idle. This happened because the number of running jobs (actively processing queue items) would exceed the number of target jobs (jobs needed to process the new items).
Initial fix: Orchestrator accounted for both new and in-progress queue items when computing the number of target jobs, instead of only new items. Sounded good. Didn't work.
Brand new, shiny fix: Orchestrator accounts for new items when computing the number of target jobs, but looks at the number of pending jobs when deciding whether to launch a new job or not.
-
Say you have 2 new items in a queue, and 2 pending jobs exist => then no new jobs are launched.
-
Say you have 2 new items, and 1 pending job exists => then 1 new job is launched.
This ensures Orchestrator launches enough jobs to process all new items without going overboard.
This release ships with a new set of folder permissions for Connections. The permissions have no actual use for the time being, they are part of an upcoming feature.
- To help you identify misconfigurations at the job or trigger level, from now on, when starting a job or configuring a trigger, you can clearly see whether certain runtimes have been configured in the containing folder or not.
At the job level, only runtimes that have been assigned to machines in the folder are available for selection. Trying to select unassigned runtimes does not work and a tooltip explaining the behavior is displayed.
At the trigger level, runtimes that haven't been assigned to machines in the folder can be selected, but you can easily spot them by looking for a warning icon.
-
Previously, you could not use testing runtimes for remote debugging from Studio or when using dynamic allocation in Orchestrator. Both operations only allowed usage of non-production or unattended runtimes. With this release, you can do both with testing runtimes.
-
For Automation Cloud™ robots, starting a job with the Keep Account/Machine allocation on job resumption now means the job resumes on any machine from the same pool - so the same type of machine, not necessarily the exact same machine.
-
You can now filter the transactions of a queue by the Robot that processed the transactions. The dropdown menu of the Robot filter displays the robots present in the corresponding modern folder. To see the available robots, you need View permissions on Users.
- Occasionally, test set and test schedule executions failed with the following error:
System.Data.Entity.Core.EntityException: The underlying provider failed on Open.System.PlatformNotSupportedException: This platform does not support distributed transactions. Test sets and test schedules are now executed with no errors. - Previously, deleting an Orchestrator folder that contained an Azure storage bucket resulted in all data being hard deleted from Azure. As of now, upon deleting a folder, Orchestrator performs a soft delete that makes data unavailable to Orchestrator users, but leaves it available in Azure.
- 28 February 2022
- New Credential Store Now Available
- 25 February 2022
- OAuth 2.0-based Framework for Robot Authentication
- 24 February 2022
- Roles Improvements
- 22 February 2022
- New Credential Store
- Delete Queue Items Content Via API
- 7 February 2022
- New(er) Queue Triggers Mechanism for Launching Jobs Via Queue Triggers
- New Permissions Set
- Improvements
- Bug Fixes
