April 2022

18 April 2022

Support for Multi-account Connections

Note: This functionality is available only in personal workspaces.

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.

From Cookie to Token-based Authentication

We migrated from cookie-based authentication to token-based authentication. Following this change, user login attempts are no longer saved in Orchestrator. As a result, the /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.

Authorizing API Calls in Swagger

You can now authorize API calls in the Swagger UI using OAuth2.

See how to obtain an access token, send requests or revoke access.

Other Improvements

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 .cer certificates as Server Root CA certificates.
• Certificate configuration errors now contain more details about the cause of the problem.

5 April 2022

Cloud Robots - Serverless (Preview)

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.

4 April 2022

Roles Changes, API Edition

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.

API Guide: Assigning roles

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 - 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:

1. Note the user ID and the role names to be assigned by the impacted request.
2. Make a GET request to /odata/Roles to retrieve the current list of roles.
3. Note the IDs for the role names you noted earlier.

4. (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.

5. 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:

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

API: Deprecation Notice

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.

Improvements

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

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.

Bug Fixes

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 is 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.