Notifications
Description
Camunda workflows running in an OMN context (started via OMN-UI or programmatically using the workflow Java services in OMN) are internally using a notification service mechanism to send notifications to the user.
By default all asynchronous Camunda workflows send error notifications in case they land in an incident. These notifications are visible in the OMN Message Client for the user who started the workflow. In case the notification level is set to INFO these workflows will also send notifications when the workflow succeeds. Several parameters like receiver, notification subject and body are also configurable.
Configuration
The following properties can be configured on every Camunda workflow in WFLConfig FunctionPlugin:
To keep the table compact we abbreviated the keys. Keep in mind that the prefix must always be "ext.notification", for example "ext.notification.default.disabled" instead of ".default.disabled":
| Key (* = required) | Type | Default | Description |
|---|---|---|---|
.default.disabled |
boolean |
false |
Indicates whether notifications should be disabled completely |
.default.level |
string |
WARN |
Describes the notification level. Can have the following possible values: INFO means all notifications at level INFO or lower are processed. WARN means all notifications at level WARN or lower are processed. ERROR means only ERROR notifications are processed. Automatic error notifications for workflows that land in an incident are sent at Level ERROR while automatic success notifications for workflows that complete successfully are sent at Level INFO |
.default.from.application |
string |
Camunda |
Describes the sender application, a field used to describe the general context this notification was send from. In Message Client this value will be displayed in "Sender Application". |
.default.from.plugin |
string |
Workflow Process Definition Key in BPMN, like 'ai-imageprocessing-autoretouch' |
Describes the sender plugin, a field used to further describe the sub-context this notification was send from. In Message Client this value will be displayed in "Sender Plugin". The idea is that 'from.application' describes the general application and 'from.plugin' describes a more concrete sub-module or sub-component of this application. |
.default.to.users |
string (multi-value) |
User which started the WFL (taken from 'sub' claim on JWT token) |
The user names this notification should be sent to |
.default.to.roles |
string (multi-value) |
The role names this notification should be sent to. If both 'to.users' and 'to.roles' are set then the notification will be sent to both: all the users and all the roles. |
|
.default.subject.error |
string |
%processDefinitionName failed |
The subject which will be used for error messages. Can contain placeholders (see below) |
.default.subject.success |
string |
%processDefinitionName succeeded |
The subject which will be used for success messages. Can contain placeholders (see below) |
.default.body.error |
string |
The following workflow failed: Workflow-Name: %processDefinitionName Workflow-Key: %processDefinitionKey Workflow-ID: %processDefinitionKey Workflow-VersionTag: %processDefinitionVersionTag Workflow-DeployVersion: %processDefinitionVersion Started: %processInstanceStartDate Finished: %processInstanceEndDate Duration: %processInstanceDuration Referenced Objects: %relatedObjects Error Message: %technicalMessage |
The body which will be used for error messages. Can contain placeholders (see below) |
.default.body.success |
string |
The following workflow completed successfully: Workflow-Name: %processDefinitionName Workflow-Key: %processDefinitionKey Workflow-ID: %processDefinitionKey Workflow-VersionTag: %processDefinitionVersionTag Workflow-DeployVersion: %processDefinitionVersion Started: %processInstanceStartDate Finished: %processInstanceEndDate Duration: %processInstanceDuration Referenced Objects: %relatedObjects |
The body which will be used for success messages. Can contain placeholders (see below) |
.default.parameters |
string (multi-value) |
List of workflow config parameter keys which should be included. Will be shown in "Parameters" tab in Message Client |
You can configure multiple notification groups by using another group-name than "default". For example the following configuration introduces a new group 'myMessages' and would send the configured success message to user 'jdoe' (the default values are taken for the other keys):
ext.notification.myMessages.level=INFO
ext.notification.myMessages.to.users=jdoe
ext.notification.myMessages.subject.success=Jippi jay jey. WFL Success!
ext.notification.myMessages.body.success=Holy guacamole. Your workflow made it all the way home!Placeholders
In the subject as well as in the body config values you can use the following placeholders which will be resolved in the actual message if available:
| Placeholder | Resolved Value |
|---|---|
%relatedObjects |
The name of the objects the WFL was started on |
%processDefinitionName |
The name of the process definition |
%processDefinitionKey |
The key of the process definition |
%processDefinitionId |
The id of the process definition |
%processDefinitionVersion |
The deployed version of the process definition (the number how many times a new BPMN with this key and version tag was deployed) |
%processDefinitionVersionTag |
The version tag of the process definition (OMN version) |
%processInstanceStartDate |
The start date of the process instance |
%processInstanceEndDate |
The end date of the process instance |
%processInstanceDuration |
The duration of the process instance |
%technicalMessage |
The technical error message |
If you want to use a '%' character in your subject or body you need to escape it with '\': For example '\%relatedObjects' will result in '%relatedObjects' instead of resolving it.
If a placeholder can not be found it will be resolved to the string 'null'.