Setting Up the Notification Process
A Notification within Avantra is the process of reacting to an event with a predefined action. A typical event would be a changed check status, and an action can be as simple as send an email, and as starting an automation.
The events that trigger notifications are :
A Check with a changed/updated check status
New SAP HotNews or a Security Note was released by SAP
A Security Note or SAP HotNews affects one of your systems
An automation is sending a notification as part of its execution
A new system Change was detected
A new Ticket record, or a changed Ticket status, or a changed Ticket priority
A new CCMS Alert record
A License that is about to expire
A Notification Action also contains a number of other configuration items like:
Which systems does this action apply to?
Which checks or scenarios does this action apply to?
Which checks status can trigger this action?
Should a check status be marked as confirmed once a notification is sent?
When should a notification be resent and how often if the issue persists?
A notification action is the container for all of your notification configuration and set up. Notification actions contain the details of what can trigger the notification, where your notification is going (the channel), any filter rules that you have set up (the filter) and also any additional context you would want included in that notification (the resolver).
Channel (where is it going)
A Notification Channel is the destination for your notification. This can be anything from an email to an automation and a lot more. A notification can have one of more channels assigned to it so you can send information to multiple destinations and you can define channels to be used in the event that your primary channel is unavailable (a fallback).
Resolver (enrich the data)
A Notification resolver is how you enrich or translate information within a notification before it is sent. For example, if your business uses terminology such as "P1" or "P2" rather than "WARNING" or "CRITICAL", you can manipulate the notification data to make that change. Similarly if you are sending the notification to a 3rd party system (e.g. ServiceNow) you may want to add context to ensure it if processed correctly.
Filter (reduce the noise)
Nobody likes a 2am wake up call especially if there is not actually a problem. Filters allow you to suppress notifications in specific circumstances. For example, if you only want a notification to be sent if a check is CRITICAL for more than 1 hour, then you can do this in a filter. Similarly if you want to only send specific notification types during business hours, you can do this with a Filter too.
Global vs. Customer Notifications
In multi-tenant scenarios you may want to allow customer-specific users to set up and configure their own notification actions. You can do this via the "Customer Notifications" option (rather than Global Notifications). All of the concepts of a standard notification action remain the same however the interior components of a customer notification are not reusable between mutliple notification actions.
If a Service Provider wants to delegate the configuration of Notification Actions to a Customer, the Customer can only make use of these customer-specific all-in-one Notification Actions. The Service Provider of course can set up their own modular Notification Actions.