Orchestrator Release Notes
2022.4
Release date: 23 May 2022
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.
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.
Publish-ResourceCatalog.ps1 and MigrateTo-ResourceCatalog.ps1. For more details, see Azure App Service Installation.
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.
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 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.
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.
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.
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).
Plug and play your S3 compatible storage with Orchestrator and take advantage of all its unique benefits: scale, cost, and reliability.
Learn how to create and configure storage buckets.
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.
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)
-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.
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.
-
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.
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.
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.
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 |
|
AssetValues |
Value |
By default |
|
Tasks (i.e., actions) |
Data (i.e., action catalogs) |
Optional via UI |
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"
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.
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:
/odata/Users({key})/UiPath.Server.Configuration.OData.AssignRolesThis 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.
<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.
-
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
SpecificContentkey via API. Use thePUT /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}` |
|
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 |
-
Improving the Identity Server - Orchestrator integration has resulted in replacing and removing several parameters in UiPath.Orchestrator.dll.config.
- we replaced
WindowsAuth.GroupMembershipCacheExpireHourswith IdentityServer.GroupMembershipCacheExpireHours. Upon upgrading to 2022.4+,WindowsAuth.GroupMembershipCacheExpireHoursis removed. To specify the Identity Server group membership cache, useIdentityServer.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, andWindowsAuth.Domain. You can now configure external identity providers for the host only after installation, from the host Management portal. - we also removed the
WINDOWS_AUTHENTICATIONandDOMAINcommand line parameters. You can now enable Active Directory only after installation, from the host Management portal.
- we replaced
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
Features.MachineMaintenanceSchedule.Enabled parameter to the UiPath.Orchestrator.dll.config file and set it to true.
- 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.
jobs.created webhook for Test Case now displays the specific robot ID and the machine used for the job run.
- 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.
/connect/token endpoint no longer accepts the multipart/form-data content type.
application/x-www-form-urlencoded content type instead.
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- CustomImportant: 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.
/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/Rolesto 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.
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/Rolesto 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.
- 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/Releasesendpoint may wrongly returnIsLatestVersionasFalse. To make sure the returned value of theIsLatestVersionkey is correct, use$expandor$selectquery 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/Endfrom the Swagger UI. - Use an API testing application (for example, Postman) to:
- retrieve an access token by exchanging your credentials to the
/api.Account/Authenticateendpoint, and then - make a POST request to the
/api/Maintenance/Endendpoint using theAuthorization: Bearer {access_token}header.
- retrieve an access token by exchanging your credentials to the
-
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" }
- Do not close the browser, and make the POST request to
- The names of our user licenses have changed over time. However, the
robotTypeparameter of the GET/odata/LicensesNamedUserendpoint 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:
|
Year or Orchestrator version |
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 |
- 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.
0characters got rendered as slashed zeros and prevented the glyph following the0from being displayed. For example, what should have been displayed as11時20分03秒was rendered as11時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 toen-usculture and re-attempt the installation.
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 |
- What’s New
- Organizing Resources With Tags
- Global Tenant Search
- OAuth 2.0-based Framework for Robot Authentication
- Machine Keys for PW Templates No Longer Visible
- Removing Disconnected and Unresponsive Unattended Sessions
- New Credential Stores Are Available
- S3 Compatible Storage
- Custom AIMWebserviceName
- SAML Integration at Organization Level
- Improvements
- Monitoring
- Automations
- Hostname Mapping for Triggers
- Complete Process Creation Flow
- Encryption
- Roles and Permissions
- API
- Setup
- Auto Update
- Other Improvements
- Deprecation Timeline
- Breaking Changes
- API: Token Endpoint
- API: Requests That Include Role Names
- Known Issues
- Bug Fixes
- Activity Package Versions
