If you read through the What is ChatOps? section, you are familiar with notifications.
Even without ChatOps, notifications can be used to post messages to external systems
like Chat clients, send emails etc. Notifications require an action that is registered with
BWC (e.g., the post_message action in the the slack pack)
and a notification rule to go with it. Notifications are implemented as triggers, rules and actions.
A special core.st2.notifytrigger is emitted by the system on completion of every action.
A rule to match the trigger to a notify action results in notifications being sent out.

Above is the same action as a local-shell-cmd action but with notify. As you can see, there
is a notify section with on-complete section. You can also specify on-success
and on-failure sections with different messages. These subsections are all optional but at
least one is required for any meaningful notification. For the sake of clarity, an on-success case
is presented below.

When the notification triggers are sent out, the message is supplied along with a data
field containing the results of the execution. The rule can use these two fields -
message and data - and send it out as part of the action.

As you can see, this rule is setup for notification route slack. The action section shows
that slack.post_message is the one what would be kicked off. We are skipping the data part
of the trigger for brevity. If you had a slack action that also consumed some data as JSON string,
you could pass data:"{{data}}" as a parameter.

As of release 1.2, Jinja templating is supported for both message and data. The Jinja
contexts available for use are parameters of action and runner ({{action_parameters.cmd}}),
keys in execution results ({{action_results.stdout}}, {{action_results.stderr}} for example),
anything in action context ({{action_context.user}})
and anything in key-value store ({{st2kv.system.foo}}). Some examples are shown below:

The procedure here is the same if you want the same notification for all tasks in the chain.
Register an action metadata with a notify section. For example:

---# Action definition metadataname:"echochain"description:"Simple Action Chain workflow"# `runner_type` has value `action-chain` to identify that action is an ActionChain.runner_type:"action-chain"# `entry_point` path to the ActionChain definition file, relative to the pack's action directory.entry_point:"chains/echochain.yaml"enabled:true# Notify section for all tasks in the chainnotify:on-complete:message:"\"@channel: Action succeeded.\""routes:-"slack"

This is mostly useless because you want to control the message in each of the tasks. See the section
below.

How do I setup different notifications for different tasks in the chain?¶

The notify subsection is the same format as seen in examples above.
Place the subsection in action chain tasks. If there is a notify section for the action metadata,
and a notify section in the task, the task section will override the default. The relevant section
of a chain action with task notify is shown below:

The method for global notifications for the workflow is the same as action chain. You have a notify
section in the action meta when registering. See an
example.
Unfortunately, notifications per task are not supported in Mistral as a first class citizen yet.
This will be added in later releases.

This is implemented as a runner parameter skip_notify. If your chain or workflow contains
multiple tasks and you want some tasks to be “muted”, you can do so by specifying skip_notify
and call out tasks in the action meta. For example,

If you enabled ChatOps, you get all the the things wired for you. You don’t have to edit
action metadata etc. You can still use skip_notify to skip notifications for certain tasks in a chain
or workflow. If you specified a notify section in metadata or in tasks, those notification routes
will override ChatOps. Therefore, you might not see notifications in chat client.
See this issue for an example.