Usage on a State
On this page we describe how you can use tasks on lifecycle states. This article describes the following subjects:
State Tasks
The task definitions and task templates that are configured as master data in the tasks-window are available on every lifecycle state. If you want to add specific tasks or templates to a state, you need to open the state details window by right-clicking the state. As you can see in the image below, a new tab named State Tasks appeared in this window.
If you want to use a task on a specific state, you can drag it from the toolbox to the designated area. You can also double click on a task in the toolbox. This will add it to the list box without the need to drag it there yourself.
You can add both task definitions and task templates to a state. When you select one of the added tasks, you'll be able to configure some extra properties. These properties are the practically the same on a task definition and a task template. But they are visualized a little different as explained later in this article.
Task Definition on a State
When you add a task definition to a state, you can configure some extra properties. As you can see in the image below. Some of the configured properties on a master data level, can be overwritten on the state level.
The following properties are available when you add a task definition to a state:
| Property | Description |
|---|---|
| Name | This property contains the name of the task. By default, this property contains the same name as the master data task definition. |
| Enabled | Indicates whether the task is enabled on the state. When set to false, the task will not be triggered. |
| Required | Indicates whether a task is required. If set to true, a task will block state transitions when it's not yet closed. If a task is required, it won't be able to be Lifecycle Wide. |
| Trigger Manually | This property indicates whether the task should be triggered manually. For example, when we don't want to start a task right after the previous one is done, we can opt to trigger it or start it manually. The task won't be visible for the assignee until it is triggered manually. |
| Lifecycle Wide | This indicates whether the task should block state transitions when it's not yet closed. If set to false, a started task should be closed before processing a state transition. |
| Multi Instantiable | This indicates whether the task can be instantiated again when the case re-enters the state where the task is configured on. If this task is lifecycle wide and not yet completed when the case re-enters the state, no new task will be created. |
| Re-instantiate In Current State | This indicates whether the task can be instantiated again without leaving the state where the task is configured on. The previous task instance should be closed though. |
| Owner | This contains the owner of the task. This can be overwritten by unchecking the "Inherit From Task Definition" checkbox. |
| Assigned To | These are the assignees of the task. This can be overwritten by unchecking the "Inherit From Task Definition" checkbox. |
| Expected Duration | This contains the expected duration of the task. This can be overwritten by unchecking the "Inherit From Task Definition" checkbox. |
| Property Setters | You can configure property setters on a system task. You can link output fields of the configured method to specific case properties. These properties are updated when the method is executed. |
| Start Conditions | You are able to specify the conditions when a task is allowed to start. In the example above, the task is only allowed to start when the LastName property is not empty and when the Email contains an '@'. You can use case properties in these conditions and you can also use the result of other tasks in these conditions. For example, you can configure that the task should only run when the previous task is closed successfully. |
| End Actions | You can also see the configured end actions on the task. You're not able to overwrite these end actions. |
Task Template on a State
When you add a task template to a state, you'll get the possibility to configure some extra properties on the template and you can configure each task definition in the template as well.
The following properties are available when you add a task template to a state:
| Property | Description |
|---|---|
| Name | This property contains the name of the task. By default, this property contains the same name as the master data task template. |
| Enabled | Indicates whether the task is enabled on the state. When set to false, the task will not be triggered. |
| Required | Indicates whether a task is required. If set to true, a task will block state transitions when it's not yet closed. If a task is required, it won't be able to be Lifecycle Wide. |
| Trigger Manually | This property indicates whether the task should be triggered manually. For example, when we don't want to start a task right after the previous one is done, we can opt to trigger it or start it manually. The task won't be visible for the assignee until it is triggered manually. |
| Lifecycle Wide | This indicates whether the task should block state transitions when it's not yet closed. If set to false, a started task should be closed before processing a state transition. |
| Multi Instantiable | This indicates whether the task can be instantiated again when the case re-enters the state where the task is configured on. If this task is lifecycle wide and not yet completed when the case re-enters the state, no new task will be created. All tasks configured on the template get the same configuration regarding the multi instantiability. |
| Re-instantiate In Current State | This indicates whether the task can be instantiated again without leaving the state where the task is configured on. The previous task instance should be closed though. |
| Start Conditions | You are able to specify the conditions when a task is allowed to start. In the example above, the task is only allowed to start when the FirstName property is not empty and when the Email contains an '@'. You can use case properties in these conditions and you can also use the result of other tasks in these conditions. For example, you can configure that the task should only run when the previous task is closed successfully. |
| Successful Conditions | If these conditions are fulfilled, the template is stopped, its result will be set as 'Closed' and its status will be successful. Any open tasks within the template are also stopped with the result set to 'Undefined'. |
| Failed Conditions | If these conditions are fulfilled, the template is stopped, its result will be set as 'Closed' and its status will be unsuccessful. Any open tasks within the template are also stopped with the result set to 'Undefined'. |
Task Definition in a Task Template
The task definitions that are present in a task template are also configurable. You can open the task definition details-window by right-clicking a task definition. In this window, the properties of a task definition can be overwritten.
As you can see in the example above, you can't disable a task definition in a template. It's also not possible to set a task in a template as required or lifecycle wide. These properties are inherited from the template itself.
Note
Tasks in a template are required by default. You can set the required flag to false. Be aware that if you configure a task as optional, you need to provide start conditions. If the start conditions are not met, the task will be skipped and the next task in the template will be validated.
Note
The assigned to value won't be validated if a task is configured as optional and the start conditions are not met.