What's new

This page provides a brief overview of the user-facing new features and improvements in the latest version of Atoti Limits.

4.2.0

Summary

New features

• Limit and incident workflows powered by new workflow service
• Limit context provided alongside limit KPIs
• Custom workflow status mapping
• Define limits on calculated measures

Improvements

• Enhanced task screen filtering
• Improved columns in status screen
• 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.

Custom workflow status mapping

When using custom workflows, status values may differ from those in the default limit workflows. 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 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.