Limit Workflows

This section describes how to use the out-of-the-box workflows in Atoti Limits.

What is a workflow?

In the context of Atoti Limits, a workflow is a sequence of tasks that are executed to manage the lifecycle of an object; in our case a limit or an incident. These tasks can executed by users (user tasks) or by the system (service tasks) to perform actions such as modifying the object state, notifying users of relevant information, or kicking off other workflows.

Why do I need workflows?

Managing object lifecycles can be complex, especially when multiple stakeholders are involved or when there are various conditions that need to be met before an object can transition from one state to another. Workflows help to automate and streamline these processes, ensuring that all necessary steps are followed, while also providing an audit trail of the object’s history to ensure compliance and accountability.

What objects are managed by workflows in Atoti Limits?

Limits and incidents are the two objects managed by workflows in Atoti Limits. These objects are fundamental pieces of Atoti Limits and managing their lifecycles effectively is crucial.

The object(s) managed by a workflow is determined by the activeviam.apps.workflow-service.business-functions property for the workflow in application.yml. Atoti Limits provides the following default business functions:

• Limit Changes - Manages the lifecycle of limits
• Incidents - Manages the lifecycle of incidents

How are workflows implemented in Atoti Limits?

Workflows in Atoti Limits are created using Business Process Management Notation (BPMN) and Activiti is the workflow engine of choice. Workflows are outlined in .bpmn files and in the context of Atoti Limits a Workflow is synonymous with a Process.

For more information on workflows, BPMN and Activiti, please see:

• BPMN.org for details on the specification
• BPMN.io for web tools used to design and edit bpmn files. Note that these bpmn files can be included in Atoti Limits
• Activiti for details on customizing workflows for the Activiti workflow engine

What workflows are provided out-of-the-box in Atoti Limits?

Limit Workflows

The following workflows are provided out-of-the-box to manage the lifecycle of limits:

• Six-Eyes Approval Process - Requires two separate approvals for new limits or when updating or deleting existing limits.

The remaining workflows are legacy workflows. They are maintained for backward compatibility and to simplify migration efforts, but they will be removed in a future release.

• FourEyes - Requires a single approval for new limits or when updating or deleting existing limits.
• StraightThrough - No approvals are required. New limits are immediately active upon creation, and updates or deletions are applied immediately.

Incident Workflows

The following workflows are provided out-of-the-box to manage the lifecycle of incidents:

• Incident Review Process - Manages the lifecycle of incident breaches and warnings, allowing them to be reviewed by users to classify them and determine the appropriate resolution.

The remaining workflow is a legacy workflow. It is maintained for backward compatibility and to simplify migration efforts, but it will be removed in a future release.

• Exception - Legacy version of the Incident Review Process workflow. Unless you have a specific need to use this workflow, we recommend using the Incident Review Process workflow to manage incidents.

How do I pass information when starting a workflow?

The Atoti Workflow Service allows workflows to be configured with initializing-variables that are stored in the workflow when a new one is initiated. These variables can then be used at various stages of the workflow to perform actions based on their values or provide information to the user.

Initializing variables are rendered as input fields in the limit structure form and in each limit row. The values set in the limit structure form are used as default values in the limit rows, but they can be overridden on a per-limit basis. The values set in the limit row are then passed to the workflow when it is started.