Skip to main content
Version: 26

Notification actions

A Notification action is the central configuration object in the Avantra notification system. It connects a trigger to one or more Output Channels, and controls when, how often, and under what conditions notifications are sent.

Each Notification action supports one of six action types:

  • Checks: RTM and Daily check status changes
  • Changes: detected system configuration changes
  • Tickets: new or updated Ticket records
  • CCMS Alerts: CCMS alert records
  • Server Events: server-level events such as license expiry
  • SAP HotNews: newly released or newly affecting SAP Security Notes
  • Workflow Steps: notifications triggered explicitly from within an Automation workflow

Creating a notification action​

  1. Navigate to Configuration > Notifications.
  2. Click the Actions tab.
  3. Click New and select the appropriate action type (for example, Action for Checks...).
  4. In the wizard, fill in a Name and optionally a Description.
  5. Click Next.
  6. Define the scope of the action. The options available depend on the action type chosen.
  7. Click Next and configure any additional trigger criteria (if applicable).
  8. Click Next.
  9. Select one or more Output Channels to assign to this action. There may be other options available, such as Filter List and Custom Resolver, depending on action type chosen.
  10. Click Finish.
  11. Double-click on the action to open it.
  12. Click Activate to enable the action.
note

A newly created Notification Action is deactivated by default. It will not process notifications until activated.

Properties​

General​

FieldDescription
NameA unique name for the Notification Action.
DescriptionOptional free-text description.
Service HoursIf set, the action only fires during the time range defined by the selected Service Hours record. Notifications outside these hours are silently dropped.

Selector​

For Checks, Changes, and Tickets, a Selector defines which monitored elements the action applies to. You can restrict the action to a pre-defined System Selector, or define an ad-hoc custom selection scoped to this action only. CCMS Alert actions do not support selectors.

Filter lists​

Filter Lists provide fine-grained control over which notifications are actually processed. If one or more Filter Lists are linked to an action, a notification only proceeds if it passes all defined filters. This is useful for suppressing noise, for example, only alerting if a check has been Critical for more than one hour.

See Filters for details on creating and configuring filter lists.

Maximum attempts​

If an Output Channel fails to deliver (for example, because an SMTP server is temporarily unavailable), Avantra retries delivery. Maximum attempts sets the maximum number of delivery attempts before the notification is marked as Aborted. If no value is set, there is no retry limit.

Resolver​

A Resolver is an optional script that runs when a Notification Action fires, enriching the notification with additional data beyond the standard Interpolations. For example, a Resolver can translate internal status codes into business-specific terminology before they are passed to an Output Channel.

See Resolvers for details.

Confirmation​

Notification Actions can be used to confirm RealTime Monitoring checks or Daily checks. When a notification is delivered to a third-party system (such as ServiceNow), enabling confirmation allows Avantra to reflect this in its monitoring views.

If you want to confirm checks without delivering any notification output, assign the Null Output Channel to the action.

Resend options​

By default, a Notification Action fires once per status change event. Resend Options allow you to configure additional notification triggers for situations where the original condition persists or changes in a way that warrants a follow-up.

Resend Options are available for Checks action types only and are configured in the action's Properties tab. The Active checkbox must be enabled for any resend behavior to take effect.

Resend when confirmation changes to​

Fires a resend notification when the confirmation state of a check changes. You can choose to resend on:

  • UNCONFIRMED, when a confirmed check becomes unconfirmed again.
  • CONFIRMED, when a check is confirmed.
  • BOTH, on either confirmation state change.

Resend RTM notifications every (minutes)​

Triggers a periodic resend at the specified interval (in minutes) for as long as the check remains in a notifiable status. This is useful for escalation scenarios or integrations that require repeated signals until an issue is resolved.

Stop After Message Number limits how many total messages (including the original notification) are generated before resending stops. Leaving this field blank means resending continues indefinitely; setting it to 1 effectively disables resending.

Resend when RTM sub-status changes​

Some RTM checks report multiple sub-checks within a single overall status result, for example, the Filesystems check or DB tablespace checks. The overall check status may remain WARNING or CRITICAL while the set of affected items changes (new filesystems become full, others are resolved).

Enabling Resend When RTM Sub-Status Changes causes a new notification to fire whenever the sub-check composition changes, even if the top-level check status stays the same. This ensures that new individual failures are not missed while an existing alert is still open.

note

Not all RTM checks support sub-status. Sub-status is indicated in check result messages by a STATUS - message format (with a space-dash-space separator). Checks such as CPU Load and Paging Space do not use sub-status. Examples of checks that do include Filesystems, DB2_FSLOGARCH, JOBSTAT, and SPOOLSTAT.

When using sub-status resending, you must also define Resend on Status — the subset of check statuses eligible for sub-status resends. At least one status must be selected. Available values are CRITICAL, WARNING, OK, UNKNOWN, and DISABLED.

Action for Workflow Steps​

A Workflow Steps action connects the Avantra notification system to the Automation workflow engine. Rather than firing automatically on a monitoring event, this action type is triggered explicitly from within a workflow via a Send notification message step.

To use a Workflow Steps action:

  1. Create the Notification Action as normal, selecting Action for Workflow Steps as the type.
  2. Assign one or more Output Channels to define how the notification is delivered.
  3. Open the relevant workflow in the Automation module.
  4. Add a Send notification message step and select the Workflow Steps action you created.

This allows workflows to send structured notifications, for example, alerting a team when an automation completes, fails, or requires manual intervention, using the same Output Channels and message templating available to other action types.

Message status​

Every notification processed by a Notification Action generates a Notification message. Messages are stored in the Avantra database and can be reviewed in the Avantra WebUI under the Messages tab of the Notification Action.

Message StatusDescription
OK - BlockedThe notification was blocked by a Filter List.
OK - SentThe notification was successfully delivered.
PendingA delivery attempt failed; the notification will be retried.
AbortedAll delivery attempts failed. The Output Channel could not deliver the notification.
ScheduledThe notification is queued and waiting to be sent.
InitialThe notification was not processed because the trigger criteria (such as status or selector) did not match.