- Release notes
Orchestrator release notes
February 2025
We have enabled the new union of privileges permissions model for Enterprise organizations. Starting today, you have three months to migrate to this model. In case you do not take action, we will handle the migration for you.
For more details, check Migrating from break inheritance to union of privileges.
To help free up the Orchestrator database and improve performance while ensuring that you can still access your audit logs, we are working on an audit log retention feature that we will introduce in the coming months.
As a starting point to assist you in evaluating the benefits of the upcoming changes, here are the feature highlights:
- Audit logs are stored in the Orchestrator database for a duration extending to at least the last six months. During this time, they are visible and searchable in the interface.
- Once per month, Orchestrator archives the audit logs for the calendar month that has moved outside the most recent six-month window. For example, the logs for November 2024 are scheduled for archival at the beginning of June 2025. Once the audit logs for a calendar month have been archived, they are removed from the Orchestrator database and are no longer searchable. However, we will provide a place in the Orchestrator interface from where you can download the monthly archive files.
- Audit log archives are available for the 18 months that precede the most recent six-month window, ensuring that the audit log data is available to you for the same 24-month period as today. Archives older than 24 months are automatically deleted.
We will publish the feature release notes and relevant documentation updates on the Community release date.
You can choose to auto-refresh logs at a ten-second interval for jobs that are not either in a Pending state or in a final state. The option is available in the Logs section of the job side panel. For more information, see Viewing job logs.
We have changed the behavior around initiating updates during job execution. As such, Robots no longer force an update if a job is still running. Furthermore, during an update, active Robots enter a maintenance mode, ensuring they do not take on any new jobs until the update is complete.
This change also means that the 10-minute wait time for service-mode Robots is no longer applicable.