In ARIS Risk & Compliance Manager, transactional objects are accompanied by tasks during their workflow. A task contains the information about which users or user groups are responsible for processing the transactional object. After logging into ARIS Risk & Compliance Manager, users can view their task list under Home > My tasks.
The users for processing a task can be specified as follows:
A list attribute is specified for the transactional object, in which users are directly assigned. By default, tasks for issues are configured in this way.
A list attribute is specified for the transactional object, in which a user group is assigned. The members of this user group are responsible for processing the task. By default, this is the most frequently used configuration. It can be used for configuring the tasks for all transactional objects apart from issues.
A role with the role level Environment-specific is specified for the transactional object. The members of the user groups assigned to the role are responsible for processing the task. The transactional object and the user groups must be assigned to the same environment.
If no user group is assigned to the role or no users are assigned to the user group, or if the transactional object is not assigned to any environment, no user is responsible for the task. By default, tasks for deficiencies are configured in this way.
A role with the role level Cross-environment is specified for the transactional object. The members of the user groups assigned to the role are responsible for processing the task. If no user group is assigned to the role or no users are assigned to the user group, no user is responsible for the task. By default, this configuration is not used.
Tasks are linked to specific workflow statuses, which determine the subsequent procedure. This set represents the scope of the task and is divided into three statuses per task:
If a transactional object reaches one of the referenced workflow statuses, a new task is started.
If a transactional object reaches one of the referenced workflow statuses, all tasks in the configuration of that transactional object are classed as completed.
If a transactional object reaches one of the referenced workflow statuses, all tasks in the configuration of that transactional object are classed as not completed.
The scope of different task configurations can overlap without causing problems. Thus, for a transactional object with a particular workflow status, there can be several tasks with various responsibilities.
A monitor strategy can be specified for each task. If it is not specified, the task has no due date for the user and retains the status Open in the system until, as a result of interaction by the user, the associated transactional object reaches the workflow status referenced by the task status Completed or Not completed. For example, in the default configuration this is the case for many reviewer tasks.
A monitor strategy specifies the processing and control period for the task. If these periods are not specified, the processing and control period for the transactional object are used. In the default configuration, this is almost always the case if a monitor strategy is specified. One exception is policies, in which the processing period for the task is specified by the plannedstartdate and plannedenddate attributes, and the control period by the controlstartdate and controlenddate date attributes.
In the default configuration, this is almost always the case if a monitor strategy is specified. One exception is policies, where the processing period for the task is specified by the publishingstartdate and publishingenddate date attributes.
All tasks with a monitor strategy are monitored by the monitoring server task. The strategy contains monitor levels, which specify what actions the monitoring server task should trigger in terms of the task. A monitor level also contains a specified time that determines when the level is classed as reached. This relates to the processing period of the task. The following settings are possible:
The monitor level is reached if, at the execution time of the monitoring server task, the elapsed processing period has reached or exceeded the specified percentage. The value must be a number between 0 and 100.
Example: Monitor level with Percentage value 50 and processing period 11/1 to 11/30. Monitor level is reached on 11/16.
The monitor level is reached if, at the execution time of the monitoring server task, the remaining time until the end of the processing period is less than or equal to the specified value. The value must be specified using a positive number followed by a letter to represent the time unit. The possible units are d (days) or h (hours).
Example: Monitor level with RemainingTime value 3d and processing period 11/1 to 11/30. Monitor level is reached on 11/28.
When a task reaches a monitor level, the monitoring server task sends the corresponding message. If no monitor messages are configured, the standard template monitorjob is used to send a message to the user responsible for the task. In the default configuration, this is the case for almost all monitor levels. Alternatively, custom messages can be defined for monitor levels. Recipients, CC recipients, the message template and the link to a list in ARIS Risk & Compliance Manager can be specified. For a monitor level of Percentage type with the value 100, monitor changes can be defined additionally to messages. Monitor changes use the monitoring server task to change values of the transactional object for the task. This can change the object to another workflow status and cause tasks to be created or closed. An example of this in the default configuration is the task configuration for tester. The task configuration for issue_owner is a further example in which an attribute value is changed but this does not have an effect on existing tasks.
If tasks are enhanced by custom attributes, the sources of the inserted values are specified by the <copyValue> XML element. The fromAttribute.idref attribute and the toAttribute.idref attribute of this XML element connect an attribute of the transactional object to an attribute of the generated task. Once the task is generated, the value from fromAttribute.idref attribute is copied to toAttribute.idref attribute. Both references must link to attributes of the same type. Exceptions: List attributes must link to text attributes. Enumeration attributes are not supported.
Location |
XML file in the xml folder |
Procedure |
Add a new <task> element at the relevant position. The combination of the id and objectType.idref properties must be unique in the entire configuration. The role.idref property is optional and is only used to display items in the task list. If specified, its value must correspond to the ID of a defined role. |
Documents |
taskconfiguration_auditmanagement.xml taskconfiguration_changemanagement.xml taskconfiguration_deficiencymanagement.xml taskconfiguration_issuemanagement.xml taskconfiguration_lossmanagement.xml taskconfiguration_policymanagement.xml taskconfiguration_riskmanagement.xml taskconfiguration_signoffmanagement.xml taskconfiguration_surveymanagement.xml taskconfiguration_testmanagement.xml |
Example |
TaskConfiguration_ModifyLevels\WEB-INF\config\custom\xml\custom.xml: TaskConfiguration_AddNewColumns\WEB-INF\config\custom\xml\custom.xml: ... All declared tasks |