- Release notes
March 2020
In 2018.3 we introduced the concepts of attended floating robot and machine template.
Used together, the two became the ideal mechanism for handling deployments based on non-persistent VDIs, long shifts with hotseat change-overs, and generally environments with arbitrary machine/user combinations.
Machine templates took over the necessity of defining a Cartesian product between the sets of users and machines, in the sense that an environment with 8 users and 8 VDIs needs a configuration with one machine template and 8 floating robots, whereas before you would've had to define all 64 robot combinations between the two 8-sets.
In 2019.10, in an effort to decrease the deployment effort even more, we introduced attended robot auto-provisioning and management. It then became possible to automatically create an attended robot for whatever type of user identities you have in your instance. This, alongside robot settings and licensing needs can be configured directly at user level.
If up until now you could only take advantage of these goodies through our attended plan, in this release we fully bring our solution to maturity, by turning our attention to our unattended offering. To this end, every behavior described above is now valid for unattended and non-production robots as well.
To sum up, the new main capabilities are focused on easy management of large deployments, regardless the robot type. They consist in efficient robot use via dynamic allocation, auto-provisioning, and non-persistent VDI support, if that your thing. Let's wrap up and call it a day with an article describing robots in modern folders.
This release ships with a feature allowing users to conveniently change the display name of a process. This is for all of you out-there republishing packages and recreating the processes because of a typo. We finally did it! 10/10 improved usability.
The Tasks functionality has been treated to a major overhaul. It is now called Action Center, with actions instead of tasks working as the operational units of the center. Don't worry, the functionality itself stays the same. Details about actions here.
We also introduced a new type of action, and guys, it is da bomb! What happened is we integrated Validation Station with our new re-branded Action Center. What does it mean?
To ensure no waste in terms of resources consumption while waiting for a long-running process completion, whenever user input is required in regard to reviewing and correcting document classification and automatic data extraction results, a Document Validation action is generated.
This action is to be acted upon by the user to whom it’s assigned. During the time the action is pending completion, no robot is held hostage. They can be used to execute different processes just like that. Upon completion of the Document Validation action, the initial workflow is resumed on whatever robot is available.
If you regularly work with background processes, you'll be pleased to know that from now on we no longer restrict you to executing them using distinct users. Yes, you heard that right, you can now execute as many such processes on the same user, at the same time. We also made several changes to our UI such that you are easily able to differentiate between processes that do require user intervention and those which don't, such that you can easily manage your processes and executions. Click here to check this out.
We've added the Jobs Priority feature y'all have been waiting for. You can now better control which job has precedence over other competing jobs. Higher priority jobs get the resources first and are executed before lower priority ones. Jobs with the same priority get executed in the order they've been created. That's it. Have fun!
Orchestrator now brings you built-in support for blob storage, using the Orchestrator database or external providers (I.e. Azure, Amazon, MinIO). These Storage Buckets are folder-scoped entities, enabling you to maintain fine-grained control over access and use of the storage and contents.
Starting with today’s deployment, you will no longer be able to start jobs or create triggers from Orchestrator on a Robot of type Studio or StudioX. This is what you need to do to keep your environment trouble-free:
- If you use Studio in production environments via unattended scheduling configured in Orchestrator, use Unattended robots.
- If you use Orchestrator in development environments to schedule and execute jobs on Studio or StudioX robots, use NonProduction robots instead.
Just a quick heads-up regarding upcoming Orchestrator changes:
Starting with 2020.4, you will no longer be able to start jobs or create triggers from Orchestrator on Studio or StudioX robots. While we are well aware this might bring adjustment pains, you need to know this happens in an effort to achieve a more streamlined business solution. Without further ado, this is what you need to do to keep your environment trouble-free:
- If you use Studio in production environments via unattended scheduling configured in Orchestrator, use Unattended robots.
- If you use Orchestrator in development environments to schedule and execute jobs on Studio or StudioX robots, use NonProduction robots instead.
In an effort to achieve better control in terms of Orchestrator performance, new queue items cannot contain Specific Data that surpasses 1 MB. Anything beyond this limit cannot be added to a queue. If you need to upload larger items, store the data in an external storage and only reference the link within the item.
We know that having too many columns in the column grid can be a pain, so for those of you who only want to see the most frequently used, we added a new button for controlling column visibility. By default, all columns are displayed on all pages. Click the Columns button and clear the check boxes corresponding to the columns you want to stay hidden. That's it. Have fun.
