22 September 2020
The new Orchestrator UX heralds a brave new world for your deployment management - out with Classic (folders) and into a Modern only world. We have disabled classic folders for all new tenants, making the modern paradigm the default option for new users and deployments.
This shift comes with a host of improvements for those already familiar with modern folders: you can now easily move folders in or between hierarchies, delete folders and all their associated entities, and modify the associated permissions for the default folder roles.
To get you even closer to a ready-to-automate place, new tenants have personal workspaces enabled by default and the five out-of-the-box roles created automatically. Hand-in-hand with the switch to a modern-only approach, the associated permissions of the default modern folder roles have been updated.
Allow to be Folder Administrator (formerly Enable Folder Administration)
Allow to be Automation User (formerly Enable Running Automation)
The Administrator user comes with the following roles at the tenant level: Tenant Administrator, Allow to be Folder Administrator, Allow to be Automation User, and Administrator.
To offer a clearer separation between a folder admin's attributions and those of a tenant admin, we removed robot management privileges from folder-focused roles (Allow to be Folder Administrator and Allow to be Automation User). As a best practice, we recommend creating a separate role consisting of Robots permissions and assign it to users who need it in a controlled manner.
To further simplify access control, we deprecated the Inherit From Tenant assignment model. Existing modern folders that previously used an Inherit From Tenant model are converted, with each user receiving their tenant roles at the folder level as well.
Let’s illustrate the conversion with an example. Let say Petrina Smith works in the Finance and HR folders which previously used the Inherit From Tenant permission model. The role inherited from the tenant will be assigned to the user at the folder level, on a per-folder basis. As a result, Petrina is assigned the role in both the Finance and HR folders, as well as keeping it at the tenant level.
For those still clinging to the classical, don't worry. Existing deployments do not lose classic folder support on upgrade, and to further entice you into the future we've also added a migration tool to enable you to quickly and easily move to the new, modern-only world.
To streamline robot migration from classic folders to modern folders, we've made it possible to enable/disable robots residing in classic folders easily. This way, you are presented with a rollback option if a step errors out during migration. You can only disable robots in the following connection states: active, disconnected, unresponsive.
Learn about enabling/disabling robots in classic folders.
Enabling a robot
To help with delegating responsibilities in your company while keeping packages separate, first-level folders can now be created with a dedicated packages feed. See how here.
Access to the feed is controlled by a new folder-scoped Folder Packages permission set. All subfolders inherit the package feed setting from the root parent.
Personal Workspaces Experience
Personal workspaces come with their own packages feed by default and mark a historical minimum in package deployment efforts. Any package that is added to the workspace gets automatically deployed as a process in the workspace.
Starting now, Orchestrator takes over machine template management from the user. This removes unnecessary overhead from the developer who can begin working in the context of that workspace right away publishing automation projects and launching jobs from Orchestrator for debugging purposes.
Users that work in other folders besides their personal workspace can benefit from the Orchestrator debugging capabilities of their machine template by assigning it to the folders they are working in (i.e., the folders they have been assigned to).
Simplified UI Profile
To help new users in their automation journey, we've added a simplified UI profile in Orchestrator for those using personal workspaces. The user experience is stripped down to the functionality available in their workspace. Learn about UI Profiles.
Personal Workspaces Administration
This release graduates key capabilities in personal workspace management, bringing about multiple improvements for all personal workspace administrators and business owners out there.
Keep an eye on all workspaces from a centralized location and give a helping hand to developers in their daily activities by exploring the contents of their workspaces at a glance.
Keeping Orchestrator clean of unused data is now a breeze. You can quickly identify all workspaces with little or no activity, or those which have been orphaned upon employees leaving the organization. The clean-up strategy is at your discretion and is pretty much hassle-free, as you can either delete or convert the workspace into a folder from the convenience of the dedicated Personal Workspaces page.
Enabling personal workspaces for numerous users is now a seamless process with a new feature allowing you to enable workspaces for multiple users at once. The Personal Workspaces section on the Settings page is the dedicated place for that. Here, an administrator can enable personal workspaces for all users in a tenant that use a particular attended licensing profile and don't yet have a workspace to call home.
Read about Personal Workspaces.
Start Job on a Specific Machine
If you were looking for better-debugging capabilities, rest assured, as of now, you can select the host machine on which a certain job is launched. Click here for details about jobs.
Unattended Robots for Local Users
To ease unattended automation ordeals concerning local Windows users residing on multiple host machines, we ensured that unattended robots impersonating local accounts require the corresponding Windows username and password only. The host machine is no longer a mandatory identifier.
Say you are using LocalUser1 on five host machines. Instead of setting up five user entities in Orchestrator for each combination,
you define the unattended robot on one user entity only, using the
.\LocalUser1 syntax in the Domain\Username field. This way, you can use that specific Windows account on each host machine through one Orchestrator user entity only.
Nothing changed for domain-joined accounts, where the robot requires the
domain\username syntax just as before.
Asset per User
To better align with your business needs, we've introduced assets per user, the modern counterpart of classic per-robot assets. Per-user assets improve the logic behind assets in modern folders by creating a precise mapping between the user and the credential used during execution.
Restricting Concurrent Execution
For scenarios where a user cannot log in more than once at a time, we've introduced the possibility to restrict concurrent unattended execution. This helps modulate the job allocation algorithm by restricting a user from simultaneously executing multiple jobs.
HSM Providers Management
For better control in terms of HSM providers, you can now choose from the convenience of your Orchestrator tenant which hardware security model to use for retrieving unattended Robot credentials.
This eliminates the need to configure the HSMs at the Robot level and streamlines the authentication experience in unattended scenarios.
Wait Queue Item Activity
You can encounter delays of up to 30 seconds if you use a Wait Queue Item activity older than 2020.10. Upgrade to the latest activity version to avoid such issues.
We have made significant changes to how we generate the
swagger.json file, which describes the Orchestrator API. If you rely on a client library generator that uses the API description in the
Swagger file (e.g., AutoRest, Swagger Codegen), the generated code will be significantly different.
APIs With Form POST Parameters
POST requests with parameters in form-data objects no longer works. The only supported mechanism to make
POST requests to Orchestrator is to include the request parameters in a JSON in the request's body.
Always Running Processes
To increase the control you have over your processes, we've added the Always Running Process option on the Process Setting page to restrict process termination from the UiPath Assistant. Learn how to manage processes.
Classification Station is a new feature that enhances human-robot collaboration by allowing humans to review and correct document classification and splitting results. It can be used both as an attended activity (through Present Classification Station) as well as integrated into Orchestrator’s Action Center by leveraging Long-Running Workflows (through Create Document Classification Action and Wait for Document Classification Action and Resume).
Automatic Trigger Disabling
As of now, a trigger gets disabled automatically after 10 failed launches if it hadn't been launched successfully at least once in the past day.
Test Data Management
Decrease your time spent on testing by managing your test data through test data queues and synthetic test data creation. The Test Data Queue is your central storage where you can prepare, store, and consume test data. You can expand your testing efforts through test cases that store and consume queue items in and out of the test data queues, on a FIFO (first-in-first-out) order.
A notable addition in this release includes Action Center support for modern folders. If up until now you were restricted to only using it in classic folders, from now on, you can take advantage of all Action Center goodies regardless of the folder type.
We also added a new page exclusively for the Action Admins in your company, such that they are easily able to allocate and assign actions to any Action User from a centralized location.
Among all the usability improvements we are excited about, this release we are incredibly excited about solving some common frustrations regarding processes. Learn more about updating processes at the package level.
To help you identify and differentiate processes from one another, they now inherit the associated package description set at design time in Studio. This happens regardless of whether they are deployed manually or automatically in a personal workspace. You can also add a description to your processes or edit the existing one as you wish, no restrictions imposed. Learn here how to add a process to Orchestrator.
Updating processes across multiple folders to the latest available package version just became easy-breezy with a new bulk update feature, which enables you to upgrade all processes associated with a package. Simply select the target packages, and Orchestrator does the job for you by searching for and displaying all associated processes that do not use the latest available package version. Choose the processes to be updated to the latest available package version, and you’re done.
How to read the letters:
a. The name of the package
b. The latest version of the package
c. The number of processes not using the latest package version
d. The names of the processes, along with the current package version and the path of the folder/subfolder they reside in.
You can now preview any changes made to the header color and logo such that you can adjust them accordingly before saving your changes.
You can now assign users, user groups, and machine templates directly at the folder level by navigating to the Settings page in a folder context.
Assigning machine templates to folders has been made easier than ever with the addition of new capabilities previously only available on the Machines page. As a result, you can now copy a machine’s key and edit its runtimes directly from the Folders page. Bear in mind, machine templates need runtimes in order to be fit for execution, so make sure you assign some when assigning the machine to a folder.
To have a better, ready-to-hand overview of your Orchestrator statistics, you can now navigate from the job counters on the Home page to the corresponding Jobs page, which is filtered accordingly. For example, if you click the section corresponding to running jobs, the displayed page has the Running state filter applied.
The Processes page now displays the package name associated with each process.
You can now easily update the default roles with any additionally required permissions.
Publishing test automations with test cases automatically creates a process if it is not already in place.
Test Schedule creates a new test execution only if the previous run has finished.
Execution Media is now supported for your test executions so that you can view any screenshots taken from failed executions.
Create test sets directly on the Test Cases page.
Test sets created through external tools are now visible only through API and will not be shown on the Test Sets page.
We now perform a couple of additional validations upon uploading test automation packages. In order to successfully upload such a package or package version, make sure the following:
- The package contains at least one entry point.
- The project type is the same in between different versions of the same package.
We improved performance for release version filtering and test set creation.
You can now choose from all available versions when selecting packages for test set creation.
We know the pain of having your jobs stuck in a Terminating state, so we came up with a couple of solutions to help clean up the clutter. You can now transition jobs to a Terminating state by using the Kill command. Moreover, we've added a cleanup background job that runs once every three hours and transitions to Failed the jobs that have been in a Terminating state for at least one day.
We've added a new webhook (
task.saved) for saving actions to notify you whenever an action has been saved prior to completion.
You can now filter logs by the name of the host machine they have been generated on by using the Machine filter on the Logs page. The new filter works retroactively for logs stored in ElasticSearch, while for logs stored in the database, it only works for new log entries.
To keep you notified about everything going on in Orchestrator, we've implemented alerts for Folders and Personal Workspaces. Learn about alerts.
As of now, the
OData.BackwardsCompatible.Enabled parameter is set to
true by default, meaning Orchestrator parses and preserves special characters by default and no longer uses encoding and escaping
mechanisms to transform input data for dynamic properties in OData models (e.g., QueueItem.SpecificContent).
OData.BackwardsCompatible.Enabled defaulted to
false, meaning special characters were encoded/escaped unless you specified the data type when performing an API request, by using
the following syntax:
If your automation projects are designed to overcome character encoding/escaping any other way than using the method presented
above (such as Regex unescaping expressions), make sure to adjust them accordingly as they might not work from now on. Either
that or set
false to preserve past behavior.
- Package versions that contain the
+symbol are unusable in Orchestrator as they cannot be used to create processes.
- The localization of Orchestrator feeds in Studio disregards the Robot language settings and causes the feeds to be displayed in English regardless of the Robot language.
- The error message resulted from incorrectly creating or updating a credential store that was not displayed on the Alerts page, and no detail about the misconfiguration was available.
- Killing a test execution job resulted in an incorrect job state in Orchestrator.
- Users with Folder Administrator roles did not have access to testing features after meeting the prerequisites unless granted manually.
- Disabling test automation did not disable any running test schedule.
- Previously, you could not edit user groups with names longer than 32 characters. We have increased the character limit for group names (Group or Username field) to 256.
9 September 2020
Removed Standalone Licensing
You can no longer license your Studios locally when using Automation Cloud Orchestrator services. In this respect, we removed the Stand-alone License checkbox from Orchestrator. Customers who licensed their Studio/StudioX/Studio Pro locally prior to this change are not impacted, however, they cannot use this feature for additional Studios.
We can enable this feature on demand. Contact us.
Enable/Disable Robots in Classic Folders
To streamline robot migration from classic folders to modern folders, we've made it possible to easily enable/disable robots residing in classic folders. This way, you are presented with a rollback option if a step errors out during migration. You can only disable robots in the following connection states: active, disconnected, unresponsive.
Disabling a robot impacts associated entities as follows:
- You cannot configure triggers to use disabled robots
- Disabled robots are removed from existing triggers that make use of that specific robot. If there is no other specific robot defined, the trigger throws errors as it cannot create jobs.
Assets per robot
- Disabled robots are removed from assets with per robot values
- If the asset only has one robot value and we disable the robot, the asset remains in an inconsistent state and cannot be modified.
Reenabling the robot renders all impacted entities usable.
The Processes page now displays the package name associated with each process.
- Disabling test automation did not disable any running test schedule.
- 22 September 2020
- Modern Folders
- Folder Packages
- Personal Workspaces Experience
- Personal Workspaces Administration
- Unattended Automation
- Wait Queue Item Activity
- Swagger Library
- APIs With Form POST Parameters
- Always Running Processes
- Classification Station
- Automatic Trigger Disabling
- Test Data Management
- Breaking Changes
- Known Issues
- Bug Fixes
- 9 September 2020
- What's New
- Bug Fixes