2023.10

Release date: October 23, 2023

Administration news

New database maintenance scripts

Released on November 1, 2023

Keeping your Orchestrator database neat and free of clutter ensures a smooth experience both during day to day operations, as well as during upgrades. However, as your automation operations increase in size and coverage, this can become a daunting task. In an effort to help you streamline it, we have created a set of scripts that you can use to regularly clean up old data, with the added option to schedule their execution at times that are convenient for you.

You can read more about the Orchestrator database maintenance scripts in the dedicated documentation, and you can download them from the Customer Portal.

Classic folders removal

Classic folders and all their associated objects are now removed. This change brings about the removal of all such objects from the Orchestrator interface.

If you are planning on upgrading to this version, make sure to migrate any existing classic folders to modern folders.

You can see the Classic folders removal page for details on the steps leading up to this change.

Roles and permissions changes

Roles help thoroughly control access to Orchestrator features and objects, allowing you to reliably separate users based on their permissions. In an effort to make this task as easy and effective as possible, we are making several changes to our default roles.

Permission changes

The Automation User folder role and the Allow to be Automation User tenant role no longer have permission to publish processes. This gives the role the minimum folder level permissions needed to execute processes. This way, we ensure that personal user packages do not accidentally get published without first being reviewed.

New roles

Two new sets of roles are available, allowing you to combine several roles so as to achieve the desired results while still maintaining granularity:

• Automation Publisher and Allow to be Automation Publisher - only contains the permissions needed for publishing processes to Orchestrator, and can be combined with any existing role.

• Automation Developer and Allow to be Automation Developer - can create automations.

Note:

New roles are added as read-only.

In the unlikely event that an organization already contains a custom role with the same name as one of the new roles mentioned above, we will rename it to "Role name - custom". This way, both roles can be used.

Assignment changes

When you assign a default folder role, you are automatically prompted to also assign its tenant counterpart. This is how we ensure that you are not missing any permissions needed for your automations.

Note:

Known issue: This option does not work for Active Directory users or groups.

Removal checks

When the Orchestrator Administrator role is unassigned from a user, we check that they are not the last user with that role. The same check applies when deleting a user or a group if there are no other users or groups with the Administrator or the Orchestrator Administrator role.

Introducing the Citizen Developers user group

We're excited to announce the latest enhancement to our platform's access control capabilities — the introduction of a new user group: Citizen Developers. This new group is defined at the organization level and will be seamlessly integrated across all services within the platform.

With the Citizen Developers group, citizen developers can access resources pertinent to their work without any unnecessary access clutter, leading to reduced overhead for your administrators.

To learn more about how the user group is integrated into the various services within the platform, refer to the product documentation.

Unattended robot setup

Unattended automation is one of the core functionalities of Orchestrator, allowing you to set up tasks that can then be carried out on their own, with no human involvement whatsoever. Its seemingly simple output is, however, built on top of a complex foundation, which involves piecing together just the right components.

In an attempt to help you seamlessly navigate the setup process, we have created the Unattended Robot setup option, which is available in the Create new menu of the Orchestrator toolbar.

You currently have the option to set up a process based on a self-hosted machine template, which is selected by default, with more to choose from coming soon.

Clicking Get started allows you to start selecting the necessary Orchestrator objects for your future unattended automation: machine template, robot account, folder, and connection settings. Each step comes with detailed instructions and helpful tips, as well as links to sections where you can create any required objects.

Permission checks change

Creating a queue trigger from the API now also requires the Create on Queues permission.

Auth.RememberMe.Enabled setting removed

The Auth.RememberMe.Enabled setting in the Authorization section of the UiPath.Orchestrator.dll.config file has been removed, as it is no longer used. This allowed you to select whether the Remember Me checkbox on the Login page was displayed or not. However, this particular option is no longer configurable from Orchestrator, as it has been moved to the Identity Server.

New HashiCorp Vault secret store

The OpenLDAP store is now available as an authentication method for HashiCorp Vault.

Conversion of inactive personal workspaces

When you convert an inactive personal workspace to a folder, it now becomes available only to the administrator who initiated the conversion. As such, no other users will have access to it.

API key authentication for Elasticsearch

You can now log in to Elasticsearch through an API key that you generate and store yourself in a key vault. All you need to do is retrieve the key, store it in your Azure key vault, and connect Orchestrator to this vault by following our instructions.

Group Alerts

Now you can set alert subscriptions for groups. This way you can control what alert types a group receives, based on the common denominator of the group members.

Subsequent alert emails are then sent to users that are part of those groups, provided those users have View permission on Alerts at group level.

Known issues:

• Alert emails sent to groups may be written in English, regardless of the language preference of individual group members.

• Local users part of local and mail-enabled AD/AAD groups may receive duplicate emails for alerts that have been generated for both groups.

Automation asset updates

Troubleshooting pending jobs

You will have likely wondered why your job was stuck in a Pending status, with no idea how to get it to run. We are coming to your aid with a section in the Job Details windows that is solely dedicated to the reasons why your job has not yet started. What is more, if available, you get actionable advice for each reason - this can either be a link that directs you to the section in Orchestrator where you can fix the problem, or a specific action to take for your particular scenario. In case you do not have permissions to fix the problem, you may need to ask for help from an administrator.

Exporting jobs grids

Ever wanted to create dashboards and metrics based on your jobs data? Nothing stands in your way, as you can export all of your job reports from the current folder and download them to your machine. Read more about Exporting grids.

Report exports improvements

We have streamlined the way data is exported from grids. These are the changes you can benefit from now:

• When you click Export, you are no longer asked for confirmation. Instead, you are shown a notification letting you know that the export is in progress.

• Once done, another notification is displayed, letting you know that the exported data is ready for download.

• The download then starts automatically if you have the Alerts - View permission.

• If you don't, you can download the exported data from the My Reports page.

Time columns consolidation in exports

Reports containing exported data from queue transactions, audit, logs, and jobs pages included instances of duplicate information which are now cleaned up. Specifically, exports now only contain absolute time columns, which are expressed in the tenant's timezone.

Deprecation of reports endpoints

Reports endpoints available for audit logs, robot logs, and queue definitions are now deprecated. As such, we advise against using the following:

• GET/odata/AuditLogs/UiPath.Server.Configuration.OData.Reports

• GET//odata/RobotLogs/UiPath.Server.Configuration.OData.Reports

• GET/odata/QueueDefinitions({key})/UiPathODataSvc.Reports

The endpoints listed above will be removed in April 2024.

If you would like to retrieve such reports, we recommend these steps:

1. Initiate an export by calling the appropriate endpoint:

   • For audit logs: POST/odata/AuditLogs/UiPath.Server.Configuration.OData.Export
   • For robot logs: POST/odata/RobotLogs/UiPath.Server.Configuration.OData.Export
   • For queue definitions: POST/odata/QueueDefinitions({key})/UiPathODataSvc.Export
   Important:

   • This operation returns an ID that is necessary for the next two steps.
2. Get the status of the report by calling the GET/odata/Exports({key}) endpoint and appending the ID returned at step 1 to it.
3. Once the status is Completed, get a download link for retrieving the exported archive, by calling the GET/odata/Exports({key})/UiPath.Server.Configuration.OData.GetDownloadLink endpoint and appending the ID returned at step 1 to it.

Recording failed queue transactions

Processes that do not succeed because of failed queue transactions can now be recorded for debugging purposes. This option, named Record and store failed queue transactions, is enabled at the process level, from the Video section of the Job recording setting.

Its output can be rendered directly in Orchestrator, within the queue transaction itself.

Invalid characters in queue names

Exporting queue transactions did not succeed if the queue name contained invalid characters (\ / : * ? " < > |). This is now fixed by replacing invalid characters with _, thus allowing queue items to be exported.

Queue processing records limit clarification

The QueueProcessingRecords resource used for returning statistical information on queues and transactions via API returns data that is maximum 90 days old. You can request data by day, hour, and minute, but it is only displayed if it has been recorded within the last 90 days.

This does not affect the UI functionality, where information recency is still capped at 30 days.

Dots in storage bucket names

Non-consecutive dots are now allowed in Amazon S3 storage bucket names.

Internal package sorting

Internal packages, namely packages uploaded via Orchestrator-hosted feeds, are now sorted by published date. The published date is the date when the most recent version of a package was published.

New machine key parameter

We have added a new parameter to the GET/odata/RobotLogs endpoint, namely MachineKey. As the name suggests, this stores the machine key, which was previously held by the MachineId parameter.

MachineKey, which has a GUID format, was introduced in order to persist robot logs in tenant move scenarios. MachineId has a dynamic number format, meaning that it cannot be persisted in such cases.

While the two work in parallel for now, we highly recommend using MachineKey, as MachineId will be removed in April 2024.

Running jobs from personal workspaces

Jobs started from personal workspaces must always run under the identity of the user that started them, not under the identity of the personal workspace owner. As such, if you want to start a job while exploring a personal workspace, you need to have your own robot defined for that specific purpose, regardless of any other robots defined in that workspace.

Job restart machine selection

When you restart a job, the Machine field is now prefilled with the same machine that was initially used for that particular job.

New Jobs page filter

The Jobs page has been enhanced with the new Process filter, allowing you to further narrow down the list of jobs per your desired criteria.

Queue items final states

In an effort to ensure the consistency of the final state across queue items, we are enforcing the following error responses when calling the SetTransactionResult endpoint.

With a success payload on a failed item:

POST https://{yourDomain}/odata/Queues(1)/UiPathODataSvc.SetTransactionResult
{
  "transactionResult": {
    "IsSuccessful": true
  }
}

With a failure payload on a successful item:

POST https://{yourDomain}/odata/Queues(1)/UiPathODataSvc.SetTransactionResult
{
  "transactionResult": {
    "IsSuccessful": false,
    "ProcessingException": {
      "Reason": "string",
      "Details": "string",
      "Type": "ApplicationException"
    }
  }
}

The error code is 1866, with the message "Invalid transition from a final status". This indicates that you cannot change the status after the queue item reaches a final state.

Besides optimizing your Queue processing mechanism, this also enables UiPath Insights to update and properly sync data based on queue item events.

Important: You'll be receiving the same error code when you use the DeferDate or DueDate properties in the SetTransactionResult payload to move transactions out of their final states. Going forward, to set a new defer or due date, you'll need to clone the transaction or create a new one.

Retention policy for process data

Now you can set a custom default retention policy for your jobs. You can choose either to permanently delete old jobs, or move them to a designated storage bucket and have them available for future access. Doing so, you free up the database in an organized manner and your Orchestrator performs better. But you should be aware that even if you do not configure your own policy, a default one still applies.

Additionally:

• two new retention columns are available for selection in the Processes > Columns filter, to help you quickly identify the existing policy of a process
• a new alert is available for email subscriptions on the Alert preferences page, to inform you about process retention failures

Discover the retention policy tips and tricks on our documentation page.

Introducing machine maintenance mode

You now have the option to take your machine offline whenever you want to perform maintenance on it. It can be enabled from the tenant-level Monitoring page, in the Unattended sessions section, by switching the toggle in the Maintenance column to On.

When you enable the option, you are given the choice to either wait for running jobs to finish, or to kill all running jobs before going into maintenance mode. Pending jobs, however, keep their status until they are picked up.

Usability improvements

Permission checks for package downloads

Robots can now download packages from the tenant feed as long as they have the View on Packages permission.

Minutes in SLA predictions

You can now set SLA predictions with more granularity, as we have added the Minutes field to both the Enable SLA for this queue and Risk SLA sections.

Handling months in cron expressions

We have changed the way we treat months that are less than 31 days long when a cron expression uses the 31W subexpression in order to indicate that a job should be executed on the last day of the month or on the closest weekday to the last day of the month.

The current behavior is as follows:

• For months with 31 days, the 31W subexpression leads to the job being executed:

  • on the 31st of the month if it falls on a weekday

  • on the nearest weekday to the 31st if the 31st falls on a weekend

• For months with less than 31 days, the 31W subexpression prevents any jobs from being executed, thus skipping the month entirely. In this case, we recommend using LW instead. This triggers the job on the last weekday of the month, regardless of the number of days, meaning that no months are skipped.

New transactions columns

We have added four new columns to the Transactions page (Queues > View Transactions):

• Deadline (absolute)

• Postpone (absolute)

• Started (absolute)

• Ended (absolute)

Note that they are not enabled by default, so make sure to select them from the Columns list.

These columns are also included in exported reports.

New type filtering option in tenant search

The Action Catalog option has been added to the Type filtering menu in the tenant search window.

Mandatory webhook name

The Name parameter is now mandatory for webhooks created via the POST odata/Webhooks endpoint.

External app assignments

The user interface items pertaining to account and group assignments have been updated so as to reflect the fact that external apps can also be assigned. Specifically, Assign account/group is now Assign account/group/external app.

Transaction reviewer column

The transaction Reviewer column now includes the name, surname, and email address of the reviewer.

Packages with sources in the package explorer

Studio packages that are uploaded along with all their .xaml sources (i.e. the Include Sources option selected in the Publish options > Compilation settings section) can now be viewed in their entirety in the package explorer. This applies to Windows and cross-platform projects.

Faulted job info limitation

The storage space dedicated to the exception information we store when a job is faulted is now limited to 42 KB.

Error message clarifications

Credential store connection error

When the connection to the credential store which contains robot credentials is not established, thus preventing the password from being retrieved, the robot is no longer started, and you are now returned the following error:

Unable to retrieve credentials from {credential_store_name} credential store. Please check your connection settings and ensure the {credential_store_name} service is running.

This prevents you from being locked out of the robot account due to repeated attempts to start the robot without credentials.

License expiration error

When Unattended licenses expire, the quantity available for allocation no longer matches the actual allocation. In that case, the following explanatory error is displayed:

Update failed! Too many licenses [license type] have been allocated. Please disconnect X [license type] from machines runtimes to match the number of defined licenses.

Bug fixes

• We have fixed an issue that prevented Swagger authentication if Orchestrator and Identity Server were deployed as Azure app services with different URLs.

  Important: The fix only applies to this version. For previous versions, you need to add the following section to the web.config file:

  <rewrite>
        <outboundRules>
           <rule name="CSP">
            <match serverVariable="RESPONSE_Content-Security-Policy" pattern=".*" />
            <action type="Rewrite" value="default-src 'self' https://<YOURIDENTITYURL>;connect-src 'self' https://<YOURIDENTITYURL>;script-src 'self' 'unsafe-inline';style-src 'self' 'unsafe-inline';img-src 'self' data:;font-src 'self'" />
          </rule>
        </outboundRules>
  </rewrite>

• When you deleted a user from the host tenant, then created another user with the same username and e-mail address as the one that you had deleted, you could no longer log in to the non-host tenant. This occurred due to a missing rule around provisioning a new user once another user with the same information was deleted. This issue is now fixed.

• The minLevel NLog setting in the Identity Server appsettings.json file was not being honored. The default minLevel is "Info" indicating that logs of "Info" severity and above should have been logged. However, the minLevel was not being considered, and logs with lower severity levels, specifically "Trace" and "Debug", were also being written to the logs.

• Previously, there was an issue where well-known SIDs were inadvertently included when retrieving security groups, leading to unexpected behavior. Well-known SIDs are no longer included when fetching security groups, ensuring smoother and more predictable functionality.

• After upgrading to version 2022.10.1 or later, logging into the host tenant, then logging out, and subsequently switching to a different tenant resulted in redirection back to the previous log-out location instead of the selected tenant. Now, after logging out and switching tenants, you will be correctly redirected to the selected tenant's page instead of the previous log-out location.

• Navigating the Browse Bucket window posed some minor display issues that are now fixed.

Security vulnerability fixes

• Due to a lack of synchronization, changes made to robot accounts and external applications at the organization level were not reflected in Orchestrator. Now, when you delete or rename an external application or when you delete a robot account at the organization level, the same thing happens to these entities in the Orchestrator folders where they were added.

• Using the Upload JSON and override option at the transaction level, in the Edit queue item window, allowed you to bypass important validations related to unsupported characters. This would lead to errors when trying to use that particular queue. The issue no longer occurs.

Swagger UI

We have fixed an issue that affected Swagger UI versions 3.14.1 to 3.37.2, allowing their libraries to fetch potentially malicious specification files linked through Swagger UI. Note that the issue is not directly exploitable, and it requires an authenticated user to actually open the malicious link.

To overcome this, we strongly advise you to update to the latest possible version (major or cumulative update).

Please see the security advisory for details.

Common Vulnerabilities and Exposures

This release brings security updates and patches to address Common Vulnerabilities and Exposures (CVEs).

Known issues

• Tag operations performed at the platform administration level, such as creating, editing, or deleting a tag, are not currently audited.

• Having 80 thousand or more attended robots running under users with the Allow to be Automation User role causes performance degradation. This is due to the role having View permissions on Alerts. As a workaround, you can create and assign a new role with the same permissions as Automation User, minus Alerts - View.

• Accessing the Apps tab and the corresponding App versions page requires enabling both Orchestrator and Apps services in Automation Suite.

• The "Trigger automatically disabled after job execution failures." alert, generated when a trigger is automatically disabled as a consequence of the Set execution-based trigger disabling toggle being enabled, does not work in this version. It will be fixed in the first 2023.10 patch.

• Added on 26 October 2023

  Standard machines are removed starting with the current version. This means that you can no longer create new standard machines, and that we recommend you resort to machine templates instead. However, the corresponding interface option is still visible, but we strongly recommend that you do not use it, as it will not work as expected. It will be removed entirely in the next patch.

• The Enable Automation Suite Robot automatically option in the tenant settings > Personal Workspaces is not working as expected.

Deprecation Timeline

We recommend that you regularly check the deprecation timeline for any updates regarding features that will be deprecated and removed.