- Release notes
April 2022
To accommodate automation projects with multi-account connections, we implemented a new feature that allows personal workspace owners to see those accounts and specify one for launching the job. You can change the account on the Package Requirements tab when creating a process or editing an existing one. A drop-down is available for each connection with multiple accounts allowing you to see the entire list of available accounts and change the active account as needed.
To manage your connections or add new ones, you can jump to Integration Service by clicking the 
button.
Learn about connections in the Integration Service guide.
/odata/UserLoginAttempts({key}) endpoint and corresponding Login Attempts section on the My Profile page in Orchestrator have been deprecated and only return login attempts made prior to this change (i.e. login attempts with
cookies). From now on, login attempts made using access tokens can be accessed solely via Audit Logs in Automation Cloud.
Contact your administrator to request this data.
Token-based authentication changes the way Orchestrator computes the last login time of a user. From now on, the last login time is computed once per hour for a user actively using Orchestrator.
Say a user is using Orchestrator between 14:10 and 15:00. Having been authenticated at 14:10 means 14:10 is displayed as their last login time until the next hourly check. Using Orchestrator until 16:00 means 15:10 displayed as the user's last login time.
Here are the places in the Orchestrator UI where you can see the changes in how we compute the last login time for your users:
- Assign roles page (Tenant > Manage access)
-
Personal workspaces page (Tenant > Folders > Personal workspaces)
Note: As an exception to our typical release cadence, this feature does not become available to Enterprise users one week after the Community release date. Instead, it will be shipped to Enterprise users in the week of May 2nd.
You can now authorize API calls in the Swagger UI using OAuth2.
Elastic robot orchestration
- Adding an elastic robot pool to a folder now also adds the pool to any sub-folders. This way, any jobs from sub-folders can also run using elastic robot orchestration.
- We have eliminated the restriction of having only one pool per folder. Scale away!
CyberArk CCP
- Orchestrator now supports
.cercertificates as Server Root CA certificates. - Certificate configuration errors now contain more details about the cause of the problem.
This feature is only available to Community users.
Ever wondered how your life would look if you didn't have to worry about the infrastructure on which your automations are executed?
In the past couple months, we have made it our number one priority to make it happen and today we bring you UiPath Automation CloudTM robots - Serverless, or Cloud robots - Serverless for short.
Serverless cloud robots make it easy to run background automation without worrying about the necessary infrastructure. They provide you with complete freedom from provisioning, managing, maintaining, and scaling any underlying infrastructure. UiPath handles all the work behind the scenes so you don't have to deal with containers, virtual machines, or physical servers.
See details about Automation Cloud robots - Serverless and instructions on how to set them up.
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.
API: Breaking changes
With the other recent improvements to roles (details here and here), which resulted in the renaming of some roles, any API calls that refence a renamed role need to be updated to use the new role 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.
Because of the recent changes and because we want to retain our ability to update roles in the future without impact to you, we are announcing our intention to deprecate the use of the role name property in the Orchestrator API.
We will continue to support this property for a minimum of 6 months from now.
However, we recommend that you begin transitioning to use the new endpoint for assigning roles to avoid breaking changes following deprecation.
We have increased the maximum number of characters allowed for role names from 32 to 64 characters.
jobs.created webhook for Test Case now displays the specific robot ID and the machine used for the job run.
You are not authorized! (#0) error message was displayed.
