...

Hello ${headers.to?join(", ")},
this is an email with subject: ${headers.subject}
Cheers

The fields in the mime message supporting such $uri: references are:

• headers

  • to

  • cc

  • from

  • bcc

  • subject

• content (including all nested ones)

Addresses and Address Resolving

In the headers section of a mime notification you can declare the addresses of the recipients where the notification must be send to. Here is an example how to do this directly inside the mime notification JSON:

pipeline:
  - notification.send:
      input: {
          "headers": {
            "to":   ["email1@domain.tld", "email2@domain.tld"],
            "cc":   ["email3@domain.tld"],
            "bcc":  ["email4@domain.tld"],
            "subject": "This is the subject",
          }
          "body": {
              "contentType": "text/plain",
              "content": "This is the plain text body."
            }
        }

As an alternative you can also use the simple mode by declaring them as parameters directly on the command:

pipeline:
  - notification.send:
      to

Template Model

Inside each template the mime notification will be provided as the template root or body model, depending on the template approach used.

This root model will provide these fields:

• headers = A key-value map which contains all header values used to configure the notification.

• to = A list of resolved to recipient objects.

• cc = A list of resolved cc recipient objects.

• bcc = A list of resolved bcc recipient objects.

• from = The from recipient object.

• subject = Contains the (resolved) subject text.

• content = Contains the nested mime part objects as configured in the notification configuration.

• excludedAddresses = A list of all recipient objects excluded in this notification.

• allAddresses = Combines all recipient objects from to, cc and bcc into a single list and removes any duplicates.

• model = The message model provided from external. The structure of this model depends on the provider.

• uuid = The unique id of this notification, if set.

• attachments = A list of mime part objects extracted from the content body, defining the attachments of this notification.

Recipient

The structure of a notification recipient is like this:

• name = The display name of the recipient.

• locale = The locale of the recipient to be used for this notification.

• address = The address uri of the recipient.

• plainAddress = The plain address without any URI prefixes or query parameters.

• channel = The channel of this recipient (for example email, slack, ...)

Part

The structure of a notification mime part is like this (also see official MIME specification for this):

• contentType = The MIME content type of the content value.

• contentDisposition = The disposition header as defined in the MIME specification.

• contentTransferEncoding = The transfer encoding as defined in the MIME specification.

• content = The content of the part which can be one of:

  • A PIPEFORCE URI if contentTransferEncoding is set to outbound-url.

  • A base64 encoded string if contentTransferEncoding is set to base64.

  • A text value with format given by contentType.

  • A list of nested Part’s in case contentType is multipart/mixed.

Addresses and address resolving

In the headers section of a mime notification you can declare the addresses of the recipients where the notification must be send to. Here is an example how to do this directly inside the mime notification JSON:

pipeline:
  - notification.send:
      input: {
          "headers": {
            "to":   ["email1@domain.tld", "email2@domain.tld"],
            "cc":   ["email3@domain.tld"],
      bcc:  "email4@domain.tld"    "bcc":  ["email4@domain.tld"],
            "subject": "This is the subject",
          }
          "body": {
              "contentType": "text/plain",
              message"content": "This is the plain text body."

These address parameters will be converted to a mime notification JSON and placed in its header section for you.

Addresses prefixed with $uri:

...

            }
        }

As an alternative you can also use the simple mode by declaring them as parameters directly on the command:

pipeline:
  - notification.send:
      to:  "$uri:slack:mychatgroup" ["email1@domain.tld", "email2@domain.tld"]
      subjectcc: "This is the subject"
      message: "This is the plain text body."

In this example, the message will be send to a Slack channel instead of via email. You can also combine different addresses of different types like this example shows:

pipeline:
  - notification.send:
      to: ["$uri:slack:mychatgroup", "email1@domain.tld"]"email3@domain.tld"
      bcc:  "email4@domain.tld"
      subject: "This is the subject"
      message: "This is the plain text body."

In this example the notification These address parameters will be rendered as a Slack message and send to the Slack channel with name mychatgroup and additionally it will be rendered as email message and send to the email address email1@domain.tld.

Final and resolving addresses

There can be final and resolving addresses:

• Final address: The address can be used by a channel to deliver the message. For example an email address.

• Resolving address: The address needs to resolved (expanded) to one or more final addresses first, before it can be used by a channel to deliver the notification. For example an address referring to a user in IAM must first be expanded (resolved) to the user’s email address before the notification can be send.

Here is an example how such a resolving could look like:

...

Some resolving addresses could also be recursive.

This resolving (expanding) is automatically done by the notification framework.

Some notes about this example:

• A: Final addresses. They will be used to send the notification directly to the channels.

• B: The supervisor will get this notification via its default email.

• C: Any user who is member of group sales will get this notification via its preferred notification channel. In this example, this is user manager1 and his notification channels from IAM are sales1@company.tld and private1@mail.tld .

• D: The group sales contains another group admins and therefore all members of this role will additionally get the notification via their preferred address.

When the notification is processed, all groups and users will be resolved and the preferred channel will be used to send the notification.

$uri:email:

This final address will send the notification via email. The format is like this:

$uri:email:<email-address>

For example:

$uri:email:foo.bar@logabit.com

This is an alternative to not using the prefix at all. So this is also a valid email address:

foo.bar@logabit.com

$uri:user:

This resolving address will lookup the user with given username in IAM (user management) and be converted to the registered target address of the user which is an email address by default.

The format is like this:

$uri:user:<username>

Whereas <username> must be an enabled and exiting user in IAM with is username.

For example:

$uri:user:maxhuber

In case the user is disabled or doesn’t exist, this address will be ignored and removed from the address fields.

For example:

Let’s assume as default address of the user maxhuber in IAM the email address foo.bar@logabit.com is configured, then an address field like this:

...

"to"

...

["$uri:user:maxhuber"]

Will be resolved to this:

...

"to"

...

["$uri:email:foo.bar@logabit.com"]

$uri:group:

This resolving address will lookup a group with given name in IAM (user management) and it will be resolved to the default addresses of all user members of this group.

The format is like this:

$uri:group:<groupname>

Whereas <groupname> must be an enabled and existing group in IAM with this group name. For example:

$uri:group:sales

In case the group is disabled or doesn’t exist, this address will be ignored and removed from the address fields.

For example:

Let’s assume there is a group sales in IAM with with these member users and their default target addresses configured in IAM:

Then, an address field like this:

...

"to"

...

["$uri:group:sales"]

Will be resolved to this:

...

"to"

...

["$uri:email:teamlead@mail.tld", "$uri:slack:mychannel", "$uri:email:user2@mail.tld"]

$uri:slack:

This final address will send the notification to a Slack channel as configured by the connection config id.

The format is like this:

$uri:slack:<connection-config-id>

Whereas <connection-config-id> must be an id of a valid and enabled connection configuration.

For example:

$uri:slack:sales-channel

$uri:teams:

This final address will send the notification to a Microsoft Teams channel as configured by the connection config idconverted to a mime notification JSON and placed in its header section for you.

Addresses prefixed with $uri:

By default all addresses are assumed to be valid email addresses. But you can also use other address types to send the notification to a different channel. In case an address is not an email address, it always must be prefixed with $uri: . Here is an example to use a Slack channel as target address instead:

pipeline:
  - notification.send:
      to: "$uri:slack:mychatgroup"
      subject: "This is the subject"
      message: "This is the plain text body."

In this example, the message will be send to a Slack channel instead of via email. You can also combine different addresses of different types like this example shows:

pipeline:
  - notification.send:
      to: ["$uri:slack:mychatgroup", "email1@domain.tld"]
      subject: "This is the subject"
      message: "This is the plain text body."

In this example the notification will be rendered as a Slack message and send to the Slack channel with name mychatgroup and additionally it will be rendered as email message and send to the email address email1@domain.tld.

Final and expandable addresses

There can be final and expandable addresses:

• Final address: The address can be used as it is by a channel to deliver the message. For example an email address.

• Expandable address: The address needs to resolved (expanded) to one or more final addresses first, before it can be used by a channel to deliver the notification. For example an address referring to a user in IAM must first be expanded (resolved) to the user’s email address before the notification can be send.

Here is an example how such a resolving could look like:

Expandable addresses could also be recursive.

The resolving (expanding) is automatically done by the notification framework.

Some notes about this example:

• A: Final addresses. They will be used to send the notification directly to the channels.

• B: The supervisor will get this notification via its default email.

• C: Any user who is member of group sales will get this notification via its preferred notification channel. In this example, this is user manager1 and his notification channels from IAM are sales1@company.tld and private1@mail.tld .

• D: The group sales contains another group admins and therefore all members of this role will additionally get the notification via their preferred address.

When the notification is processed, all groups and users will be resolved and the preferred channel will be used to send the notification.

Handling address duplicates

Duplicate addresses which appear after expanding will be removed (for example because a user is member of multiple groups or roles configured for the notification, so his address is used only once).

In case the same addresses is used in to, cc and bcc, then the address in the lowest visibility will be kept. The visibility is like this (from lowest to highest):

1. bcc

2. to

3. cc

So for example if the same address is given in bcc, cc and to it will be removed from to and cc and only kept in bcc. Another example: If the same address is given in to and cc, it will be kept in to and removed from cc. And if the same address is given in bcc and cc, it will be kept in bcc and removed from cc. And so on.

$uri:email:

This final address will send the notification via email. The format is like this:

$uri:email:<email-address>

For example:

$uri:email:foo.bar@logabit.com

This is an alternative to not using the prefix at all. So this is also a valid email address:

foo.bar@logabit.com

$uri:user:

This expandable address will lookup the user with given username in IAM (user management) and be converted to the registered target address of the user which is an email address by default.

The format is like this:

$uri:teams:<connection-config-id>

...

user:<username>

Whereas <username> must be an id of a valid and enabled connection configurationenabled and exiting user in IAM with is username.

For example:

$uri:teamsuser:sales-team

$uri:message-route:

This is a final address: It will forward the message to the message broker using the given routing key.

The format is like this:

$uri:message-route:<routing-key>

Whereas <routing-key> is the target routing key where the message must be forwarded to. The mime notification headers will be set as message headers and the body will be serialized as JSON into the playload of the message.

For example:

$uri:message-route:security_audit_queue

$uri:pipeline:

This resolving address will call the pipeline given by path, puts the mime notification into its body and executes it. It expects a JSON array of addresses to be returned, all starting with prefix $uri:. Otherwise, the address will be ignored. These addresses will then replace the $uri:pipeline: address in the fields.

The format is like this:

$uri:pipeline:<pipeline-path>

For example:

$uri:pipeline:global/app/my.app/pipeline/dynamic-addresses

The dynamic-addresses pipeline could look like this example to return addresses dynamically:

pipeline:
  - body.set:
      value: ["$uri:email:address1@mail.tld", "$uri:user:someusername"]

$uri:property:

...

maxhuber

In case the user is disabled or doesn’t exist, this address will be ignored and removed from the address fields.

For example:

Let’s assume as default address of the user maxhuber in IAM the email address foo.bar@logabit.com is configured, then an address field like this:

Will be resolved to this:

$uri:group:

This expandable address will lookup a group with given name in IAM (user management) and it will be resolved to the default addresses of all user members of this group.

The format is like this:

$uri:group:<groupname>

Whereas <groupname> must be an enabled and existing group in IAM with this group name. For example:

$uri:group:sales

In case the group is disabled or doesn’t exist, this address will be ignored and removed from the address fields.

For example:

Let’s assume there is a group sales in IAM with with these member users and their default target addresses configured in IAM:

Then, an address field like this:

Will be expanded (resolved) to this:

$uri:slack:

This final address will send the notification to a Slack channel as configured by the connection config id.

The format is like this:

$uri:property:<property-path>slack:<connection-config-id>

Whereas <connection-config-id> must be an id of a valid and enabled connection configuration.

For example:

$uri:property:global/app/my.app/data/my-addresses

The my-addresses pipeline could look like this example:

["$uri:email:address1@mail.tld", "$uri:user:someusername"]

Recursive resolving of addresses

Resolving addresses are resolved (expanded) recursively until the final address appears. So for example a resolving address given like this:

...

"to"

...

["$uri:pipeline:global/app/my.app/pipeline/my-adresses"]

Could return and resolve to:

...

"to"

...

["$uri:email:user1@logabit.com", "$uri:group:sales"]

Which in term could resolve to this in the next recursion:

...

"to"

...

["$uri:email:user1@logabit.com", "$uri:user:user2", "$uri:user:user3", "$uri:user:user4"]

Which resolves to these final addresses:

...

"to"

...

["$uri:email:user1@logabit.com", "$uri:email:user2@logabit.com", "$uri:email:user3@logabit.com", "$uri:email:user4@logabit.com"]

Excluding addresses

It is possible to exclude certain addresses from a mime message. To do so, you can use the custom header x-pipeforce-exclude-addresses and specify the addresses to be excluded. For example:

:slack:sales-channel

$uri:teams:

This final address will send the notification to a Microsoft Teams channel as configured by the connection config id.

The format is like this:

$uri:teams:<connection-config-id>

Whereas <connection-config-id> must be an id of a valid and enabled connection configuration.

For example:

$uri:teams:sales-team

$uri:message-route:

This is a final address: It will forward the message to the message broker using the given routing key.

The format is like this:

$uri:message-route:<routing-key>

Whereas <routing-key> is the target routing key where the message must be forwarded to. The mime notification headers will be set as message headers and the body will be serialized as JSON into the playload of the message.

For example:

$uri:message-route:security_audit_queue

$uri:pipeline:

This expandable address will call the pipeline given by path, puts the mime notification into its body and executes it. It expects a JSON array of addresses to be returned, all starting with prefix $uri:. Otherwise, the address will be ignored. These addresses will then replace the $uri:pipeline: address in the fields.

The format is like this:

$uri:pipeline:<pipeline-path>

For example:

$uri:pipeline:global/app/my.app/pipeline/dynamic-addresses

The dynamic-addresses pipeline could look like this example to return addresses dynamically:

pipeline:
  - notificationbody.sendset:
      inputvalue: {
          "headers": {
            "x-pipeforce-exclude-addresses": ["$uri:group:vacation"]
            "to":   ["$uri:group:sales"],
            "subject": "New lead",
          }
          "body": {
              "contentType": "text/plain",
              "content": "Hi, a new lead was created."
            }
        }

In this example, the New lead notification will be send to all members of group sales excluding those users also in group vacation.

Exclude addresses can be final and resolving addresses.

Multi-Language Notifications (i18n)

The notification framework supports multi language notifications. This means a notification can be send in different languages to the recipients.

How to enable it

...

["$uri:email:address1@mail.tld", "$uri:user:someusername"]

$uri:property:

This expandable address will load the property at given path and expects the value to be a JSON array containing the addresses to be returned.

The format is like this:

$uri:property:<property-path>

For example:

$uri:property:global/app/my.app/data/my-addresses

The my-addresses pipeline could look like this example:

["$uri:email:address1@mail.tld", "$uri:user:someusername"]

Resolving of expandable addresses

Expandable addresses are resolved (expanded) recursively until the final address appears. So for example an expandable address given like this:

Could return and resolve to:

Which in term could resolve to this in the next recursion:

Which resolves to these final addresses:

Excluding addresses

It is possible to exclude certain addresses from a mime message. To do so, you can use the custom header x-pipeforce-exclude-addresses and specify the addresses to be excluded. For example:

{
  "headers": {
    "x-pipeforce-exclude-addresses": ["$uri:group:vacation"]
    "to":   ["$uri:group:sales"],
    "subject": "New lead",
  }
  "body": {
      "contentType": "text/plain",
      "content": "Hi, a new lead was created."
    }
}

In this example, the New lead notification will be send to all members of group sales excluding those users also in group vacation.

Exclude addresses can be final and expandable addresses.

Multi-Language Notifications (i18n)

The notification framework supports multi language notifications. This means a notification can be send in different languages to multiple recipients. The framework handles the way how the templates related to the selected language will be loaded and clusters the notifications based on the selected language (locale).

How to enable it

By default i18 is turned-off. In order to enable multi-language (i18n) support, you have to set the header x-pipeforce-multilang to true in your notification configuration:

{
  "headers": {
    "x-pipeforce-multilang": true,
    ...
  }
  ...
}

How it works

The main concept behind i18n support in notifications is that any $uri:template, $uri:property or $uri:pipeline which is used in subject or body of the notification will automatically be suffixed with the selected locale (= language key): For example, if you use the URI $uri:template:global/app/com.acme.myapp/mytemplate inside your notification configuration like this:

{
    "headers": {
      "to":   ["email1@domain.tld", "email2@domain.tld"],
      "subject": "This is the subject",
    }
    "body": {
        "contentType": "text/plain",
        "content": "$uri:template:global/app/com.acme.myapp/mytemplate"
      }
  }

… and the locale de (german) is selected, the URI will automatically become $uri:template:global/app/com.acme.myapp/mytemplate_de: It will be prefixed with _de so the template specific to german language can be loaded. And in case the locale en (english) is selected, this prefixed URI will be loaded instead: $uri:template:global/app/com.acme.myapp/mytemplate_en (the suffix _en is appended). This way you can organize your templates in the property store in a clear way. For example it could look like this:

• global/app/com.acme.myapp/template/

  • mytemplate_de

  • mytemplate_en

  • mytemplate_fr

  • mytemplate_sk

Here are the steps, how this all works together:

1. It will look for a query param ?locale=<lang> in each address in to, cc or bcc fields.
   For example: $uri:email:foo@bar.tld?locale=de. If no locale exists it will use en as default.

2. If the address is an IAM address like $uri:group: or $uri:user: it will use the value of user attribute locale from IAM for the locale, if exists. Otherwise, it will fallback to en as default. If both are given (query param and locale attribute in IAM), the query param will have precedence.

3. It will split a notification to multiple notifications for each new language and will manage to split also addresses according to these languages. For example if there are these TO addresses set: $uri:email:my@mail.tld?locale=de, $uri:email:another@mail.tld?locale=en this means two emails will be rendered and send: One with de as language with german text in subject and body and one with english text. Finally, there will be two emails: The DE one is sent to my@mail.tld and the EN one sent to another@mail.tld. The same is true for addresses in cc and bcc.

4. As already mentioned above, any $uri:template, $uri:property or $uri:pipeline which is used in subject and body of the notification configuration will automatically be suffixed with the selected locale. So for example $uri:template:global/app/com.acme.myapp/mytemplate will become $uri:template:global/app/com.acme.myapp/mytemplate_de in case the detected language (locale) is set to de.

Static suffix / disable suffixing

In some situations, suffixing the template resource path is not wanted or a static suffix must be used for all of such resources. For this, you can set the header x-pipeforce-multilang-suffix to a static suffix. If this is set, it will be used and the calculated suffixes from the language (for example _en) will be ignored.

In case you don’t want to use suffixes at all, set this header to empty string "". Then, always the template resource without suffix will be loaded. You can then add language specific logics inside your template by using the Content-Lang header which is also provided into the template.

Multi-Channel Notifications

The notification framework also supports sending a notification to different channels. This way it is possible beside via email, the same notification can be send to a Slack channel, via SMS and Teams for example. For each channel, different templates can be provided in order to adjust the format of the message so it fits the target channel.

How to enable it

By default multi-channel support is disabled. In order to enable multi-channel support, you have to set the header x-pipeforce-multilang to true.multichannel to true in your notification configuration:

{
  "headers": {
    "x-pipeforce-multichannel": true,
    ...
  }
  ...
}

How it works

If this header is setmulti-channel support is enabled, the framework will consider these ruleshandle a notification similar to the multi-language approach:

• It will look for a query param ?locale=<lang> in each address.
  for the final addresses in the address uri. For example:

  • $uri:email:

  foo@bar.tld?locale=de. If no locale exists it will use en as default.If the address is an IAM address like $uri:group: or $uri:user: it will use the value of user attribute locale from IAM for the locale if exists. Otherwise, it will fallback to en as default. If both are given (query param and locale attribute in IAM), the query param will have precedence.

  • → email channel

  • $uri:slack: → slack channel

  • $uri:teams: → teams channel

  • $uri:sms → sms channel

  • aso.

• It will split a single notification to multiple notifications for notification messages: For each new language channel and will manage to split also addresses according to these languageschannels. For example if there are these TO addresses set: $uri:email:my@mail.tld?locale=de, $uri:email:another@mail.tld?locale=enslack:mygroup this means two emails notifications will be rendered and send: One with de as language with german text as email and the other one as Slack message. The same is true for addresses in CC and BCC.

• Any $uri:template, $uri:property or $uri:pipeline which is used in subject and body and one with english text. Finally, there will be two emails: The DE one is sent to my@mail.tld and the EN one sent to another@mail.tld. The same is true for addresses in CC and BCC.Any $uri:template, $uri:property or $uri:pipeline which is used in subject and body of the notification will automatically be suffixed with the selected locale. So for of the notification will automatically be suffixed with the selected channel. So for example $uri:template:mytemplate will become $uri:template:mytemplate_slack in case the channel is set to slack via address. This way, different templates can be provided in the property store and the notification framework will pick-up the one which belongs to the selected channel.

Additionally, the detected channel will be set as x-pipeforce-channel header so it can be used in the templates as well.

...

...

...

Multi-Channel Notifications

The notification framework also supports sending a notification to different channels. This way it is possible beside via email, the same notification can be send to a Slack channel, via SMS and Teams for example. For each channel, different templates can be provided in order to adjust the format of the message so it fits the target channel.

How to enable it

In order to enable multi-channel support, you have to set the header x-pipeforce-multichannel to true.

How it works

If multi-channel support is enabled, the framework will handle a notification similar to the multi-language approach:

• It will look for the final addresses in the address uri. For example:

  • $uri:email: → email channel

  • $uri:slack: → slack channel

  • $uri:teams: → teams channel

  • $uri:sms → sms channel

  • aso.

• It will split a single notification to multiple notification messages: For each new channel and will manage to split also addresses according to these channels. For example if there are these TO addresses set: $uri:email:my@mail.tld?locale=de, $uri:slack:mygroup this means two notifications will be rendered and send: One as email and the other one as Slack message. The same is true for addresses in CC and BCC.

• Any $uri:template, $uri:property or $uri:pipeline which is used in subject and body of the notification will automatically be suffixed with the selected channel. So for example $uri:template:mytemplate will become $uri:template:mytemplate_slack in case the channel is set to slack via address. This way, different templates can be provided in the property store and the notification framework will pick-up the one which belongs to the selected channel.

Static suffix / disable suffixing

In some situations, suffixing the template resource path is not wanted or a static suffix must be used for all of such resources. For this, you can set the header x-pipeforce-multichannel-suffix to a static suffix. If this is set, it will be used and the calculated suffixes from the channel (for example _email) will be ignored.

In case you don’t want to use suffixes at all, set this header to empty string "". Then, always the template resource without suffix will be loaded. You can then add channel specific logics inside your template by using the x-pipeforce-channel header which is also provided into the template.

Personalized Notifications

Lets a assume you have a list of recipient addresses configured in your notification configuration like this:

{
  "headers": {
    "to": ["$uri:user:someUser1", "$uri:user:someUser2"]
  },
  ...
}

… and instead of sending the same static email to all of these recipients you would like to generate and send individual text messages for each.

So for example someUser1 should get this email text:

Hello someUser1,
this is a personlized email for you.

… and someUser2 should get this email text:

Hello someUser2,
this is a personlized email for you.

To do so, you have to set the header x-pipeforce-personalized to true:

{
  "headers": {
    "x-pipeforce-personalized": true,
    "to": ["$uri:user:someUser1", "$uri:user:someUser2"]
  },
  ...
}

In this case for each recipient the templating rendering is called again so the content can be personalized then. The to header will always be set to the personalized recipient and cc and bcc will be deleted.

Inside the template you can then access the personalized recipient by accessing the to header or by calling allAddresses[0]. Here is an example how such a template could look like:

<#assign recipient = allAddresses[0]>
Hello ${recipient.name},
this is a personlized email for you.

This will be repeated for every recipient, regardless whether it is set on to, cc or bcc.

Finally, the text result of each template rendering will be send as individual message.

Push Notifications

Push notifications are system and business events, a user can subscribe to. Any time there is a match, such an event is automatically converted to a notification and will be send to the registered user's preferred communication channels like email or chat group for example.

...

• to: A list of addresses, to send the push notification to.

• cc: A list of addresses, to send the push notification to in CC.

• bcc: A list of addresses, to send the push notification to in BCC.

• subject: The subject to be used for the push notification. If no subject is set, a default subject is generated.

• x-pipeforce-exclude-addresseses: A list of addresses to exclude from the push notification.

...

• $uri:wf-authenticated-user = Returns the $uri:user:<username> of the user who was logged-in at the time of this event and potentially has initiated this event.

• $uri:wf-process-involved-users = Returns the $uri:user:<username> of all users involved in the workflow process.

• $uri:wf-started-by = Returns the $uri:user:<username> of the user who started the workflow.

• $uri:wf-task-candidate-groups = Returns the $uri:group:<name> names of all groups which are set as candidate group of given task. In case there is no candidate group set, the address variable will be removed from all address fields.

• $uri:wf-task-assignee = Returns the $uri:user:<username> of the user who is set as assignee on given workflow task. In case there is no taskAssignee set, the address variable will be removed from all address fields.

• $uri:wf-task-owner = Returns the $uri:user:<username> of the user who is set as assignee on the given workflow task. In case there is no taskOwner set, the address variable will be removed from all address fields.

• $uri:author = In case the event is related to a comment creation, returns the $uri:user:<username> of the user who created the comment. This is also true for comments created outside of workflow related events.

Duplicate addresses will always be removed.

...