> ## Documentation Index > Fetch the complete documentation index at: https://docs.activeviam.com/llms.txt > Use this file to discover all available pages before exploring further. # Release notes From version 6.1.20 onwards, Atoti Limits version numbers are aligned with the Atoti Java SDK. Previously, Atoti Limits used its own versioning (the last release under the old scheme was 4.2.2). The jump in version numbers reflects this alignment. There are no missing releases between 4.2.2 and 6.1.20. For the list of changes and fixes covered in this release, see the [Changelog](./changelog). For information on upgrading from previous versions, see the [Migration guide](./migration-guide) Follow [this link](https://activeviam.jfrog.io/artifactory/activeviam-accelerators-artifacts/limits/6.1.22/) to download the zipped distribution files for: * **UI source code** * **UI build** * **Source files** to build the module * **Sample bookmarks** * **Maven repository** required to build the project and run the tests. This release does not ship any changes. Follow [this link](https://activeviam.jfrog.io/artifactory/activeviam-accelerators-artifacts/limits/6.1.21/) to download the zipped distribution files for: * **UI source code** * **UI build** * **Source files** to build the module * **Sample bookmarks** * **Maven repository** required to build the project and run the tests. * ### Summary **Improvements** * [Bug fixes and performance improvements](#bug-fixes-and-performance-improvements) ### Improvements #### Bug fixes and performance improvements This is a bug fix and performance release. Please see the [Changelog](./changelog) for more details. Follow [this link](https://activeviam.jfrog.io/artifactory/activeviam-accelerators-artifacts/limits/6.1.20/) to download the zipped distribution files for: * **UI source code** * **UI build** * **Source files** to build the module * **Sample bookmarks** * **Maven repository** required to build the project and run the tests. ### Summary **Improvements** * [Bug fixes and performance improvements](#bug-fixes-and-performance-improvements) ### Improvements #### Bug fixes and performance improvements This is a bug fix and performance release. Please see the [Changelog](./changelog) for more details. Follow [this link](https://activeviam.jfrog.io/artifactory/activeviam-accelerators-artifacts/limits/4.2.2/) to download the zipped distribution files for: * **UI source code** * **UI build** * **Source files** to build the module * **Sample bookmarks** * **Maven repository** required to build the project and run the tests. ### Summary **New features** * [Uploaded Six-Eyes limits can be auto-approved](#uploaded-six-eyes-limits-can-be-auto-approved) **Improvements** * [Limit evaluation scheduling](#limit-evaluation-scheduling) * [Limit repository change](#limit-repository-change) ### New features #### Uploaded Six-Eyes limits can be auto-approved Limits using the Six-Eyes Approval Process workflow may now be automatically approved, foregoing both levels of approval that are typically required, when created via file upload by users that have the `ROLE_AUTO_APPROVE_LIMIT` permission role. ### Improvements #### Limit evaluation scheduling The scheduled evaluations of limit structures have been improved to be more robust and to provide more API and REST options. For more information, see the section on [Evaluating Limits](../dev/evaluation-tasks). #### Limit repository change The Atoti Limits codebase now lives within the Atoti Server codebase, which streamlines dependency management. Follow [this link](https://activeviam.jfrog.io/artifactory/activeviam-accelerators-artifacts/limits/4.2.1/) to download the zipped distribution files for: * **UI source code** * **UI build** * **Source files** to build the module * **Sample bookmarks** * **Maven repository** required to build the project and run the tests. The Atoti Server 6.1.16 Maven repository files can be downloaded from [here](https://artifacts.activeviam.com/share/ActivePivot_stable/6.1.16). * **Atoti Limits Python Extension** ### Summary **New features** * [Atoti Limits Python extension](#atoti-limits-python-extension) * [New Direct limit approval process](#new-direct-limit-approval-process) **Improvements** * [Limit evaluation performance improvements](#limit-evaluation-performance-improvements) ### New features #### Atoti Limits Python extension The new Atoti Limits Python extension allows users to connect an Atoti Python session to a running Atoti Limits server. See the [Atoti Python integration section](../dev/integration/python) for more details. #### New Direct limit approval process Atoti Limits now has a new Direct limit approval process which uses the more performant `workflow-service`. This workflow does not require any approvals for limits to be created, updated or deleted. This workflow should be preferred to the `StraightThrough` workflow. See [the Direct approval process section](../dev/limit-workflow/default-workflows/direct-approval-process) for more details. ### Improvements #### Limit evaluation performance improvements We have improved performance in limit evaluation by caching work across locations and implementing better fast-failure mechanisms for invalid locations. Follow [this link](https://activeviam.jfrog.io/artifactory/activeviam-accelerators-artifacts/limits/4.2.0/) to download the zipped distribution files for: * **UI source code** * **UI build** * **Source files** to build the module * **Sample bookmarks** * **Maven repository** required to build the project and run the tests. The Atoti Server 6.1.13 Maven repository files can be downloaded from [here](https://artifacts.activeviam.com/share/ActivePivot_stable/6.1.13). ### Summary **New features** * [Limit and incident workflows powered by new workflow service](#limit-and-incident-workflows-powered-by-new-workflow-service) * [Limit context provided alongside limit KPIs](#limit-context-provided-alongside-limit-kpis) * [Custom workflow status mapping](#custom-workflow-status-mapping) * [Define limits on calculated measures](#define-limits-on-calculated-measures) **Improvements** * [Enhanced task screen filtering](#enhanced-task-screen-filtering) * [Improved columns in status screen](#improved-columns-in-status-screen) * [Performance improvements](#performance-improvements) ### New features #### Limit and incident workflows powered by new workflow service A new workflow service has been introduced to streamline the configuration and execution of limit and incident workflows. Key benefits include: * **Simplified setup**: User tasks are now configured directly, while service tasks are defined via Spring beans. * **Runtime flexibility**: You can now provide additional context, such as attaching emails, when initiating workflows. * **Performance boost**: Bulk operations are significantly faster, supporting high-volume use cases. This release introduces two default workflows built on the new service: * **Six-Eyes workflow**: A standard approval process for limits requiring two levels of authorization before evaluation. * **Incident review workflow**: A simplified incident handling process designed for faster review and easier customization. Both workflows are provided out of the box and are fully supported by the new workflow service. The previous workflows remain available and continue to operate using the legacy workflow engine, ensuring backward compatibility. #### Limit context provided alongside limit KPIs You can now view the specific limit affecting a KPI’s status directly within the dashboard, allowing for quick identification of warning or breach triggers. With appropriate permissions, you can also request a temporary limit increase from this view. This streamlines the process, letting users proactively manage limits. For instance, before executing a trade, a user can perform a what-if check. If this check indicates a potential breach of the current limit, they can then request a temporary limit increase to prevent it. For more information, see [KPI Drawer](../user-ref/viewing-limits/in-the-cube#kpi-drawer). #### Custom workflow status mapping When using custom workflows, status values may differ from those in the [default limit workflows](../dev/limit-workflow). To ensure consistent behavior across Atoti Limits, you can now map these custom statuses to standard limit actions. This mapping allows the system to correctly interpret whether a limit is active, evaluable, visible in KPIs, or pending, regardless of the specific status labels used in your workflow. See the [custom workflow statuses section](../dev/dev-extensions/custom-workflow-service/custom-workflow-statuses) for more details. #### Define limits on calculated measures You can now define limits on calculated measures where the underlying is a hierarchy. ### Improvements #### Enhanced task screen filtering The Status screen lets you quickly view your outstanding tasks, enabling prompt action. Other incidents and passes can still be viewed using the switch located above the table. Additionally, screens can be pre-filtered by selected IDs allowing notifications to link directly to relevant tasks. #### Improved columns in status screen The Status screen now displays workflow variables as columns. This enhancement enables better analysis of incidents by making custom fields visible within the view. Additionally, the **Limit type**, which indicates whether an incident resulted from a temporary or permanent limit, is now shown by default. #### Performance improvements This release brings several enhancements that significantly improve system responsiveness and scalability: * **Faster KPI evaluations**: Evaluations are now quicker thanks to smarter caching and more efficient compatibility checks between limits and locations. Irrelevant data is automatically excluded to reduce processing time. * **Improved UI responsiveness**: When viewing KPIs, large evaluation requests are now broken into smaller batches to prevent freezing and ensure a smoother user experience. * **Bulk workflow execution**: New services have been introduced to start limit and incident workflows in bulk, reducing delays when processing large volumes of data. This is especially beneficial during post-evaluation when many incidents are created at once. * **Faster reloading on restart**: The system now reloads persisted limits more efficiently during server startup, reducing downtime and improving overall responsiveness.