The ResQueServe® platform includes several predefined task implementations. These implementations are selectable in the dispatch center administration area when creating task templates and can be used immediately.
Each implementation encapsulates a specific technical function. The selected implementation defines what actually happens when a task is executed.
The following sections describe the currently available implementations, their purpose, their behavior, and typical use cases.
Base
The Base implementation is the most fundamental task implementation in the system. It does not perform any internal operational or technical action and immediately completes the task successfully.
Its real purpose is external signaling. When a task using the Base implementation is executed, an execution event is still emitted in managed sessions. External systems therefore receive a clear notification that a task has been started.
The Base implementation is therefore primarily an external trigger, not an internal action.
Typical use cases
Starting an external process
Handling business logic outside ResQueServe®
Using a task purely as a trigger
External systems can react to the emitted event, start their own processes, and optionally send a result back via the API.
HTTP(s) Webhook
The HTTPS Webhook implementation allows external systems to be integrated via HTTPS. When the task is executed, an HTTPS request is sent to a configurable target URL.
This implementation is only executable in managed sessions. In unmanaged sessions the task is marked as Not supported.
Behavior
When the task starts, an HTTPS request is sent to the configured URL. The HTTP method can be freely chosen. Supported methods are GET, POST, PUT, and PATCH. If no method is specified, POST is used.
An optional HTTP header key and value can be defined, typically for authentication or token-based access.
The maximum wait time for a response is defined by the time limit configured in the task template. If no time limit is set, a short default is used. If the target server responds successfully, the task is marked as Completed. If an error occurs or the URL is invalid, the task ends with Failed.
Typical use cases
Notifying external systems
Integrating third-party systems
Triggering follow-up processes
Forwarding operation data to specialist applications
Single-resource suggestion
The Single-resource suggestion implementation automatically determines a suitable resource for an operation and reserves it. Based on defined criteria, the best matching resource close to the operation location is selected and preselected for the operation.
Behavior
When the task is executed, the operation data is validated. A resolved operation location with coordinates is required.
A preselection is then built using defined filter criteria. Currently, resource category is supported. Multiple categories can be specified.
It can also be defined whether volunteer resources, full-time resources, or both should be considered.
Only available resources are considered. All other statuses are explicitly excluded.
From the resulting set, the best suited resource is selected and automatically reserved for the current operation.
If no suitable resource can be found, the task ends with Failed.
Typical use cases
Automatic preselection of a response unit
Standardized suggestions for specific keywords
Reducing dispatcher workload for routine reinforcements, for example adding a second ambulance
This implementation is especially effective when combined with automatic tasks on dispatch.