In most cases, Inbound Integrations are singular things; data is sent to an endpoint, an Open condition is matched, an alert is generated, the designated team is notified. Any inbound payload containing the Open condition will produce the alert, and the team being notified is always the same.
In organizations with multiple teams using AlertOps, monitoring many resources, with differing levels of severity, different response needs, a single Integration just can't contain all of the configurations necessary to distribute the load properly.
Furthermore, configuring multiple endpoints in the originating system can be cumbersome, defining rules to route alerts to different endpoints offers considerable opportunity for errors, and troubleshooting becomes a challenge with the configurations present in separate systems.
In AlertOps, we address this challenge by allowing you to configure a single endpoint in the originating system, and use multiple Integrations to process the data. You can then choose different teams to send the alert to, based on the data. Or, perhaps you need different notification behavior, noisy (phone, SMS) alerts for high severity, quiet alerts for routine things (email). Different Escalation Rules can be applied to deliver the notifications based on the data.
To do this, we leverage two elements, Integration Sequence and Cloning. Cloning produces an exact copy of an Integration, including the endpoint URL, all of the data field mapping, filters, etc. You may give the clone a unique name, or leave it the same. The cloned Integration will have one significant difference, the Integration Sequence will be incremented.
In the above example, we have cloned an Integration, it has received the Integration Sequence of 1 and will be processed second. We have configured a specific Recipient Group and Escalation Rule for this clone.
Cloning alone does not provide any real difference between the Integrations, so with no further change, the second Integration above will never produce an Alert, as the first one will process all alerts. This is where Filters come into play. In Advanced Settings, expand Filters To Match Incoming Json/Form Fields.
By adding Filters, you create additional conditions for opening alerts. If the Filters in the first Integration are not matched, the data is passed to the second Integration, and if the Filters match there, an Alert is opened.
In this example above, we have configured a filter for the severity field. If the value in the data is "critical", this Integration will open an Alert. If the value is anything other than "critical", it will pass to the next Integration. With this filter in place, we can choose an Escalation Rule that is appropriate for the condition. In a subsequent Integration, we can modify this filter to reflect a different value, and provide an appropriate Escalation Rule to deliver those notifications.
Typically, the most important conditions are earliest in the sequence, and a catch-all (filterless) Integration can be used at the end of the sequence to notify someone if all other conditions are not met.
By configuring Sequenced Clones of Integrations, you can produce a scripted triage process that can direct alerts to specific teams, provide variable notification methods for differing conditions, invoke Workflow automations to send a webhook to remediate the issue, notify Stakeholders that their resources have been impacted, or many other options.