- Release notes
Orchestrator Release Notes
July 2023
We are constantly striving to make our roles as intuitive and self-contained as possible, so that you can more easily determine which one best fits your needs.
As such, this is what you can expect starting with August 21st in Community and August 28th in Enterprise:
-
The Automation User role will no longer have permission to publish packages, and will abide by its initial definition, namely a user with the minimum folder level permissions needed to execute processes. This is a governance best practice to ensure that personal user packages do not accidentally get published without first being reviewed.
-
You will have access to a new role, Automation Publisher, which is dedicated to proficient users who can publish their own packages.
Webhooks have been added to the list of entities that can be returned in the Search in tenant page.
Manual retries are not counted towards the maximum number of retries you set for queue items.
To align with this behavior, the following parameter changes have been applied when manual retries are performed from the API:
-
RetryNumber
is now0
-
AncestorId
is nownull
Individual queue items now get their own unique key upon retrial, whereas before they would inherit the parent's key.
This applies to both automatic and manual retries.
When the connection to the credential store which contains robot credentials is not established, thus preventing the password from being retrieved, the robot is no longer started, and you are now returned the following error:
Unable to retrieve credentials from {credential_store_name} credential store. Please check your connection settings and ensure the {credential_store_name} service is running.
Unable to retrieve credentials from {credential_store_name} credential store. Please check your connection settings and ensure the {credential_store_name} service is running.
This prevents you from being locked out of the robot account due to repeated attempts to start the robot without credentials.
We have added four new columns to the Transactions page (Queues > View Transactions):
-
Deadline (absolute)
-
Postpone (absolute)
-
Started (absolute)
-
Ended (absolute)
Note that they are not enabled by default, so make sure to select them from the Columns list.
These columns are also included in exported reports.
We have changed our retention policy for recorded videos. Now, when you choose to record a job execution from the settings of its underlying process, the video is stored in Orchestrator as follows:
-
for 7 days in the case of failed jobs
-
for 3 days in the case of successful jobs
We have added new settings to help you control when triggers are disabled following job failure. This is what you can now benefit from:
- A new setting in the time trigger and queue
trigger creation window, namely Set execution-based trigger disabling. When the
toggle is enabled, you are presented with two options:
- Disable when consecutive job execution fail count – the trigger is disabled after the number of failed executions you choose for this setting.
- Grace period on disabling the
trigger (days) – the number of days to wait before the trigger is disabled after
the first failure of a job.
Note:
In case you're running a Serverless robot in a Community instance, the following execution values are automatically set, and cannot be edited:
- Disable when consecutive job execution fail count - 10.
- Grace period on disabling the trigger (days) - 0.
This means the trigger will get disabled on the day when the job failed 10 consecutive times, to prevent the consumption of Robot Units from constantly trying to execute the job successfully.
- Two new
tenant-level execution settings aimed at connected event, time, and queue
triggers (i.e. triggers created in Studio Web) automatically published to personal
workspaces:
- Triggers - Connected triggers - Disable when job execution fail count - the trigger is disabled after the number of failed executions you choose for this setting.
- Triggers - Connected triggers - Grace period when job execution keeps failing count (days) - the number of days to wait before the trigger is disabled after the first failure of a job.
These do not apply to triggers published outside of personal workspaces.
We have streamlined the way data is exported from grids. These are the changes you can benefit from now:
-
When you click Export, you are no longer asked for confirmation. Instead, you are shown a notification letting you know that the export is in progress.
- Once done, another notification is displayed, letting you know that the exported data is ready for download.
-
The download then starts automatically if you have the Alerts - View permission.
- If you don't, you can download the exported data from the My Reports page.
Two tenant-level execution settings have been renamed, so as to help you find your way around with ease:
- Triggers - Disable when failed count is now Triggers - Disable when job creation fail count
- Triggers - Disable when it keeps failing count (days) is now Triggers - Grace period when job creation keeps failing count (days)
Internal packages, namely packages uploaded via Orchestrator-hosted feeds, are now sorted by published date. The published date is the date when the most recent version of a package was published.
The recurrent execution of time triggers, queue triggers, and test schedules is now based on their creation time. While they were previously triggered at second 0 of every minute, they are now triggered at the same second as the one in their creation time.
This is how the change translates in cron expressions:
-
For a time trigger created at 12:23:34 with the cron expression 0 * * ? * * (i.e. set to run every minute), the next execution time will be at 12:24:34.
-
For a time trigger created at 12:23:34 with the cron expression 1 * * ? * * (i.e. set to run at 1 second past every minute), the next execution time will be at 12:24:01.
Robots can now download packages from the tenant feed as long as they have the View on Packages permission.
Manual retries are not counted towards the maximum number of retries you set for queue items.
To align with this behavior, the following parameter changes will be applied when manual retries are performed from the API:
-
RetryNumber
will be0
-
AncestorId
will benull
This change is scheduled to happen in two weeks' time in Community and in a month's time in Enterprise.
Upcoming change to permission checks
Creating a queue trigger from the user interface requires Queues permissions. However, this enforcement is not currently in place for API-triggered actions. As such, within a month, we will also start checking for the Create on Queues permission when you try to create a queue trigger from the API. Please make sure that you meet this requirement before that time.
The date when a change is first announced in the release notes is the date when it first becomes available.
If you don't see the change yet, you can expect to see it soon, after we roll out changes to all the regions.
We recommend that you regularly check the deprecation timeline for any updates regarding features that will be deprecated and removed.
- 26 July 2023
- Upcoming changes to roles and permissions
- 24 July 2023
- Webhooks in tenant search
- Manual retries changes
- Queue item unique key
- Credential store connection error
- New transactions columns
- 20 July 2023
- Retention of recorded videos
- 18 July 2023
- Execution settings changes
- Report exports improvements
- 11 July 2023
- Renamed execution settings
- Internal package sorting
- Trigger execution changes
- Permission checks for package downloads
- Upcoming manual retries change
- Breaking change
- When can I see these changes?
- Deprecation timeline