Inbuilt Incident Priority Control

Summary of the Current Solution

• One of the use cases we implemented is to classify incoming events via probe rules into service types (e.g., Outage, Degradation, Interface Down) using a lookup table. Incidents are created via front-end policies with predefined priorities (P1, P3, P5), while priority updates are handled through backend impact policies triggered by new correlated events. This three-part design is generic enough for current and future use cases, and provides automation and scalability with minimal policy configuration. However, the customer believes that this setup creates an operational gap: the NOC team is responsible for managing incident behavior, including escalation and suppression logic, but cannot directly control priority changes, which must be implemented by the customer project team via backend policies. For example, an incident initially triggered as P3 may need to be promoted or demoted based on evolving conditions.

Problem Statement

• Current version (v4.9.1) of AIOps does not have the function to escalate Incident priority based on a newly added correlated event with higher severity. The customized solution implemented by IBM service team required backend access which currently only the customer project team has the access (e.g. Probe rules lookup and Impact policy to query AIOps backend). This limits the NOC team’s ability to adjust priorities independently, creating operational delays and reducing agility in responding to real-time network conditions.

Feature Request

• The customer requested inbuilt function to escalate Incident priority based on new added correlated event with higher severity. So that it allows the NOC team to configure both incident creation and priority update logic directly from the AIOps interface, without depending on Probe rules lookup table and Impact policy.