All task templates are maintained exclusively in the administration area of a dispatch center. In sessions and in operations these templates are not modified; they are only evaluated. As soon as the defined conditions are met, a concrete task is generated from a template inside the operation.
Task description
The description is the visible text of the task in the operation. It must be operationally unambiguous and clearly state what has to be done or what is executed automatically.
Classification as OPTIONAL or REQUIRED
Each task template can be marked as OPTIONAL or REQUIRED. This classification has no effect on technical execution. It only defines the operational importance of the task inside the operation.
An OPTIONAL task is not mandatory. It serves as guidance or support for the dispatcher and can be executed or ignored.
A REQUIRED task is mandatory. It indicates that a defined step is compulsory. REQUIRED tasks remain visible in the operation until they are completed or explicitly handled.
Task execution mode
The execution mode defines how and when a task is executed. Manual tasks are not started automatically. They appear in the operation and must be triggered by the dispatcher. Depending on configuration, they can be executed once or multiple times.
Automatic tasks are triggered whenever Dispatch is clicked in the operation. At that moment the system evaluates all tasks that are configured for automatic execution and starts them according to their configuration. Automatic tasks can be executed once, continuously, or once with later manual re-execution. The execution mode therefore determines whether a task is only displayed as a work item or whether it is actively executed by the system.
Conditions for task creation
Whether a task template applies in an operation is controlled by conditions. Conditions compare defined operation data with predefined values. A template can contain one or more conditions. These conditions are evaluated whenever a relevant change occurs in the operation. If no conditions are defined, the task is added as soon as the operation is created.
Reference fields for conditions
The following reference fields are available for conditions:
Reference field | Description |
Operation location | Full textual representation of the operation location |
District | District or area from the operation address |
City | City from the operation address |
Object ID | Internal identifier of a POI at the operation location |
Object name | Name of a POI at the operation location |
Keyword | All keywords assigned to the operation |
Resource | Call signs of all resources assigned to the operation |
Resource ID | Internal identifiers of the assigned resources |
Resource location | Station or base of the assigned resources |
All fields are derived dynamically from the current operation data. For fields with multiple values, such as keywords or resources, each value is evaluated individually.
Condition operators
For each condition, the comparison method is defined.
Operator | Meaning |
Contains | Checks whether a field value contains the given text |
Does not contain | Checks whether no field value contains the given text |
Starts with | Checks whether a field value starts with the given text |
Ends with | Checks whether a field value ends with the given text |
Is equal | Checks whether a field value exactly matches the given text |
Always true | The condition is always considered true |
Evaluation is case-insensitive.
Condition logic
For each task template it is defined how multiple conditions are combined. Either all conditions must be true for the template to apply, or it is sufficient if at least one condition is true.
Rules for multiple creation
Task templates can be configured to create multiple tasks within the same operation. The logic is as follows: every matching value generates its own task. If a template matches multiple resources or multiple keywords, a separate task is created for each match.
Each generated task contains a specific reference to the triggering value, such as a resource name or a keyword. This keeps it traceable why the task exists. Existing tasks are not duplicated.
Optional external success confirmation
Tasks can be configured to require an external confirmation before they are considered successful. When this option is enabled, starting the task emits an event with a unique identifier. This identifier must be acknowledged via the API as successful or failed. If no acknowledgement is received, the task remains open. This is intended for technical integrations.
Optional time limit
A maximum waiting time can be defined for task templates (timeout). If neither a successful execution nor an external confirmation is received within this time, the task automatically switches to Failed. This exposes technical problems or missing responses and allows them to be handled explicitly.