August 2021

You can now auto-update client apps (Robot, Studio, Assistant) from Orchestrator. This is a much-needed feature that helps IT Admins and RPA CoEs save a lot of time when it comes to making sure that Robot, Studio and Assistant are up-to-date.

For now, we are doing a staggered launch just for community users. For enterprise users, the functionality becomes available with the 2021.10 enterprise release and you can get a sneak peak here.

Say goodbye to the hassle of debugging when the Enforce user authentication, disable robot key authentication option is enabled (also known as interactive login, set from tenant settings in Orchestrator).

While this feature brings multiples advantages (security enhancements, easier flow for attended users when connecting to Orchestrator, streamlined licensing for users by enabling the User License Management functionality), it also had as a side effect a more cumbersome debugging experience for the unattended processes: when logging in to a machine connected to Orchestrator via machine key for debugging purpose while interactive authentication is enforced, there are no processes available in your Assistant to debug them, unless you first sign in.

Now you can achieve this, by enabling a troubleshooting session on the machine, which is available from the Unattended sessions tab of the Robots page:

Enabling a troubleshooting session allows you to see and run unattended processes from Assistant for debugging purposes.

The troubleshooting session is temporary and the above only applies while troubleshooting is active.

No user license is required for the developer to perform this operation.

For instructions, see Debugging Unattended Processes.

Yes, you read that right! This release brings unattended execution within the reach of all RPA developers out there and paves the way for remotely executed RPA processes from within the comfort of your personal workspace.

For those of you who are familiar with modern folders, this feature should bring nothing new - the experience is quite similar in that it allows remote execution on company-managed VMs; only this time workspace owners can do it too. Enough with the bragging, let's take you through the highlights:

The administrator experience

Enabling the unattended experience for all your RPA developers involves one important thing: a machine object - machine template or standard machine - associated with the workspaces. This makes the unattended infrastructure (machines connected to Orchestrator using their key) available for execution in all personal workspaces.

You can do that from the tenant context > Folders > Personal Workspaces.

Note: You cannot restrict a machine object scope to specific workspaces, nor can you exclude it from certain workspaces; a machine object can be associated to either all workspaces or none.

Another note: Make sure the machine object has the necessary runtimes to support the execution for all your workspaces.

The RPA developer experience

All unattended-specific functionalities become available in personal workspaces provided an administrator made the necessary configuration beforehand.

This allows RPA developers to perform the following operations:

A. Launch automations in a preplanned manner or through a queue item condition using Triggers.

B. Check the health and status of the machines and machine runtimes assigned by the administrator to your workspace using the Monitoring feature. We have added a Machines card to the workspace Home page for quick access.

C. Monitor all resources in your workspace by checking out the new Monitoring menu that allows you to learn about the health of your machines, processes, queues, and SLA predictions.

Modern folder vs. personal workspace

In a personal workspace context, jobs are launched under the identity of the workspace owner. This brings a couple of changes to the functionality as you may know if from modern folders:

Permission considerations

To make the transition as smooth as possible, we've adjusted the predefined Personal Workspace Administrator role:

Congrats for making it this far and don't forget: this is one in a series of features that will pave the way for the most well-rounded RPA experience there is! Keep an eye out!

To address security challenges brought by robots having access to the default host feed (currently on MyGet) to retrieve library packages, we have added a new option that only allows connections to the tenant's feed.

Whereas before we provided an Only host feed and a Both host and tenant feeds options for the retrieval of your library packages, we now offer a third option: Only tenant feed.

Learn how to configure library feeds.

In our quest to summon all actions-related functionality inside Action Center, the Action Catalogs management has been transitioned entirely from Orchestrator to the Actions service.

For more details, check out our documentation.

Worry not about existing Orchestrator actions, as every link redirects you to the same action in the Action Center interface.

Now you can use Testing Robots to test your workflows in non-production environments. This is intended for non-production environments only. You can select this option when you configure jobs or schedule triggers, as seen in the following screenshot.

Your test sets show the activity coverage for each execution. Include this feature in your RPA testing to check which activities have been covered during execution, indicated within a percentage calculator. To learn how it works, see Test execution coverage.

You made your voices heard! This release brings a new addition for all administrators out there that use the same machine object - machine template or standard machine - in all subfolders. Instead of assigning the same machine to each and every single subfolder manually, as of today, you can push it from a parent folder to all its child folders with a couple of easy clicks.

Learn about assigning machines to folders.

In the following example, Orchestrator will attempt to stop jobs that have been stuck in Pending for at least 10 minutes. If the termination does not happen, Orchestrator will attempt killing those jobs that have been Stopping for at least 20 minutes.

Learn how to configure time triggers.

A suspended job is resumed by any available robot on any available machine. However, there are cases when:

To acknowledge your resources and license requirements on a job resumption, we deliver the option to use the same User-Machine configuration set at the job start. Find out more details in the Managing Jobs article.

In an effort to clarify the distinction between adding users, which is done from the Admin page in Automation Cloud, and granting access to users, which is done from Orchestrator, we have improved the Orchestrator user interface and tweaked the terminology to make things less confusing.

So here's what changed: