2022.4

Release date: 9 May 2022

What’s New

Organizing Resources With Tags

We know it can be quite a pain to categorize resources and we recognize the importance of having everyone in your company easily see the dependencies between these resources and know how to use them together. Changing an asset or deleting a queue, for example, could impact running processes and, unbeknownst to you, cause them to crash.

As your robot fleet grows, the number of resources to consume and manage expands. This can cause your business to run into some significant challenges, which include:

difficulties in figuring out how the various objects work with each other;
increased manual workload: you need to come up with cumbersome workarounds to categorize and track the dependencies between objects, such as Excel spreadsheets;
no visibility into how your actions could impact other resources, such as running processes;
no visibility into the potential downtime brought by upgrading an application targeted by your automations, since there’s no easy way to see what processes are employing that app.

Tags come to your aid in a number of areas:

Increasing developer productivity: Help developers identify which resources are relevant for them. They become able to focus on adding value rather than spending an infinity looking for that one piece of process they might be impacting.
Increasing administrator productivity: With a consistent tags structure across your organization, you can start creating a unified taxonomy that will help everyone find resources faster.

Tagging is currently available for several Orchestrator resources and Action Center actions. See the list of taggable objects.

Note: This feature works with Studio 2022.4+.

Known issue

Set Asset and Set Credentials activities version 2021.4 or lower remove tags from assets.

Installation & upgrade considerations

This functionality is available as part of the Resource Catalog via both on-prem delivery methods: Automation Suite and standalone.

For Automation Suite, there's no need to worry about the installation and configuration of this new service, as it all happens behind the scenes.

As for standalone Orchestrator, if you opt for an Azure App Service installation, there are a couple of additional steps you need to take to make sure you benefit from the goodies brought about by Resource Catalog. We have introduced two new scripts to help you with that: Publish-ResourceCatalog.ps1 and MigrateTo-ResourceCatalog.ps1. For more details, see Azure App Service Installation.

Global Tenant Search

We've added a global search functionality that lets you search for resources in a tenant. It looks for both folder-scoped resources and tenant-scoped resources in that tenant. Currently, the search works for queues, assets, buckets, machine objects, processes, triggers, and action catalogs.

To access it, select the Search icon in the upper-right corner of any page.

Known Issue:

Editing objects from the global Search page incorrectly requires View permissions on Folders or View on Subfolders.

OAuth 2.0-based Framework for Robot Authentication

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.

More on robot authentication.

Instructions for administrators on how to manage client credentials (create new credentials, revoke access).

Instructions for RPA developers and attended users on how to connect their robots to Orchestrator.

Machine Keys for PW Templates No Longer Visible

Machine keys for personal workspace machine templates are no longer visible, neither via API nor in the Orchestrator user interface. What this means for you is you have to sign in to connect your robot to Orchestrator.

Removing Disconnected and Unresponsive Unattended Sessions

From now on, you can keep Orchestrator free from clutter by removing disconnected or unresponsive unattended sessions. This operation allows the cleanup of unused sessions and helps provide relevant insights to administrators by only showing connected sessions.

To remove the unattended sessions one by one, navigate to Tenant > Robots > Unattended sessions and, for the disconnected session you wish to remove, click More actions > Remove. To remove multiple sessions simultaneously, select the sessions and then click the Remove icon.

To delete all unattended sessions older than 60 days from your Sessions table, you can use the database maintenance scripts provided in the official documentation.

Database maintenance for Orchestrator in Automation Suite
Database maintenance for standalone Orchestrator

More about how to delete disconnected or unresponsive unattended sessions.

New Credential Stores Are Available

You can now choose from a wider selection of plugins to store your Orchestrator credentials. Three new credential stores are now integrated with Orchestrator: HashiCorp Vault, BeyondTrust, and Azure Key Vault (read-only).

S3 Compatible Storage

Plug and play your S3 compatible storage with Orchestrator and take advantage of all its unique benefits: scale, cost, and reliability.

Learn how to enable S3 compatible providers for creating storage buckets in Orchestrator.

Learn how to create and configure storage buckets.

Custom AIMWebserviceName

From now on, you can give a custom name to the Central Credential Provider web service. This is possible with the help of the new Web Service Name field, which is available when configuring a CyberArk CCP credential store. Leaving this field empty means the default name is used: AIMWebService.

Azure AD for SQL Server

We once again come bearing gifts for those of you who have installed Orchestrator on an Azure VM or Azure App Service: we now offer support for Azure AD. You can use this authentication method to connect Orchestrator to SQL Server. For details, see our documentation.

SAML Integration at Organization Level

The integration allows you to connect Automation Suite to any third-party identity provider (IdP) that supports the SAML 2.0 standard - like Okta or PingOne, to name a few.

The integration was already available at the host level, but now you can also enable it at the organization level.

About the SAML authentication model | Configuring the SAML integration (for organizations)

Important: Erratum 22 June 2022: A new parameter, -NoAzureAuthentication, has been added to the Orchestrator script, the Identity Server scripts, the Webhooks scripts, and the Resource Catalog scripts. It allows you to publish to the Azure App Service under your own identity, without having to create a service principal.

Improvements

Monitoring

Monitoring folder resources from a centralized location

From now on, you can keep an eye on the health and state of the resources in all your folders from a centralized location at the tenant level. The new Monitoring page allows you to visualize data in your system via a collection of dashboards that are grouped together based on a certain dimension, such as machines.

The new functionality should be quite familiar to you; its looks and behavior are based on its folder-scoped counterpart. This is not a coincidence, because tenant monitoring dashboards display aggregated data from all folders and personal workspaces to which you have access.

Bringing together all monitoring functionality in one place also required us to do a little reorganization of the Orchestrator UI, so here's a list of the things that have been relocated to the new tenant monitoring page:

Unattended sessions and User sessions pages (originally on Tenant > Robots);
Robot usage widget (originally on Tenant > License).

New filtering options when monitoring processes

Now, when monitoring processes, you have the possibility to filter the data by bigger time intervals: 1 month (last 30 days) or 1 week (last 7 days). Previously, you could only filter by the last hour or last day.

Persisting filters

Previously, Orchestrator did not persist selected filters on Monitoring dashboards. This could prove wasteful, since you had to redo the configuration every time you switched tabs. You can now navigate away from the dashboards and find the same filter configuration applied upon returning.

Automations

Prevent pending jobs from piling up in Orchestrator and set a strategy to automatically stop or kill their job execution. The option to schedule when a job execution ends is now available on the Start job and Queue trigger pages, in addition to the Time trigger page.

Learn more about the Schedule ending of job execution option in our documentation about managing jobs and queue triggers.
You can now filter queue transactions by the robot (that is, user or robot account) that processed them. 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.

Hostname Mapping for Triggers

Recently introduced in triggers, the account-machine-hostname mapping allows you to select a specific machine from a template to schedule your job execution. Why would you need to select a hostname? Because that specific hostname (that is, workstation) has the resources - licenses, software, user configuration, permissions - required by your job to execute smoothly. You can select a hostname for your trigger as part of the trigger execution target, and have it either dynamically allocated or manually mapped in a valid account-machine mapping, in a similar way you choose a hostname for jobs.

However, there are a couple of twists in selecting a hostname for triggers:

you can select any available hostname of the template, whereas in jobs you can select only connected machines.
you can duplicate an existing trigger and add a hostname to it, thus doubling the number of jobs queued for execution.

Complete Process Creation Flow

Until today, to execute a newly created process, you went to the Jobs or Processes page; to schedule a trigger for the same process, you went to the Triggers page.

No need to wander between Automations pages anymore, as now you have the option to finalize a process creation in a single flow: after creating the process, you can start the job or create the trigger with one click.

Encryption

In a continuous effort to keep your data safe, starting with this release, we encrypt all types of newly created assets by default. Additionally, you now have the option to encrypt newly created queues and actions linked to newly created action catalogs. However, the encryption is not applicable retroactively.

The following columns are encrypted in the corresponding database tables:

Database table

Encrypted columns

Encryption method

QueueItems

Specific Data

Output

Optional via UI

Creating a queue

AssetValues

Value

By default

Tasks

(i.e., actions)

Data

(i.e., action catalogs)

Optional via UI

Adding a new Action Catalog

Roles and Permissions

We provide several default roles in Orchestrator to make it easy to assign access for the main use cases and to serve as a functioning base for any new customer that is just starting out 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.

Role name changes

Longer role names

We have increased the maximum number of characters allowed for role names from 32 to 64 characters.

Customized versions of default roles are renamed with "Custom"

If you have customized any of the default roles by changing their 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

Tenant Administrator is now Orchestrator Administrator

To better describe the scope of rights included with this default role, we have renamed the Tenant Administrator role to Orchestrator Administrator.

This role is also impacted by the rename of customized default roles:

Orchestrator Administrator: the read-only default role that was previously named Tenant Administrator.
Orchestrator Administrator - Custom: your customized version of what was the Tenant Administrator role, if you changed the base permissions of the default role in any way.

Note: If you happen to have a custom role named Orchestrator Administrator, that role is also renamed as Orchestrator Administrator - Custom.

Impact to your current setup

Existing role assignments are not impacted. Although your custom roles now have a new name, any accounts or groups associated to the affected roles were assigned now have the renamed version assigned to them. So there is no action that you need to take following this change. Everything works as usual.
API requests that use role names need to be updated. See API: Requests that include role names below, in the Breaking Changes section.

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 to 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. Find out how to export and import a role.

Permissions without effect are now deselected and grayed out

When editing a role, you can no longer select or deselect permissions that grant no abilities, such as Logs - Edit. These permissions, which have no effect, are now deselected by default and grayed out in the interface.

API: New endpoint for assigning roles

A new endpoint is now available in the Orchestrator API for assigning roles or overwriting the assigned roles for an existing account:

POST /odata/Users({key})/UiPath.Server.Configuration.OData.AssignRoles

This endpoint is improved compared to our existing Users endpoints because it assigns roles based on the role ID as opposed to the role name, making it more reliable.

You can find the new endpoint in the Swagger of the Orchestrator API, available at <OrchestratorURL>/swagger.

Actions and Action Catalogs permissions

All permissions for Actions and Action Catalogs are configured as default for personal workspace administrator roles. Now, you can execute long-running workflows (that is, orchestration processes) from your personal workspace folder.

API

For auditing purposes, we have added the necessary properties to several resources DTOs, hence to the response bodies of the following endpoints:
- /odata/Users
  
  "LastModificationTime": "2021-10-12T07:29:25.914Z", "LastModifierUserId": 0, "CreatorUserId": 0
- odata/Robots
  
  "LastModificationTime": "2021-10-12T07:32:24.940Z", "LastModifierUserId": 0, "CreationTime": "2021-10-12T07:32:24.940Z", "CreatorUserId": 0
- odata/Releases
  
  "LastModificationTime": "2021-10-12T07:29:25.914Z", "LastModifierUserId": 0, "CreatorUserId": 0
- odata/Assets
  
  "LastModificationTime": "2021-10-12T07:57:15.145Z", "LastModifierUserId": 0, "CreationTime": "2021-10-12T07:57:15.145Z", "CreatorUserId": 0
- odata/Libraries
  
  "Created": "2021-10-12T07:59:04.182Z", "LastUpdated": "2021-10-12T07:59:04.182Z", "Owners": "string", "IconUrl": "string", "Summary": "string", "PackageSize": 0, "IsPrerelease": true, "LicenseUrl": "string", "ProjectUrl": "string"
Prevent queue items data tracing by deleting the value of the SpecificContent key via API. Use the PUT /odata/QueueItem({Id}) endpoint with the type of payload described in our documentation.

Endpoints deprecations

As vacation season approaches, our API collections get decluttered. We have several deprecated endpoints, but worry not, as we provide replacements for them. Check the Swagger description to see the replacements and make sure you replace the deprecated endpoints in your client as well, to prevent failures. Here is the list of deprecated APIs and their replacements:

Logs

Deprecated	Replaced with
POST `/api/Logs`	POST `/api/Logs.SubmitLogs`

Assets

Deprecated	Replaced with
GET `/odata/Assets/UiPath.Server.Configuration.OData.GetRobotAsset(robotId='{robotId}`	`/odata/Assets/GetRobotAssetByNameForRobotKey`

OrganizationUnits

Deprecated	Replaced with
GET `/odata/OrganizationUnits`	GET `/odata/Folders`
POST `/odata/OrganizationUnits`	POST `/odata/Folders`
GET `/odata/OrganizationUnits({key})`	GET `/odata/Folders({key})`
PUT `/odata/OrganizationUnits({key})`	PUT `/odata/Folders({key})`
DELETE `/odata/OrganizationUnits({key})`	Replace with: DELETE `/odata/Folders({key})`
POST `/odata/OrganizationUnits({key})`	POST `/odata/Folders.AssignUsers`
GET `/odata/OrganizationUnits/UiPath.Server.Configuration.OData.GetUsersForUnit(key={key})`	GET `/odata/Folders.GetUsersForFolder`

Settings

Deprecated	Replaced with
GET `/odata/Settings/UiPath.Server.Configuration.OData.GetCalendar`	GET `/odata/Calendars`
POST `/odata/Settings/UiPath.Server.Configuration.OData.SetCalendar`	POST `/odata/Calendars`

Studio Web

Deprecated	Replaced with
GET `/api/StudioWeb/TryEnableFirstRun`	POST `/api/StudioWeb/TryEnableFirstRun`

Setup

Improving the Identity Server - Orchestrator integration has resulted in replacing and removing several parameters in UiPath.Orchestrator.dll.config.
- we replaced WindowsAuth.GroupMembershipCacheExpireHours with IdentityServer.GroupMembershipCacheExpireHours. Upon upgrading to 2022.4+, WindowsAuth.GroupMembershipCacheExpireHours is removed. To specify the Identity Server group membership cache, use IdentityServer.GroupMembershipCacheExpireHours.
- we removed the following parameters: ExternalAuth.AzureAD.Enabled, ExternalAuth.AzureAD.ApplicationId, ExternalAuth.AzureAD.RedirectUri, ExternalAuth.Saml2.Enabled, ExternalAuth.UserMappingStrategy, ExternalAuth.UserIdentifierClaim , ExternalAuth.Google.Enabled, ExternalAuth.Google.ClientId, ExternalAuth.Google.ClientSecret, WindowsAuth.Enabled, and WindowsAuth.Domain. You can now configure external identity providers for the host only after installation, from the host Management portal.
- we also removed the WINDOWS_AUTHENTICATION and DOMAIN command line parameters. You can now enable Active Directory only after installation, from the host Management portal.
The Platform Configuration Tool no longer verifies the certificate host name when upgrading from a version prior to 2020.4. This change is due to the check not being applicable in this upgrade scenario.
The UiPathOrchestrator.msi installer now works with ASP.NET Hosting Bundle 6.0.x. ASP.NET Hosting Bundle 5.0.x is no longer supported.
We no longer validate the SAN certificate against the machine hostname, as we now use the public load balancer DNS for this purpose. As a result, when running the UiPathOrchestrator.msi installer, you no longer have to specify the Host name in the Orchestrator IIS Settings screen. In addition to that, we have deprecated the WEBSITE_HOST command line parameter.
You can now disable public access to newly created Amazon S3 storage buckets by tweaking the UiPath.Orchestrator.dll.config file. To do that, set the BlockPublicAccess property to true in the Amazon S3 storage connection string. Note that this has no impact on existing buckets.
In addition to that, if you opt for Amazon S3 as the storage provider for Orchestrator, you can now use the machine’s IAM role for authentication, instead of AccessKey and SecretKey.

For more details, see the Storage.Location parameter.
When upgrading Orchestrator, you are now prompted with a warning if an Insights version older than 2021.10 is enabled. This message is meant to remind you that Insights hardware requirements changed significantly starting with version 2021.10. Before an Orchestrator upgrade, you must ensure you meet the new Insights requirements.
For consolidation purposes, we have deprecated the following UiPath.Orchestrator.dll.config parameters:
- ExternalAuth.System.OpenIdConnect.Enabled
- ExternalAuth.System.OpenIdConnect.Authority
- IdentityServer.S2SIntegration.Enabled
- IdentityServer.OAuth.Enabled
In addition to that, following a cleanup operation we did for the UiPath.Orchestrator.dll.config file, the following parameters have been removed as well:
- ActiveDirectory.SearchInputMinimumLength
- ActiveDirectory.SearchResultsSizeLimit
- ActiveDirectory.SearchResultsTimeLimitSeconds
- ActiveDirectory.UseNativeDomainResolver
- WindowsAuth.Enabled
- WindowsAuth.Domain
- WindowsAuth.AutoLogin.Enabled
- WindowsAuth.ApiAutoLogin.Enabled
- WindowsAuth.GroupMembershipFetchStrategy
- WindowsAuth.ConvertUsersAtLogin
We no longer require setting the Database.EnableAutomaticMigrations parameter to true for cron jobs changes to take effect.
Instead, to apply changes related to the schedules of internal jobs, you must follow the instructions in Updating schedules of internal jobs.
To prevent unexpected behavior when updating certificates using the Platform Configuration Tool, we have introduced the -KeepOldCertificate parameter.
When configuring SMTP for system email notifications, the SMTP Host field failed validation if using a hostname instead of an FQDN.
We have deprecated the UseRedis flag in the Identity Server's AppSettings.json configuration file. To turn on Redis for load-balanced scenarios, fill in the RedisConnectionString setting under the LoadBalancerSettings section .
If you have enabled Redis for a load-balanced scenario, you have the option of using Redis for caching to reduce stress on the SQL database. A new section called RedisSettings controls which caches are enabled. We have moved the UseRedisStoreCache under this section. In addition to that, the section contains a new parameter, UseRedisStoreClientCache. For details, see Redis Settings.

Azure App Service installations are seeing some similar changes as well. The AppSettings__LoadBalancerSettings__UseRedis setting is no longer used with the Publish-IdentityServer.ps1 script, and AppSettings__UseRedisStoreCache has been renamed to AppSettings__RedisSettings__UseRedisStoreCache. On the other hand, we have introduced a new parameter to enable client caching in Redis, namely AppSettings__RedisSettings__UseRedisStoreClientCache. For details, see Identity Server Scripts.

Auto Update

The auto update functionality now supports Robot and Assistant on macOS platforms. Also, you can now schedule the update to start at a specific time and date so that you can match other maintenance windows in your company.

Erratum - 28 April 2023

To enable this feature, you need to add the Features.MachineMaintenanceSchedule.Enabled parameter to the UiPath.Orchestrator.dll.config file and set it to true.

Other Improvements

In the folder context, on the Automations > Logs page, you can now filter logs by the machines associated to the current folder. Previously, the Machine filter displayed all available machines in the tenant.
After you create a new object from the Create new menu, you get redirected back to the page you were on. Previously, you were redirected to that object's listing page.
Unattended sessions can now be selected on the Audit page, from the Component dropdown.

Erratum 02 November 2022: The payload of the jobs.created webhook for Test Case now displays the specific robot ID and the machine used for the job run.

Deprecation Timeline

Important: Deprecated features or capabilities are fully supported and continue to work until we effectively remove them.

Standard machines will be deprecated starting with 2022.10. We recommend using machine templates.
Classic folders will be deprecated starting with 2022.10. We recommend migrating to modern folders.
API: The role name property will be deprecated across the Orchestrator API starting with 2022.10. We recommend updating your requests to rely on the role ID instead of the role name.
API: Several API endpoints have been deprecated in this release. We recommend using the replacement endpoints listed in the dedicated section above.

More about upcoming deprecations and removals.

Breaking Changes

API: Token Endpoint

The /connect/token endpoint no longer accepts the multipart/form-data content type.

After upgrading to version 2022.4, you must update any affected API requests to this endpoint to use the application/x-www-form-urlencoded content type instead.

API: Requests That Include Role Names

With the improvements to roles, which include the renaming of some roles, any API calls that refence a role name that was renamed need to be updated to use the new name.

This impacts:

API calls related to a customized version of a default role, which is now renamed as Role name - Custom

Important: These calls continue to work without making any changes, but the result is not as expected. Namely, the call now assigns the default role instead of the customized version of the role.
API calls related to the old Tenant Administrator role, which is now named Orchestrator Administrator.

These calls failed with an error due to the inability to find a role with the specified name.

Affected endpoints

The following requests can assign a role based on the role name:

POST /odata/Users
PUT /odata/Users({key})
PATCH /odata/Users({key})
POST /odata/Users({key})/UiPath.Server.Configuration.OData.ToggleRole

Remediation

To address this issue, you can use the new endpoint to assign roles based on the role ID instead of the role name.

There are two ways in which you can update your integrations that were affected by this change so that they work as expected:

A. Add a second API call (recommended)

You can leave your existing API requests as they are but follow each call that assigns roles with a call to the new endpoint to overwrite the assigned roles with corrected ones.

For example, if you have a POST request to /odata/Users to create a tenant administrator account - that is, as part of the account creation, the request attempts to assign the Tenant Administrator role, which has been renamed to Orchestrator Administrator - then you should follow it with a new POST request to /odata/Users({key})/UiPath.Server.Configuration.OData.AssignRoles which passes the role ID for the Orchestrator Administrator role so that it is correctly assigned.

For this remediation method: you need to identify impacted requests in your integration and then, for each identified request:

Note the user ID and the role names to be assigned by the impacted request.
Make a GET request to /odata/Roles to retrieve the current list of roles.
Note the IDs for the role names you noted earlier.
(Optional, but recommended) In your integration, update the impacted request to remove the role name property.

With this change, the request no longer assigns roles and the request in the next step will handle assigning roles going forward.

You can choose to not remove the role property from this request because the request in the next step overwrites any assigned roles.
Immediately after the impacted request, add a POST request to /odata/Users({key})/UiPath.Server.Configuration.OData.AssignRoles, including the role IDs in the body of the request.

The {key} value should be the user ID from the impacted request.

This ensures that any roles that the impacted request you identified would have assigned are immediately overwritten with the correct roles.

B. Update role names

An easier but less efficient remediation method is to update the impacted requests with the new role names.

Note: While this method is easier, we recommend that you consider using the previous method instead because it hardens your integration against any subsequent changes to role names.

For this remediation method, you need to identify impacted requests in your integration and then, for each identified request:

Make a GET request to /odata/Roles to retrieve the current list of roles.
Note the current name for the role names that impacted requests assign.
In your integration, update the role name property values in the impacted request with the updated role names.

Known Issues

Sorting assets by Name in the Assets page does not work.
Orchestrator does not update the Robot role with View on Processes upon upgrading from 2020.4 to 2020.10 and newer. You have to add the permissions manually.
Postponing a successful queue transaction deletes the transaction output data. To overcome this behavior, create a new queue item to store the output of the current transaction. After all, why would you postpone a transaction, once it completed successfully?
The response body of the GET /odata/Releases endpoint may wrongly return IsLatestVersion as False. To make sure the returned value of the IsLatestVersion key is correct, use $expand or $select query parameters, as follows:
- /odata/Releases/$expand=CurrentVersion
- /odata/Releases/$select=IsLatestVersion

As a host, trying to end a maintenance window through Swagger UI may fail. This happens because Swagger UI uses cookies for authentication, which are lost when you close the browser. To end the maintenance mode via API, use one of the following workarounds:

Do not close the browser, and make the POST request to /api/Maintenance/End from the Swagger UI.
Use an API testing application (for example, Postman) to:
- retrieve an access token by exchanging your credentials to the /api.Account/Authenticate endpoint, and then
- make a POST request to the /api/Maintenance/End endpoint using the Authorization: Bearer {access_token} header.

Run the following PowerShell script:

 $orchestratorUrl="https://localhost:6234"
$hostTenant="host"
$hostUser="admin"
$hostPassword=""
$tenantId="" #number

# Authenticate
$body=@{
    "tenancyName"="$hostTenant";
    "usernameOrEmailAddress"="$hostUser";
    "password"="$hostPassword"
}

$response = Invoke-WebRequest -Uri "$orchestratorUrl/api/account/authenticate" -Method Post -Body ($body | ConvertTo-Json) -ContentType "application/json"
$token = "Bearer " + ($response | ConvertFrom-Json).result

# End maintenance mode

$headers=@{
    "Authorization"="$token"
}

$res = Invoke-WebRequest -Uri "$orchestratorUrl/api/maintenance/end?tenantId=$tenantId" -Headers $headers -Method Post -ContentType "application/json" -ErrorAction Stop

if ($res -and ($res.StatusCode -eq 200)) {
    Write-Host "Maintenance mode ended successfully for tenant $tenantId"
}$orchestratorUrl="https://localhost:6234"
$hostTenant="host"
$hostUser="admin"
$hostPassword=""
$tenantId="" #number

# Authenticate
$body=@{
    "tenancyName"="$hostTenant";
    "usernameOrEmailAddress"="$hostUser";
    "password"="$hostPassword"
}

$response = Invoke-WebRequest -Uri "$orchestratorUrl/api/account/authenticate" -Method Post -Body ($body | ConvertTo-Json) -ContentType "application/json"
$token = "Bearer " + ($response | ConvertFrom-Json).result

# End maintenance mode

$headers=@{
    "Authorization"="$token"
}

$res = Invoke-WebRequest -Uri "$orchestratorUrl/api/maintenance/end?tenantId=$tenantId" -Headers $headers -Method Post -ContentType "application/json" -ErrorAction Stop

if ($res -and ($res.StatusCode -eq 200)) {
    Write-Host "Maintenance mode ended successfully for tenant $tenantId"
}

The names of our user licenses have changed over time. However, the robotType parameter of the GET /odata/LicensesNamedUser endpoint still references the old names, together with the new ones. That's why you see "Development" as an option, which was renamed to RPA Developer, and you see the "RpaDeveloper" option too. To better identify our robot licenses, check the naming progress below:

2018	2019	2020	2021.4	2021.10
Attended	Attended	Attended	Attended	Attended
Development	Studio	Studio	RPA Developer	Automation Developer
	+ StudioX	StudioX	Citizen Developer	Citizen Developer
		+ StudioPro	RPA Developer Pro	Automation Developer
Unattended	Unattended	Unattended	Unattended	Unattended
NonProduction	NonProduction	NonProduction	NonProduction	NonProduction
		+Testing	Testing	Testing

Upgrades to 2022.4 may fail with a timeout error due to an Identity Server database issue. To fix the problem, see Identity Server troubleshooting
User sessions on the host- and organization-level portals do not time out. To enforce a timeout period, you must manually set a timeout interval for the Management portals .

Bug Fixes

An issue was fixed that would allow an attacker with privileged access to a robot to retrieve the LicenseKey (MachineKey) of other robots within the same tenant by brute forcing API calls to Orchestrator. This would theoretically allow the attacker to access resources restricted only to that robot. Read the security advisory for UiPath - Robot Account Takeover.
You could not assign robot accounts to a folder if, prior to navigating to the tenant level, the last folder selected was a classic folder. The main symptom was that when looking for a robot account to assign, the robot account was not displayed even if it existed.
We added the View permissions on Robots as a requirement for starting or creating jobs in modern folders. As a result, the Start job button becomes inactive until you assign the required permissions, which are displayed in the button tooltip. Previously, when you started or created jobs in modern folders, the "You are not authorized! (#0)" error message was displayed.
Upon changing the mechanism behind GenerateReportsJob (the background job computing stats on the Queues page) from incremental to partition swapping, you ran into following error: "The 'LastQueueItemEventProcessed' property on 'UiQueueProcessingRecordBase' could not be set to a 'null' value". The issue no longer occurs.
The Update button on the Edit trigger window did not get enabled after changing the execution target from Dynamic Allocation to All Robots. This only occurred in classic folders. Now, after changing the execution target for triggers in classic folders, you are able to save your changes by clicking Update.
The names of manually uploaded packages were not displayed in the audit details. This issue affected packages uploaded both individually and in bulk. Now, the names of all uploaded packages are successfully logged in the audit details.
Orchestrator threw an “Invalid authentication token” error (error code - 1431), causing an infinite loop in the browser after a session inactivity timeout. The issue no longer occurs.
We made a typo on the Assign roles to a robot account window. Instead of Search for a robot account, the field said Seach for a robot account. The field name is now spelled correctly.
Orchestrator did not correctly render time formats on the Logs page when the Orchestrator language was set to Chinese, Japanese, or Korean. 0 characters got rendered as slashed zeros and prevented the glyph following the 0 from being displayed. For example, what should have been displayed as 11時20分03秒 was rendered as 11時2Ø03秒.
When opting for Latin1-based SQL collation, the same behavior occurred if Turkish (tr-tr) culture was used on the application server. To fix this issue, switch to en-us culture and re-attempt the installation.
Deadlocks would occur where queue item processing took less than a second per queue item. Processes would throw multiple "An error has occurred. Error code: 0" errors before crashing. The issue has been fixed and you are now able to process queue items without running into deadlocks.
When the Orchestrator and Identity databases used Turkish-specific collation, upgrades from version 2020.10 to 2021.10 failed.
Credential asset retrieval failed for CyberArk credential store when setting Plugins.SecureStores.CyberArk.UsePowerShellCLI to true in Orchestrator's UiPath.Orchestrator.dll.config file.
Upon upgrading to 2021.10.1 or later, Orchestrator failed to send email alerts when the Use default credentials option was enabled. Email alerts are now successfully sent.
An issue was preventing users from enabling the encryption key per tenant feature on the default tenant after a clean installation.

Activity Package Versions

The following activity packages and versions are shipped with Orchestrator:

Activity Pack	Version
UiPath.UIAutomation.Activities	v22.4.4
UiPath.System.Activities	v22.4.1
UiPath.Mail.Activities	v1.15.1
UiPath.Excel.Activities	v2.12.3
UiPath.Testing.Activities	v22.4.2
UiPath.MobileAutomation.Activities	v22.4.4
UiPath.Word.Activities	v1.10.1
UiPath.ComplexScenarios.Activities	v1.1.6
UiPath.PDF.Activities	v3.6.0
UiPath.Terminal.Activities	v2.4.0
UiPath.Web.Activities	v1.11.1
UiPath.Persistence.Activities	v1.3.4
UiPath.Form.Activities	v1.9.4

Orchestrator Release Notes

Was this page helpful?