More options to setup conditions for triggering policies

We have a few automations in place and in development which must be triggered by specific actions on AIOps, which are currently not supported by the application. Right now, we need to trigger the policy for each and every alert update, and then check the specific conditions in the Impact policy code. By allowing more options when setting up trigger conditions we will be able to reduce processing load on Impact by triggering it only when it actually has to do further processing.

I've listed some of the triggers we need right now:

• Trigger policy when an alert is included in a group of alerts or incident
• Trigger policy when a group of alerts has been created / updated, also being able to filter if a specific alert is present in the group, or if the number of alerts in the group has reached a specific threshold
• Trigger policy when a group of alerts / incident has reached a threshold on number of open alerts it contains (both upper and lower thresholds)
• Trigger policy when all alerts in a group of alerts / incident have been closed

We also need additional parameters to setup conditions for when alerts should be promoted to incidents:

• Trigger incident creation only for groups of alerts with a minimum number of alerts
• Trigger incident creation only for groups of alerts containing X alerts matched to Y correlation type policies (for example, create incident only when 5 alerts brought together by a scope correlation policy, any or a specific one)
• Trigger incident creation only for groups of alerts with a specific alert present

Our goal is to create multiple incident creation policies for different scenarios. At first, we need to prevent incident creation for single alerts, so that we prevent excessive processing, as incidents are more costly to process then alerts. Then we need to create incidents only for groups of alerts. We want to allow incidents to be created for a single alert only in specific scenarios, for very specific alerts. For all others, an incident should not be automaticaly created if it is not part of a group, as our operations team want to review and evaluate them beforehand.

And finally, we need to be able to trigger policies for a defined date and time, while also being able to setup frequent executions (for example, every 10 minutes). This will allow us to use AIOps itself to trigger some alert automations instead of relying on an external job manager, which will make our plans to migrate all automations currently running on Netcool to AIOps.